Re: dhclient bug when joining new wireless lan

[bodie]

On 11.05.2014 13:10, Creamy wrote:
On Sun, May 11, 2014 at 06:52:51AM -0400, Kenneth Westerback wrote:
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.

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.

Mmm what hardware? It may be that it's supported in -current already 
and anyway for getting support inside OpenBSD for that hardware patch 
will need to be done against -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