2

typically when I reserve an IP for a MAC addr the device when booting up and requesting a dhcp address, will pick up the address I reserved. However recently the request looks like it comes in but dhcp instead offers an address from a range and says "unknown lease". Is there something missing or not configured correctly? I'm pretty sure I factory-reset the camera several times so it's not hard-coded in there. Any other suggestions?

config file: /etc/dhcp/dhcpd.conf

}
## }}}
## {{{ IT::Devices (10.54.200.0/24)
subnet 10.54.200.0 netmask 255.255.255.0 {
  authoritative;
  option ntp-servers 10.54.25.110;
  option broadcast-address 10.54.200.255;
  option routers 10.54.200.1;
  pool {
    # WINS server address and info for microsoft win 3x,9x & NT
    option netbios-name-servers 10.54.25.75;
    option ntp-servers 10.54.25.110;
    option netbios-dd-server 10.54.25.75;
    option netbios-node-type 8;
    option domain-name-servers 10.54.25.110,10.54.25.110;
    range 10.54.200.35 10.54.200.40;
    #range dynamic-bootp 10.54.200.25 10.54.200.29;
    default-lease-time 345600;
    max-lease-time 518400;
    allow unknown clients;
  }

...

 host 040-cam-test {
    hardware ethernet 00:02:d1:01:10:73;
    fixed-address 10.54.200.60;
  }

tail -f /var/log/dhcpd/dhcpd.log | ccze -A | grep 10.54.200

Dec 10 11:39:31 DHCP01 dhcpd: DHCPOFFER on 10.54.200.60 to 00:02:d1:01:10:73 via 10.54.200.1
Dec 10 11:39:31 DHCP01 dhcpd: DHCPDISCOVER from 00:02:d1:01:10:73 (IP21x2-VVTK-0101c) via 10.54.200.1
Dec 10 11:39:31 DHCP01 dhcpd: DHCPREQUEST for 10.54.200.60 (10.54.25.75) from 00:02:d1:01:10:73 via 10.54.200.1
Dec 10 11:39:31 DHCP01 dhcpd: DHCPACK on 10.54.200.60 to 00:02:d1:01:10:73 via 10.54.200.1
Dec 10 11:39:31 DHCP01 dhcpd: DHCPREQUEST for 10.54.200.60 (10.54.25.75) from 00:02:d1:01:10:73 via 10.54.200.1: unknown lease 10.54.200.60.
Dec 10 11:39:32 DHCP01 dhcpd: DHCPOFFER on 10.54.200.37 to 00:02:d1:01:10:73 (IP21x2-VVTK-0101c) via 10.54.200.1

/var/lib/dhcp/dhcpd.leases ...

lease 10.54.200.37 {
  starts 4 2015/12/10 18:32:44;
  ends 4 2015/12/10 18:35:10;
  tstp 4 2015/12/10 18:35:10;
  cltt 4 2015/12/10 18:32:44;
  binding state free;
  hardware ethernet 00:02:d1:01:10:73;
  uid "\001\000\002\321\001\020s";
}

2 Answers 2

2

There was a rogue dhcpd process running, so the device was receiving too many responses. This was because the service was restarted several times using the command:

/etc/init.d/isc-dhcp-server restart

Instead I need to restart dhcpd using:

sudo service isc-dhcp-server restart
0

I had a similar issue on my RPi 1 running Raspbian 8. I am running isc-dhcp-server.

Instead of giving a machine the statically configured DHCP IP address of 192.168.1.8 for the MAC address, it instead said that that lease was unknown and offered it something in the dynamic range I had set, e.g. 192.168.1.201. But even with that IP address, things still did not work properly, and often the client machine would have no IP address configured when I checked it.

Eventually I read the bottom posts in this link: https://ubuntuforums.org/archive/index.php/t-1575290.html

On checking my server I found that I had another dhcp process running (ps -elf | grep dhcp), which was called dhcpcd5, but that is a client (https://packages.debian.org/search?keywords=dhcpcd)

This is the apt log of what I did (the two packages I removed):

cat /var/log/apt/history.log

Start-Date: 2017-11-13  20:28:38
Remove: raspberrypi-net-mods:armhf (1.2.5), dhcpcd5:armhf (6.7.1-1+rpi5)
End-Date: 2017-11-13  20:28:52

After I had uninstalled the dhcpcd5 package (and the raspberrypi-net-mods package that was dependent on it) I found that my DHCP system was working wonderfully for all my client machines and the server logs stopped saying that leases were unknown for the fixed addresses for dhcp clients such as 192.168.1.8 that is mapped to specific a MAC address in /etc/dhcp/dhcpd.conf

The dhcp server even started to give out DHCPNAK messages to clients to undo the harm done previously, i.e. to reject the request of 192.168.1.201 to the machine with the MAC address that had 192.168.1.8 reserved for it in my dhcp server, and then it correctly offered it 192.168.1.8.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .