Re: bind() udp behavior 2.6.8.1

[linux-os]

On Wed, 15 Dec 2004, Adam Denenberg wrote:

> almost yes.  The firewall never passes the retransmit onto the DNS
> server since it has the same DNS ID, source port and source ip.  What is
> happening is the following
>
> request 1
> --------------------
> linux box.32789 (id 001) ->  FW -> DNS SERVER.53
> DNS SERVER.53 (id 001) -> FW -> linux box.32789
>
> request 2
> -------------------
> linux box.32789 (id 002) -> FW -> DNS SERVER.53
> DNS SERVER (id 002).53 -> FW -> linux box.32789
>
> request 3
> -----------------------
> linux box (id 002).32789 -> FW -> NEVER GETS HERE, B/C ITS DROPPED
>
> the time between request 2 and request 3 is under 60ms.  The firewall is
> in the midst of clearing its table for the dns request with ID 002
> already so it thinks its a duplicate and drops it.  So my question is,
> why is the kernel not incrementing the DNS ID in this case? It does it
> for almost all other tests that i can find, and the firewall does not
> drop any traffic.  Only when the DNS ID does not increment does this
> problem occur.  This does not seem to always be the default behavior.  I
> wrote a small C program to just put a gethostbyname_r() in a for loop
> and each DNS ID is incremented all 40 times.  But there are times when
> this doesnt happen, and this seems to be what is causing the issue.  The
> firewall needs some sort of identifier to know which dns request is
> associated with which dns reply (source ip, source port, ID).
>
> this is the behavior I am trying to debug.
>
> thanks
> adam

The ID portion of the IP header, offset 32, is 16 bits of unique
identification that is supposed to be unique for the entire time
that any message should be in the system. That's what firewalls
and routers use to determine if it's a duplicate packet. You
never before stated that Linux was duplicating the ID portion,
and if it is, it's a bug. But, I'll bet that it isn't. Nothing
would work if it was. All TCP/IP messages are composed of
Datagrams. If these basic elements were mucked up, this would
have been discovered long before now, and if not discovered,
you wouldn't receive this message. Also UCP is connectionless
and stateless. If you have some box that handles it differently,
its broken.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by John Ashcroft.
                 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/