Re: bind() udp behavior 18.104.22.168
From: Adam Denenberg
Date: Wed Dec 15 2004 - 15:21:57 EST
sorry for any confusion, but i am not referring to the Identification
field in the IP header but rather the "Transaction ID" field in the DNS
query portion of the packet. I can reproduce this behavior on our linux
system where if i pump gethostbyname_r requests on the system at some
point it will reuse a transaction id in the DNS request. This is my
lastest discovery in what is causing the requests to fail thru the
firewall. So far my research has not turned up any reason as to why the
kernel would be re-using a transaction ID in the dns request.
The ip IDentification field is uniquely generated as it should be, just
not the Transaction ID field of the dns portion of the packet.
Please CC me as I am not on this list.
On Wed, 2004-12-15 at 15:06, linux-os wrote:
> 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.
> 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/