From: Adam Denenberg <adam@dberg.org>
To: linux-os@analogic.com
Cc: Jan Harkes <jaharkes@cs.cmu.edu>,
Kyle Moffett <mrmacman_g4@mac.com>,
linux-kernel@vger.kernel.org,
Jan Engelhardt <jengelh@linux01.gwdg.de>
Subject: Re: bind() udp behavior 2.6.8.1
Date: Wed, 15 Dec 2004 15:19:51 -0500 [thread overview]
Message-ID: <1103141991.6825.17.camel@sucka> (raw)
In-Reply-To: <Pine.LNX.4.61.0412151459150.4365@chaos.analogic.com>
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.
adam
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.
>
>
> 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.
>
next prev parent reply other threads:[~2004-12-15 20:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-14 15:38 bind() udp behavior 2.6.8.1 Adam Denenberg
2004-12-14 16:04 ` Jan Engelhardt
2004-12-14 16:42 ` Adam Denenberg
2004-12-14 16:44 ` Jan Engelhardt
2004-12-14 17:01 ` Adam Denenberg
2004-12-14 17:10 ` Jan Engelhardt
2004-12-14 17:38 ` Adam Denenberg
2004-12-14 17:49 ` Jan Engelhardt
2004-12-15 0:43 ` Wichert Akkerman
2004-12-16 5:49 ` Willy Tarreau
2004-12-14 22:07 ` Kyle Moffett
2004-12-15 2:23 ` Adam Denenberg
2004-12-15 3:19 ` Kyle Moffett
2004-12-15 14:16 ` Adam Denenberg
2004-12-15 19:07 ` Jan Harkes
2004-12-15 19:22 ` Adam Denenberg
2004-12-15 20:06 ` linux-os
2004-12-15 20:19 ` Adam Denenberg [this message]
2004-12-15 20:45 ` Doug McNaught
2004-12-15 20:48 ` Adam Denenberg
2004-12-15 20:57 ` Doug McNaught
2004-12-16 6:10 ` Willy Tarreau
2004-12-16 14:24 ` Adam Denenberg
2004-12-16 14:51 ` Jan Harkes
2004-12-16 15:00 ` Adam Denenberg
2004-12-16 6:03 ` Willy Tarreau
2004-12-16 14:17 ` Adam Denenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1103141991.6825.17.camel@sucka \
--to=adam@dberg.org \
--cc=jaharkes@cs.cmu.edu \
--cc=jengelh@linux01.gwdg.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
--cc=mrmacman_g4@mac.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox