On 11 May 2014 06:03, Kenneth Westerback <[email protected]> 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. > >> but if you pass the -L option to dhclient, it doesn't produce the > > At last! Somebody using -L! > >> 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.
Possibly, but it turns out not. Even if the lease is determined to be identical, the bind_lease() function will re-write the -L file by calling rewrite_option_db(). But even this is inapplicable in the situation you describe since your script starts a new dhclient, and it will not have a lease bound to the interface and will never conclude that it is responsible for the address in place. Thus it will do the full monty of deleting existing addresses and binding the lease it gets. > >> >> 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, can you provide some more details on what version of > OpenBSD you have installed? 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. There is also a conceivable race between the old and the new dhclient. One trying to truncate the file to indicate it has not configured an address and one trying to repopulate the file with new lease info. I haven't seen that in my testing. Are you saying the behaviour you report is consistent? Or occasional? .... Ken > >> >> 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? > > .... Ken > >> -- >> Creamy! <3 >>
