not getting same ip for same MAC

[Christopher Barry]

configs and leases file here:
https://pastebin.com/Fp7e8378

Problem:
I'm booting an embedded device via u-boot over tftp, and I am getting
one IP during boot, and another IP once Linux comes up. This has not
always done this, and I am struggling to find a solution.


Scenario:
I have a pool with 2 IPs in it, and I boot 2 devices in a test fixture.
Each device position (regardless of physical device) always gets the
same IP, as I am deleting the leases file / restarting dhcpd between
invocations of the test, and I power on the devices in the same order.

Now, device1 boots the tftp image, gets 172.19.0.2 (as it should), then
when Linux boots and requests an IP, it is getting 172.19.0.3 (which it
should NOT do). I have the lease time and max lease time set to 1 (but
I have set these values to many other values up to a couple minutes
with no change).

To be clear, this has worked for over a year, and suddenly is not
working. The Linux platform running dhcpd is centos 7. The dhcpd
version is in the pastebin link above.

NOTE:
In the leases file it can be seen that the uid value is different
between u-boot and linux, even though the MAC is the same. I'm
suspicious that this is what is confusing dhcpd.

How can I MAKE it only use MAC?


Thanks!

--
Regards,
Christopher
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Pavel Zhukov]

You can add into your dhclient.conf following statement:
send dhcp-client-identifier = hardware;
On Wed, Aug 8, 2018 at 5:05 PM Christopher Barry
<[hidden email]> wrote:

>
>
> configs and leases file here:
> https://pastebin.com/Fp7e8378
>
> Problem:
> I'm booting an embedded device via u-boot over tftp, and I am getting
> one IP during boot, and another IP once Linux comes up. This has not
> always done this, and I am struggling to find a solution.
>
>
> Scenario:
> I have a pool with 2 IPs in it, and I boot 2 devices in a test fixture.
> Each device position (regardless of physical device) always gets the
> same IP, as I am deleting the leases file / restarting dhcpd between
> invocations of the test, and I power on the devices in the same order.
>
> Now, device1 boots the tftp image, gets 172.19.0.2 (as it should), then
> when Linux boots and requests an IP, it is getting 172.19.0.3 (which it
> should NOT do). I have the lease time and max lease time set to 1 (but
> I have set these values to many other values up to a couple minutes
> with no change).
>
> To be clear, this has worked for over a year, and suddenly is not
> working. The Linux platform running dhcpd is centos 7. The dhcpd
> version is in the pastebin link above.
>
> NOTE:
> In the leases file it can be seen that the uid value is different
> between u-boot and linux, even though the MAC is the same. I'm
> suspicious that this is what is confusing dhcpd.
>
> How can I MAKE it only use MAC?
>
>
> Thanks!
>
> --
> Regards,
> Christopher
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

--
Pavel Zhukov
Software Engineer
IRC: landgraf
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Christopher Barry <[hidden email]> wrote:

> Problem:
> I'm booting an embedded device via u-boot over tftp, and I am getting
> one IP during boot, and another IP once Linux comes up.
...
> In the leases file it can be seen that the uid value is different
> between u-boot and linux, even though the MAC is the same.

This is a known issue. The DHCP spec requires that the Client ID (uid in the leases file) is used as the primary key in the lease database, the MAC address is not used at all if there is a Client ID provided.
There are 4 ways around this :
1) Just enlarge your pool
2) Use classes to make the u-boot and Linux use different pools. The booted Linux will then behave as you were used to. In a production environment, it can also be used to give the bootloader a short lease so that a smaller pool can be used.
3) Configure one or both clients so that they both use the same Client ID, or both use no Client ID
4) A long time ago someone wrote some patches - though I don't think they would be applicable to your case. IIRC the patches did something like "if there is no Client ID, add one using the MAC address" and were intended to deal with the known "Linux doesn't send a Client ID, Windows uses the MAC address" dual boot issue.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[perl-list]

This could also be interesting tho I don't know how it affects lease assignment for sure (from man dhcpd.conf):

The ignore-client-uids statement

ignore-client-uids flag ;

If the ignore-client-uids statement is present and has a value of true or on , the UID for clients will not be recorded.
If this statement is not present or has a value of false or off , then client UIDs will be recorded.

----- Original Message -----
> From: "Simon Hobson" <[hidden email]>
> To: "Users of ISC DHCP" <[hidden email]>
> Sent: Wednesday, August 8, 2018 1:40:49 PM
> Subject: Re: not getting same ip for same MAC

> Christopher Barry <[hidden email]> wrote:

> > Problem:
> > I'm booting an embedded device via u-boot over tftp, and I am getting
> > one IP during boot, and another IP once Linux comes up.
> ...
> > In the leases file it can be seen that the uid value is different
> > between u-boot and linux, even though the MAC is the same.

> This is a known issue. The DHCP spec requires that the Client ID (uid in the
> leases file) is used as the primary key in the lease database, the MAC address
> is not used at all if there is a Client ID provided.
> There are 4 ways around this :
> 1) Just enlarge your pool
> 2) Use classes to make the u-boot and Linux use different pools. The booted
> Linux will then behave as you were used to. In a production environment, it can
> also be used to give the bootloader a short lease so that a smaller pool can be
> used.
> 3) Configure one or both clients so that they both use the same Client ID, or
> both use no Client ID
> 4) A long time ago someone wrote some patches - though I don't think they would
> be applicable to your case. IIRC the patches did something like "if there is no
> Client ID, add one using the MAC address" and were intended to deal with the
> known "Linux doesn't send a Client ID, Windows uses the MAC address" dual boot
> issue.

> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

perl-list <[hidden email]> wrote:

> This could also be interesting tho I don't know how it affects lease assignment for sure (from man dhcpd.conf):
>
> The ignore-client-uids statement
>
> ignore-client-uids flag ;
>
> If the ignore-client-uids statement is present and has a value of true or on , the UID for clients will not be recorded.
> If this statement is not present or has a value of false or off , then client UIDs will be recorded.

Ah, I'd completely forgotten about that one. IIRC it provides exactly the non-RFC-compliant operation needed to work around the problem.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Gregory Sloop]

SH> perl-list <[hidden email]> wrote:

>> This could also be interesting tho I don't know how it affects lease assignment for sure (from man dhcpd.conf):

>> The ignore-client-uids statement

>> ignore-client-uids flag ;

>> If the ignore-client-uids statement is present and has a value of true or on , the UID for clients will not be recorded.
>> If this statement is not present or has a value of false or off , then client UIDs will be recorded.

SH> Ah, I'd completely forgotten about that one. IIRC it provides
SH> exactly the non-RFC-compliant operation needed to work around the problem.


Ok, Simon - you've had your one "I'd completely forgotten about that one" episode this century. Don't let it happen again! ;)
[I was totally impressed with your original reply, and found this "Oh, yeah...that..." amusing...]

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users