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.
