Re: UDP error handling

From: David Schwartz (davids_at_webmaster.com)
Date: 04/04/05


Date: Mon, 4 Apr 2005 13:36:07 -0700


"Barry Margolin" <barmar@alum.mit.edu> wrote in message
news:barmar-FE27C6.15423604042005@comcast.dca.giganews.com...

>> Are you saying you have never heard of a case where a NAT box
>> 'repaired'
>> the checksum of a UDP packet that was received corrupt because it didn't
>> check the checksum before rewriting the destination address?

> No, I've never heard of a proxy modifying the payload when it doesn't
> know the application protocol.

    You mean when it doesn't *think* it knows the application protocol. It
may think it knows the application protocol because of the port used (either
as source or destination in some cases) or it make 'recognize' the protocol
automatically.

>> It's hard to find URLs on the Internet because it's not clear what
>> terms
>> to search for. But I have personally dealt with many cases where proxies,
>> firewalls, and LSPs thought they understood the data I was sending and
>> made
>> manipulations that might be sensible for other protocols but made no
>> sense
>> for an arbitrary protocol layered over TCP or UDP.
>>
>> http://forums.bitpass.com/viewtopic.php?p=136
>> http://www.livejournal.com/community/lj_dev/666626.html
>> http://www.uwsg.iu.edu/hypermail/linux/net/9609.3/0024.html
>
> None of these seem to be examples of what you're describing.

    These are all cases where proxies created problems because they thought
they understood what the applications wanted and were wrong. There have
definitely been reported cases of NAT boxes doing the equivalent of a 'grep'
through packets for the inside source address and helpfully changing it to
the outside address.

> I have no
> trouble believing the case where a NAT box doesn't verify the checksum
> of a received packet before doing the header rewrite.

    That's really sufficient to create the problem he's worried about. A
corrupted packet could have its checksum 'repaired' by a broken NAT
application.

    DS



Relevant Pages

  • Problem Modifing the NDIS packet
    ... I am trying to modify the NDIS packet. ... Calculate the Checksum. ... Modify the Destination MAC address. ...
    (microsoft.public.development.device.drivers)
  • NDIS passthru packet redirection
    ... I want to redirect tcp packets to different destination. ... But the packet is routed somewhere else. ... and calculate the ip header checksum. ...
    (microsoft.public.development.device.drivers)
  • Re: Problem with the NDIS MUX IM driver (decapsulation not working)
    ... If the higher-level protocol and the lower-level miniport have enabled some TCP task offload contract, then the decapsulated packet you are indicating may not provide the necessary task offload information. ... then temporarily disabling the NDIS task offload features of the adapter using the adapter's NCPA advanced property tab should make the behavior "better". ... I slap on my own ethernet header infront of the real ...
    (microsoft.public.development.device.drivers)
  • Re: Serial port read latency (SERIOUS - NEED HELP FAST!)
    ... In regular Windows XP, expecting a 5ms interval would normally encounter geers and cat-calls from the news group. ... Is the 5ms "window" the only termination, or are you using a protocol that defines end of text or message? ... ReadFile will complete when there is 5 ms interval between received bytes. ... > The protocol requires our embedded device to respond to a packet> within ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Sniffer Cant see cluster traffic
    ... > protocol and cluster specific multicast MAC address, ... > node specific source MAC address. ... > is a multi-cast packet or a directed packet. ... Yep and that is solely at the ethernet packet level. ...
    (comp.os.vms)