Re: Correct or expected UDP behavior

[email protected] wrote:
> A project I'm working on is about to make a kernel mod
> that I'm not really in favor of, so I thought I would
> query the experts.

This is not an ARM question, so you're asking on the wrong list, and
experts on UDP & DNS probably aren't reading this list.

I'm replying but you should probably reply to me in private if you
have any further questions.

> This is a mobile device that supports network connectivity.
> The problem arises when a DNS query comes back with valid
> data from a different IP address than the query was sent to.

The DNS service is broken.

Even if you changed the client, it wouldn't work with that DNS service
if you put an ordinary stateful firewall in the way.

> tcpdump logs viewed with wireshark clearly show the
> DNS query going out as a UDP packet and the response
> coming back as a UDP packet from a different IP address.
> Our device then sends an ICMP packet [Destination unreachable (Port  
> unreachable).  This sequence of 3 packets repeats endlessly.

This is expected behaviour in either of these situations:

    - The client's UDP socket had both bind() and connect() called on it.
    - There is a stateful firewall or NAT between the client and server.

Also, if the client doesn't call connect, but does check the source IP
address of the reply and ignore replies from the wrong address, then
you'll see the endless repeat of 2 packets, with no ICMP.

Many DNS clients do call connect() or check the source IP address of
the reply themselves (and discard replies with the wrong source IP),
so this is no surprise.

> At least one online reference indicates this is incorrect
> behavior for UDP
> 
> http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/udp.html

I've just read it, and I don't see any place where it says that is
incorrect.  Where do you see that?

> > If a client/server application executes on a host with more than one  
> > IP >interface, the application needs to ensure that it sends any UDP  
> > responses >with an IP source address that matches the IP destination  
> > address of the UDP >datagram that carried the request.
> 
> An internal network expert indicates the mobile device should accept
> the DNS response even though the IP address differs.

The internal network expert is misinformed, unless mobile networks are
different from other IP networks to such an extent that standard
applications won't work.

> Q.1) Is the behavior we are seeing where the packet gets rejected
> expected/normal behavior for the Linux kernel?

Yes.

The behaviour depends on the application running on your client asks
for.  The kernel will send ICMPs if the application asked for it by
calling connect().  If the application doesn't do that, it may still
check the source IP address of replies, and discard replies which
don't match what it's expecting.

> Q.2) If we have to make a mod to accomodate this behavior, where is
> the least intrusive point in the network stack to make this mod?

In the DNS library used by the client application.  I assuming you're
running ARM Linux, so probably in uClibc or Glibc in a file called resolv.c
(but a few applications use something else instead).

If you look you'll see the code is put in there deliberately though...
GNU/Linux DNS client code is extremely well tested, you have not found a bug.

That DNS service is severely broken, I wouldn't try to pretend it's ok.
Insist that it is broken and must be fixed.

But if you must workaround a broken mobile network, either a private
modification to the userspace library is the place to do it, or perhaps
an iptables ruleset to "mangle" the broken replies.

-- Jamie

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php