On Sun, May 11, 2014 at 06:52:51AM -0400, Kenneth Westerback wrote: > On 11 May 2014 06:38, Creamy <[email protected]> wrote: > > On Sun, May 11, 2014 at 06:03:24AM -0400, Kenneth Westerback wrote: > >> On 11 May 2014 05:26, "Creamy" <[email protected]> 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.
Oh, OK, excellent... So the situation I was worrying about doesn't exist. Sorry for the noise. I had assumed that the lack of output from -L indicated that it was recycling an old lease, but as you point out this isn't the case. > >> > 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. Sorry, I'm running with some custom changes to make some other hardware work on this box, and at the moment I haven't had time to update them for -current. > >> 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. OK. > > 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. I can't either, but then I'm not particularly familiar with the depths of dhcp. But at least we've identified a race with regards to the use of -L -- Creamy! <3
