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. > > 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. > 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. My worry is that this might have side effects that I haven't noticed. 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. -- Creamy! <3
pgpAr3xM17IAm.pgp
Description: PGP signature
