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

[Simon Kelley]

Dan Shechter wrote:
> 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.
> 

Argh, it's taken me this long to twig that this conversation follows on 
from earlier stuff where dnsmasq failed to generate the a NAK because 
the claimed address wasn't on the current network. Must wake up!

That got fixed in 2.23, and in the process, we disovered that XP's DHCP 
client is in fact moving to REBINDING state during those 10 seconds. 
This means that it sets the ciaddr field in the DHCP packet, causing the 
previous (now fixed) problem. Clearly the wonderful people at Microsoft 
are _also_ setting the packet source address, and hence confusing the 
kernel too.

I'm slighly confused, since as part of the previous fix Gyorgy Farkas 
did some tests on XP and produced some packet captures which didn't show 
this effect. Also, the previous problem could only have occured if the 
DHCPREQUEST in REBINBING state was being recieved at user level by 
dnsmasq. What has changed which is stopping that from happening now?

Following from Oliver's suggestion, there's another sysctl variable, 
bootp_relay, which might be just what's needed, except that it's not 
implemented. Dang!

http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html#AEN601

Cheers,

Simon.