From: Adam Denenberg <adam@dberg.org>
To: Jan Harkes <jaharkes@cs.cmu.edu>
Cc: 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 14:22:53 -0500 [thread overview]
Message-ID: <1103138573.6825.11.camel@sucka> (raw)
In-Reply-To: <20041215190725.GA24635@delft.aura.cs.cmu.edu>
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
Please CC me as i am not on the list.
On Wed, 2004-12-15 at 14:07, Jan Harkes wrote:
> On Wed, Dec 15, 2004 at 09:16:02AM -0500, Adam Denenberg wrote:
> > the Firewall from distinguishing unique dns requests. It sees a second
> > DNS request come from the linux server with the _same_ transaction ID in
> > the UDP header as it is marking that session closed since it already saw
> > the reply successfully. So for example the linux server is making a dns
>
> Stupid guess here,
>
> The reply got dropped after it passed your firewall and before it
> reached the linux server. What you are seeing is simply a retransmit
> which would also have happened if the original request got lost, or if
> the reply was dropped before it reached your firewall, in which case the
> firewall probably would have forwarded the retransmitted request without
> a problem.
>
> I would open the window before you throw the piece of garbage out.
>
> Jan
>
next prev parent reply other threads:[~2004-12-15 19:24 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 [this message]
2004-12-15 20:06 ` linux-os
2004-12-15 20:19 ` Adam Denenberg
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=1103138573.6825.11.camel@sucka \
--to=adam@dberg.org \
--cc=jaharkes@cs.cmu.edu \
--cc=jengelh@linux01.gwdg.de \
--cc=linux-kernel@vger.kernel.org \
--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