[Dnsmasq-discuss] Weird Routing/FW/dnsmasq problem

[Dan Shechter]

Again, this is pretty much what I've seen as well.

I'm using Windows XP SP2 as a client.

The exact situation is that when the XP machine is
Connected/disconnected from net A -> B WITHIN 10 seconds,
it performs the sequence of events described in my previous e-mail...

If the disconnection is for MORE than about 10 seconds,
The DHCP request is from address 0.0.0.0 which of course, succeeds,
almost immediately.

The unpleasant part is that these scenarios happen much too often in
wireless roaming environments, which is where I'm at... :(

The unfortunate bit of Microsoft's client behaviour, is that it resends
the same request 3 times, displays an annoying, "Network is lost"
balloon popup, and only then issues a discover from 0.0.0.0 which
succeeds, 40 seconds after it "appeared" on network B.

All of my attempts to somehow propagate the packet through Linux, using
any combination of iptables / -j MARK / iproute2 packages have failed
insofar.

	Shechter.


> -----Original Message-----
> From: Simon Kelley [mailto:simon at thekelleys.org.uk]
> Sent: Monday, October 31, 2005 16:05
> To: Dan Shechter
> Cc: dnsmasq-discuss at lists.thekelleys.org.uk
> Subject: Re: [Dnsmasq-discuss] Weird Routing/FW/dnsmasq problem
> 
> Dan Shechter wrote:
> > Yes, I totally agree, although I know for a fact that these packets
are
> > not dropped by iptables, since I've written an explicit rule to
ACCEPT
> > them.
> > I've basically done a:
> > "iptables -t filter -A INPUT -p udp --dport 67 -s ! 192.168.100.0/24
-j
> > ACCEPT"
> > And I can verify using "iptables -L -n -v -t filter" that this rule
in
> > the
> > FW chains is being hit upon using the packet counters.
> 
> Ok, that rules out iptables. Sorry to doubt you, but most problems of
> this type which I see are iptables related.
> >
> > My problem seems to be related more to routing.
> > A possible fix to this situation is for example to configure an
> > Additional device:
> > "ifconfig eth2:0 up 10.0.0.0 netmask 255.0.0.0"
> > This command alone, allows dnsmasq to "see" the packets and return a
> > broadcast NAK.
> >
> 
> So it looks like there might be some code in the kernel that checks
that
> the source address is on a local network. That would make some sense:
> packets sent to 255.255.255.255 are not meant to be routed, but if
they
> are it can cause mischief.
> 
> I had a quick poke around in the linux IP stack, but I couldn't see
> anything obvious, and it's code which has been optimised for years by
> very bright people, ie not very easy to understand.
> 
> BTW, what client are you using? I think most clients always set the
> source address to zero when broadcasting. RFC2131 says
> 
>     "DHCP messages broadcast by a client prior to that client
obtaining
>     its IP address must have the source address field in the IP header
>     set to 0."
> 
> but that's ambiguous, since it's not clear if a client in INIT-REBOOT
> state is "prior" to "obtaining its IP address".
> 
> Cheers,
> 
> Simon.
>