On 11 May 2014 07:00, Creamy <cre...@dishplanning.com> wrote: > On Sun, May 11, 2014 at 06:31:23AM -0400, Kenneth Westerback wrote: >> On 11 May 2014 06:03, Kenneth Westerback <kwesterb...@gmail.com> 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. >> > >> >> 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. > > Agreed. > >> >> > >> >> >> >> 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? > > Initially I only saw it in the situation I described above, where it occurs > almost all the time. But after testing, it happens occasionally if I just > start a new dhclient on the same interface connected to the same wlan. > > So, most likely it is a race, possibly a timing difference in the response > from the servers making one situation worse than the other with my setup. >
-current should be better at this if you want to try it. > I didn't realise at first that a new dhclient instance always polls the > DHCP server afresh, I thought it would use existing leases that had been > allocated and not expired. What happens if the dhcp server doesn't respond? > Do we re-use an old but not expired lease? > In theory. In practice I have a diff that will be committed soon that makes reusing such leases more reliable. .... Ken > -- > Creamy! <3