On 11 May 2014 06:38, Creamy <cre...@dishplanning.com> wrote: > On Sun, May 11, 2014 at 06:03:24AM -0400, Kenneth Westerback wrote: >> On 11 May 2014 05:26, "Creamy" <cre...@dishplanning.com> wrote: >> > >> > Hello again! >> > >> > OK, this time it's a bug, (or is it a feature?), in dhclient. >> > >> > Imagine that you have two separate wireless networks, which operate >> > independently using the same private address spaces and offer leases >> > based on the same algorithm computed from the MAC address of the >> > client. >> > >> > For example: >> > >> > Network 1 - SSID foo, AP IP 192.168.64.1 netmask 255.255.255.0 >> > Network 2 - SSID bar, AP IP 192.168.64.1 netmask 255.255.255.0 >> > >> > But these are NOT connected in any way. They are two completely >> > different networks. E.G. 192.168.64.20, (by way of example), on >> > foo, is a different machine to 192.168.64.20 on bar. Maybe one >> > is your office network and one is a home network. >> > >> > Now, imagine that you have another machine, (probably a laptop), >> > which connects to either one, but never both at the same time. >> > >> > This machine is assigned an IP by DHCP when it joins either >> > network. The DHCP server assigns IPs based pseudo randomly based >> > on MAC address. >> > >> > If both networks use identical algorithms to calculate this IP, >> > then the laptop will be assigned the same IP regardless of the >> > network it joins. Imagine that it's assigned 192.168.64.10. >> > >> > This causes problems with dhclient, when you switch between >> > networks whilst a lease is still valid on the first one. It works, >> >> Whew. At least it works. > > Yes, it works quite well actually, the behavior I've noticed might not > even matter. > >> > but if you pass the -L option to dhclient, it doesn't produce the >> >> At last! Somebody using -L! > > Well, I use it to monitor exactly what's coming back from the DHCP > server when it's one that I don't trust :-). Call me paranoid, but > since the DHCP protocol supports much more than just assigning an IP > address lease, I like to see what the remote end is trying to do, > before it changes an obscure aspect of my networking configuration. > > (Although thankfully the current code doesn't implement the majority > of stupid things listed in tables.c). > >> > normal output, presumably because it believes that it's continuing >> > with an active lease. >> >> Possibly, since I believe you are saying the dhcp servers have the same IP >> or provide the same server id. dhclient currently has no way to detect that >> the nwid and only the nwid has changed. > > Well, it could notice differences in, for example, the > vendor-encapsulated-options string, which it currently ignores.
It already compares the contents of all options. Of which vendor-encapsulated-options is one, i.e. option 43. Any difference in length or detected by memcmp() would mean the leases are deemed not identical, compare_lease() fails and normal processing of a new lease proceeds. > >> > This causes problems with scripts. >> > >> > A script such as this: >> > >> > #!/bin/sh >> > ifconfig if0 nwid foo wpakey bar >> > sleep 3 >> > dhclient -L /output >> > cat /output >> > >> > fails with cat: /test: No such file or directory. >> >> This seems implausible. Why would cat complain about /test here? >> >> Assuming that's a typo, > > It was, sorry. cat: /output: No such file or directory. > >> can you provide some more details on what version >> of OpenBSD you have installed? > > Well I'm testing this on a 5.5-release box, but saw the same behavior with > 5.4-release. If you want to test the latest changes you need to be trying -current snapshots. > >> Some -L changes went in recently. There is >> also a race in your script since dhclient will not be guaranteed to have >> finished with /output before your cat runs. > > I realise that, but it's always used interactively by me, so it's not > critical in my case. > >> > dhclient needs to recognise that it is not just continuing with an >> > active lease, even though the new lease has the same parameters it >> > has come from a different dhcp server. >> >> Different how? Does it at least have a different MAC? > > Different MAC, with one server returning a random string in > vendor-encapsulated-options, and the other not returning anything. Then the leases are as different as they can be. You can validate this by tweaking the "bound to ..." message issued by bind_lease() when it has decided the leases are identical and the interface, routing table and resolv.conf do not need to be updated. > > My worry is that this might have side effects that I haven't noticed. Not sure what side effects you are thinking of. > > If the second server is evil in nature, can it take advantage in any way > that the client thinks that it's just maintaining an existing lease from > another server? If not, it doesn't matter. I can't see how an evil dhcp server could cause problems by tricking a dhclient into not deleting and adding the same address/subnet, same routes and same resolv.conf. At least any problems not caused by benign servers doing the same thing. .... Ken > > -- > Creamy! <3
