Hello,

I have some problems when doing a network install with the kernel and
initrd in the netboot.tar.gz package in 20110106+squeeze3.

I have a local dhcp-server with an address pool configured. After I have
booted into the installer and selected configure with dhcp the lease
file on the server looks like this:

lease 10.0.0.11 {
starts 3 2011/09/28 07:36:42;
ends 3 2011/09/28 11:36:42;
cltt 3 2011/09/28 07:36:42;
binding state active;
next binding state free;
hardware ethernet 00:30:48:f9:5b:22;
uid "01000H371["";
}

When the install is done and I have rebooted the server the dhcp-server
gives the newly installed server another address then during the
install, so know it looks like this:

lease 10.0.0.11 {
starts 3 2011/09/28 07:36:42;
ends 3 2011/09/28 11:36:42;
cltt 3 2011/09/28 07:36:42;
binding state active;
next binding state free;
hardware ethernet 00:30:48:f9:5b:22;
uid "01000H371["";
}
lease 10.0.0.12 {
starts 3 2011/09/28 07:43:50;
ends 3 2011/09/28 11:43:50;
cltt 3 2011/09/28 07:43:50;
binding state active;
next binding state free;
hardware ethernet 00:30:48:f9:5b:22;
}

I assume the reason is that the dhcp-client on the installed server does
not send uid (is this the client-identifier?)

I have tried setting the keyword duplicates to both allow and deny
without any success. From what I can tell duplicates makes the
dhcp-server ignore the UID, which is exactly what I want. Am I using it
wrong or is there some bug here?

This used to work fine with lenny so assume something has changed with
the dhcp-client in the installer for squeeze.

If I can not fix the dhcp-server to behave correctly can I modify the
initrd to make the dhcp-client in the installer to not send an UID?

All help is appreciated!

/Nico

--
Niklas Jakobsson - SysAdmin @ Netnod
mailto:nico@netnod.se


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1317197062.2889.14.camel@iego.netnod.se">http://lists.debian.org/1317197062.2889.14.camel@iego.netnod.se

On Wed, 28 Sep 2011 10:04:22 +0200, Niklas Jakobsson wrote:

(...)

> I have tried setting the keyword duplicates to both allow and deny
> without any success.

I think it should be "deny duplicates;" in this case.

> From what I can tell duplicates makes the
> dhcp-server ignore the UID, which is exactly what I want. Am I using it
> wrong or is there some bug here?

Mmm... man page (man 5 dhcp.conf) says this stanza can work with either
client UID "and/or MAC" address...

***
Host declarations can match client messages based on the DHCP Client
Identifer option or based on the client's network hardware type and MAC
address. If the MAC address is used, (...)
***

... okay, so I wonder how can you tell your dhcp server to use the MAC
address instead the UID to identify the client request because the man
page does not seem to provide any clue over it :-?

I say this because it seems the client is sending the UID at install time
but not once the system boots so maybe this is what confuses the dhcp
server ("same MAC address but differenet UID → give that client another
lease").

> This used to work fine with lenny so assume something has changed with
> the dhcp-client in the installer for squeeze.
>
> If I can not fix the dhcp-server to behave correctly can I modify the
> initrd to make the dhcp-client in the installer to not send an UID?

There is also the "one-lease-per-client" flag, you could try by setting
this to "on", although I'm not sure if it will work.

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2011.09.28.16.23.29@gmail.com">http://lists.debian.org/pan.2011.09.28.16.23.29@gmail.com

On ons, 2011-09-28 at 16:23 +0000, Camaleón wrote:
> On Wed, 28 Sep 2011 10:04:22 +0200, Niklas Jakobsson wrote:
>
> (...)
>
> > I have tried setting the keyword duplicates to both allow and deny
> > without any success.
>
> I think it should be "deny duplicates;" in this case.
>
> > From what I can tell duplicates makes the
> > dhcp-server ignore the UID, which is exactly what I want. Am I using it
> > wrong or is there some bug here?
>
> Mmm... man page (man 5 dhcp.conf) says this stanza can work with either
> client UID "and/or MAC" address...
>
> ***
> Host declarations can match client messages based on the DHCP Client
> Identifer option or based on the client's network hardware type and MAC
> address. If the MAC address is used, (...)
> ***
>
> ... okay, so I wonder how can you tell your dhcp server to use the MAC
> address instead the UID to identify the client request because the man
> page does not seem to provide any clue over it :-?
>
> I say this because it seems the client is sending the UID at install time
> but not once the system boots so maybe this is what confuses the dhcp
> server ("same MAC address but differenet UID → give that client another
> lease").
>
> > This used to work fine with lenny so assume something has changed with
> > the dhcp-client in the installer for squeeze.
> >
> > If I can not fix the dhcp-server to behave correctly can I modify the
> > initrd to make the dhcp-client in the installer to not send an UID?
>
> There is also the "one-lease-per-client" flag, you could try by setting
> this to "on", although I'm not sure if it will work.
>
> Greetings,
>
> --
> Camaleón
>
>

Thanks for your answer.

I have tried both "deny duplicates" (again) and one-lease-per-client,
none of the seems to do the trick.

/Nico

--
Niklas Jakobsson - SysAdmin @ Netnod
mailto:nico@netnod.se


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1317277949.2889.22.camel@iego.netnod.se">http://lists.debian.org/1317277949.2889.22.camel@iego.netnod.se

I found this post to the dhcp-users mailing list:
https://lists.isc.org/pipermail/dhcp-users/2011-July/013440.html

It adds a new option ignore-client-uids to dhcpd. I applied the patch
and recompiled my dhcp-server and it works exactly as intended.

So, my problem is solved...

/Nico

--
Niklas Jakobsson - SysAdmin @ Netnod
mailto:nico@netnod.se


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1317285122.2889.30.camel@iego.netnod.se">http://lists.debian.org/1317285122.2889.30.camel@iego.netnod.se

On Thu, 29 Sep 2011 10:32:02 +0200, Niklas Jakobsson wrote:

> I found this post to the dhcp-users mailing list:
> https://lists.isc.org/pipermail/dhcp-users/2011-July/013440.html

W-o-w... that's incredible.

So it is not working even in the upstream dhcpd? :-o

> It adds a new option ignore-client-uids to dhcpd. I applied the patch
> and recompiled my dhcp-server and it works exactly as intended.
>
> So, my problem is solved...

Good to know, and thanks for posting the above URI and confirming the
patch works. What scares me is to see no replies to the user who posted
the message on the dhcpd mailing list...

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2011.09.29.13.45.20@gmail.com">http://lists.debian.org/pan.2011.09.29.13.45.20@gmail.com

Camaleón wrote:
> Niklas Jakobsson wrote:
> > I found this post to the dhcp-users mailing list:
> > https://lists.isc.org/pipermail/dhcp-users/2011-July/013440.html
>
> W-o-w... that's incredible.
> So it is not working even in the upstream dhcpd? :-o

It may be unintuitive but ignoring client identifier is incorrect.
That is why patching to do so isn't accepted upstream. Ignoring
client identifier violates the protocol. See RFC 2131.

Now that doesn't mean that in restricted cases it isn't beneficial to
violate some protocols. I violate protocols! (I want that tshirt by
the way. :-) Expecially when it suits me. But it does prevent it
from being general purpose and certainly should not be the default.

A typical suggestion for people provisioning a large number of systems
would be to identify PXE clients using vendor-class-identifier and
assign those a short lease time so that those addresses expire quickly
to keep from depleting the pool.

> > It adds a new option ignore-client-uids to dhcpd. I applied the patch
> > and recompiled my dhcp-server and it works exactly as intended.
> >
> > So, my problem is solved...
>
> Good to know, and thanks for posting the above URI and confirming the
> patch works. What scares me is to see no replies to the user who posted
> the message on the dhcpd mailing list...

Search for Yedidyah Bar-David (aka Didi) single lease dhcp patch and
you should get to various discussions going back several years. This
isn't a new topic. It comes up periodically concerning booting
multiple different operating systems and having each system assigned
its own address.

Bob

On Thu, 29 Sep 2011 13:39:06 -0600, Bob Proulx wrote:

> Camaleón wrote:
>> Niklas Jakobsson wrote:
>> > I found this post to the dhcp-users mailing list:
>> > https://lists.isc.org/pipermail/dhcp-users/2011-July/013440.html
>>
>> W-o-w... that's incredible.
>> So it is not working even in the upstream dhcpd? :-o
>
> It may be unintuitive but ignoring client identifier is incorrect. That
> is why patching to do so isn't accepted upstream. Ignoring client
> identifier violates the protocol. See RFC 2131.

Yes, I guess that's what man page also warns about, so what's the point
in adding a setting that in the end cannot be honored? :-?

***
The duplicates flag tells the DHCP server that if a request is received
from a client that matches the MAC address of a host declaration, any
other leases matching that MAC address should be discarded by the
server, even if the UID is not the same. This is a violation of the
DHCP protocol, but can prevent clients whose client identifiers change
regularly from holding many leases at the same time. By default,
duplicates are allowed.
***

I mean, the patch is aimed to solve something that is currently there but
is not working or did I miss something?

> Now that doesn't mean that in restricted cases it isn't beneficial to
> violate some protocols. I violate protocols! (I want that tshirt by
> the way. :-)

Maybe at "thinkgeek.com"? ;-)

> Expecially when it suits me. But it does prevent it from
> being general purpose and certainly should not be the default.

If I read the man page correctly, it certainly is not the default but the
option is available for specific sitations.

> A typical suggestion for people provisioning a large number of systems
> would be to identify PXE clients using vendor-class-identifier and
> assign those a short lease time so that those addresses expire quickly
> to keep from depleting the pool.

I agree there has to be a better/another way to get the job done.

>> > It adds a new option ignore-client-uids to dhcpd. I applied the patch
>> > and recompiled my dhcp-server and it works exactly as intended.
>> >
>> > So, my problem is solved...
>>
>> Good to know, and thanks for posting the above URI and confirming the
>> patch works. What scares me is to see no replies to the user who posted
>> the message on the dhcpd mailing list...
>
> Search for Yedidyah Bar-David (aka Didi) single lease dhcp patch and you
> should get to various discussions going back several years. This isn't
> a new topic. It comes up periodically concerning booting multiple
> different operating systems and having each system assigned its own
> address.

Hum... I was not aware this was part of that well-know-discussed issues,
but regardless its "awareness status", is something that should addressed
at dhcp mailing list. I think is a valid concern for users and they
deserve a proper response, whatever it be.

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2011.09.29.20.16.54@gmail.com">http://lists.debian.org/pan.2011.09.29.20.16.54@gmail.com

Camaleón wrote:
> Bob Proulx wrote:
> > It may be unintuitive but ignoring client identifier is incorrect. That
> > is why patching to do so isn't accepted upstream. Ignoring client
> > identifier violates the protocol. See RFC 2131.
>
> Yes, I guess that's what man page also warns about, so what's the point
> in adding a setting that in the end cannot be honored? :-?

What do you mean, cannot be honored? Why can't it be honored? And in
fact it does honor it. It works exactly as described. (confused)

> ***
> The duplicates flag tells the DHCP server that if a request is received
> from a client that matches the MAC address of a host declaration, any
> other leases matching that MAC address should be discarded by the
> server, even if the UID is not the same. This is a violation of the
> DHCP protocol, but can prevent clients whose client identifiers change
> regularly from holding many leases at the same time. By default,
> duplicates are allowed.
> ***

Wow. It is now an option in the upstream as "deny duplicates;". I
did not know it was now available there as an upstream option. I will
have to try it and see how it works!

But frankly I have never needed it. There are a large number of
private addresses available. I have just always made sure I had a
large enough pool that it did not matter.

A brief search turned up this reference that describes some problems
with ignoring the client identifier and the workarounds they
implemented in order to workaround the workarounds.

http://www.net.princeton.edu/announcements/dhcp-cliid-must-match-chaddr.html

I think it is better simply to have enough IP addresses in the pool
and then not worry about it.

> I mean, the patch is aimed to solve something that is currently there but
> is not working or did I miss something?

Actually it was I who did not realize that the patch is now in the
upstream as "deny duplicates". And not knowing about it I haven't
tried it. Will need to test it.

> Hum... I was not aware this was part of that well-know-discussed issues,
> but regardless its "awareness status", is something that should addressed
> at dhcp mailing list. I think is a valid concern for users and they
> deserve a proper response, whatever it be.

I admit to not knowing but it seems to me that the response must have
been the addition of "deny duplicates;". Assuming that does what it
says it does in the documentation.

Bob