isc-dhcp-server 4.3.3-5ubuntu12.6 BOOTREPLY to wrong MAC address

[Teresa Remmet]

I am testing network boot on several embedded targets using BOOTP from the isc-dhcp-server package using Ubuntu 16.04.2.

The /etc/dhcp/dhcpd.conf I modified looks like this:

subnet 192.168.3.0 netmask 255.255.255.0
{
  # The filenames must correspond to the barebox and MLO files which are placed in the /tftpboot directory
  range dynamic-bootp 192.168.3.11 192.168.3.100;
  if substring (option vendor-class-identifier, 0, 10) = "AM335x ROM"
  {
    filename "MLO";
  }
  elsif substring (option vendor-class-identifier, 0, 18) = "am335x barebox-mlo"
  {
    filename "barebox.bin";
  }
  range 192.168.3.101 192.168.3.199;
}

Booting the first target does work out of the box with no issues:

Feb 16 09:11:38 lws-xxxx dhcpd[4259]: BOOTREPLY on 192.168.3.13 to 68:c9:0b:4a:3c:fe via enp5s2
Feb 16 09:11:46 lws-xxxx dhcpd[4259]: reuse_lease: lease age 63582 (secs) under 25% th
Feb 16 09:11:46 lws-xxxx dhcpd[4259]: BOOTREQUEST from 68:c9:0b:1c:74:8c via enp5s2

And then the booting works..

Trying to boot the second target (different board with different MAC) does not work any more:

Feb 16 09:16:12 lws-xxxx dhcpd[4259]: BOOTREQUEST from 68:c9:0b:1c:74:8c via enp5s2
Feb 16 09:16:12 lws-xxxx dhcpd[4259]: BOOTREPLY on 192.168.3.13 to 68:c9:0b:4a:3c:fe via enp5s2

The dhcp receives the request but replies to the MAC of the first target. I see the same when trying the third, forth target and so on. The dhcp always replies to the MAC of the first target.

This did work with the same configuration setup on Ubuntu 14.04.5 with 4.2.4-7ubuntu12.8.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Andreas Hilse (gnijieb)]

I can confirm the bug description.

Ubuntu 16.04.2 LTS
isc-dhcp-server 4.3.3-5ubuntu12.6

dhcpd.conf used:

subnet 192.168.255.0 netmask 255.255.255.0
{
   range dynamic-bootp 192.168.255.2 192.168.255.99;
   allow bootp;

   if substring (option vendor-class-identifier, 0, 10) = "AM335x ROM"
   {
      filename "barebox-mlo.img";
   }
   elsif substring (option vendor-class-identifier, 0, 10) = "am335x bar"
   {
      filename "barebox.img";
   }

   range 192.168.255.100 192.168.255.199;
}

Trying to boot the second target sends the BOOTREPLY to the MAC of the first target:
Mar 23 16:42:26 ubuntu dhcpd[30055]: BOOTREQUEST from 98:5d:ad:45:bf:4d via ens39
Mar 23 16:42:26 ubuntu dhcpd[30055]: BOOTREPLY on 192.168.255.2 to 98:5d:ad:45:65:bc via ens39

[Andreas Hilse (gnijieb)]

I dug a little deeper and could see that in our case the devices all use the same uid in the boot request, thus receiving the same ip address via dhcp.
I guess the failing bootreply comes from the still memorized mac address of the device before.

To get it working I used the option "ignore-client-uids on;" in the dhcpd.conf.

I can't tell if this issue is really a bug.

[Teresa Remmet (trmt)]

I have tried this, too. I added the option "ignore-client-uids on;" and deleted the lease file.
After restarting the server I could boot several targets. I also don't know if this is a bug or not.

[Sjors Gielen (sgielen)]

Can confirm this with DHCP instead of BOOTP as well:

Apr 19 17:51:48 curacao dhcpd[18031]: reuse_lease: lease age 671 (secs) under 25% threshold, reply with unaltered, existing lease
Apr 19 17:51:48 curacao dhcpd[18031]: DHCPDISCOVER from 08:00:27:44:28:00 via eth0
Apr 19 17:51:49 curacao dhcpd[18031]: DHCPOFFER on 192.168.0.60 to 08:00:27:04:2f:0f via eth0

Has this been reported upstream?