Re: bind() udp behavior 2.6.8.1

[Adam Denenberg]

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
> 

-
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/