isc-dhcp-server fails if interface not connected on reboot

Question

On Ubuntu 18.04 on my gateway server, I've installed and configured isc-dhcp-server, but it doesn't start up (i.e. it fails to start) if there's nothing connected to enp2s0 after a reboot.

Note it says "Not configured to listen on any interfaces!"

$ service isc-dhcp-server status
● isc-dhcp-server.service - ISC DHCP IPv4 server
   Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2020-01-18 19:05:34 GMT; 1s ago
     Docs: man:dhcpd(8)
  Process: 3475 ExecStart=/bin/sh -ec      CONFIG_FILE=/etc/dhcp/dhcpd.conf;      if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; fi;      [ -e /var/lib/dhcp/dhcpd.leases ] || touch /v
 Main PID: 3475 (code=exited, status=1/FAILURE)

Jan 18 19:05:34 user-Default-string dhcpd[3475]:
Jan 18 19:05:34 user-Default-string dhcpd[3475]: Not configured to listen on any interfaces!
Jan 18 19:05:34 user-Default-string dhcpd[3475]:
Jan 18 19:05:34 user-Default-string dhcpd[3475]: If you think you have received this message due to a bug rather
Jan 18 19:05:34 user-Default-string dhcpd[3475]: than a configuration issue please read the section on submitting
Jan 18 19:05:34 user-Default-string dhcpd[3475]: bugs on either our web page at www.isc.org or in the README file
Jan 18 19:05:34 user-Default-string dhcpd[3475]: before submitting a bug.  These pages explain the proper
Jan 18 19:05:34 user-Default-string dhcpd[3475]: process and the information we find helpful for debugging..
Jan 18 19:05:34 user-Default-string dhcpd[3475]:
Jan 18 19:05:34 user-Default-string dhcpd[3475]: exiting.

My gateway server has two ethernet ports, enp1s0, and enp2s0. I use enp1s0 for internet access via a router, and enp2s0 simply for serving a web app to ethernet-connected laptops. enp2s0 is the one for which the DHCP server assigns IP addresses (for the laptops needing the web app). I want enp1s0 to get a random IP address from the internet-conneted router on the 192.168.1.0 subnet, so that interface is not managed by isc-dhcp-server, only enp2s0.

Here's "ip route" with nothing connected to enp2s0, if that might help...

$ ip route
default via 192.168.1.254 dev enp1s0 proto dhcp metric 100
169.254.0.0/16 dev enp1s0 scope link metric 1000
192.168.1.0/24 dev enp1s0 proto kernel scope link src 192.168.1.76 metric 100

Here's my dhcpd.conf setup:

default-lease-time 600;
max-lease-time 7200;

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# This is a very basic subnet declaration.    
subnet 192.168.2.0 netmask 255.255.255.0 {
  range 192.168.2.200 192.168.2.250;
  # option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
  option broadcast-address 192.168.2.255;
}

Here's my isc-dhcp-server setup:

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#       Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACESv4="enp2s0"
INTERFACESv6=""

One solution is to restart the isc-dhcp-server after plugging a laptop into enp2s0, but I don't want to have to do that after every reboot, or every time someone plugs in a laptop to enp2s0. The DHCP server works after restarting the service...

$ sudo service isc-dhcp-server restart
$ service isc-dhcp-server status
● isc-dhcp-server.service - ISC DHCP IPv4 server
   Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-01-18 18:22:01 GMT; 14min ago
     Docs: man:dhcpd(8)
 Main PID: 2437 (dhcpd)
    Tasks: 1 (limit: 2016)
   CGroup: /system.slice/isc-dhcp-server.service
           └─2437 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf enp2s0

Any ideas? I'm sure there's a configuration thing I'm missing, that will solve this problem...

EDIT: Output from command "nmcli connection show lan" (AKA: nmcli c s lan)

$ nmcli connection show lan

connection.id:                          lan
connection.uuid:                        96fbb458-1178-4af2-a1b7-ccce301176e0
connection.stable-id:                   --
connection.type:                        802-3-ethernet
connection.interface-name:              enp2s0
connection.autoconnect:                 yes
connection.autoconnect-priority:        0
connection.autoconnect-retries:         -1 (default)
connection.auth-retries:                -1
connection.timestamp:                   1579379514
connection.read-only:                   no
connection.permissions:                 --
connection.zone:                        --
connection.master:                      --
connection.slave-type:                  --
connection.autoconnect-slaves:          -1 (default)
connection.secondaries:                 --
connection.gateway-ping-timeout:        0
connection.metered:                     unknown
connection.lldp:                        default
connection.mdns:                        -1 (default)
802-3-ethernet.port:                    --
802-3-ethernet.speed:                   0
802-3-ethernet.duplex:                  --
802-3-ethernet.auto-negotiate:          no
802-3-ethernet.mac-address:             --
802-3-ethernet.cloned-mac-address:      --
802-3-ethernet.generate-mac-address-mask:--
802-3-ethernet.mac-address-blacklist:   --
802-3-ethernet.mtu:                     auto
802-3-ethernet.s390-subchannels:        --
802-3-ethernet.s390-nettype:            --
802-3-ethernet.s390-options:            --
802-3-ethernet.wake-on-lan:             default
802-3-ethernet.wake-on-lan-password:    --
ipv4.method:                            manual
ipv4.dns:                               --
ipv4.dns-search:                        --
ipv4.dns-options:                       ""
ipv4.dns-priority:                      0
ipv4.addresses:                         192.168.2.2/24
ipv4.gateway:                           --
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   no
ipv4.dhcp-client-id:                    --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.never-default:                     no
ipv4.may-fail:                          yes
ipv4.dad-timeout:                       -1 (default)
ipv6.method:                            auto
ipv6.dns:                               --
ipv6.dns-search:                        --
ipv6.dns-options:                       ""
ipv6.dns-priority:                      0
ipv6.addresses:                         --
ipv6.gateway:                           --
ipv6.routes:                            --
ipv6.route-metric:                      -1
ipv6.route-table:                       0 (unspec)
ipv6.ignore-auto-routes:                no
ipv6.ignore-auto-dns:                   no
ipv6.never-default:                     no
ipv6.may-fail:                          yes
ipv6.ip6-privacy:                       -1 (unknown)
ipv6.addr-gen-mode:                     stable-privacy
ipv6.dhcp-send-hostname:                yes
ipv6.dhcp-hostname:                     --
ipv6.token:                             --
proxy.method:                           none
proxy.browser-only:                     no
proxy.pac-url:                          --
proxy.pac-script:                       --

EDIT2: Added output from "nmcli -f name,autoconnect connection show"

$ nmcli -f name,autoconnect connection show
NAME                AUTOCONNECT
Wired connection 1  yes
lan                 yes

EDIT3: Added output from "cat /etc/NetworkManager/system-connections/lan"

[connection]
id=lan
uuid=96fbb458-1178-4af2-a1b7-ccce301176e0
type=ethernet
interface-name=enp2s0
permissions=
timestamp=1579379263

[ethernet]
mac-address-blacklist=

[ipv4]
address1=192.168.2.2/24
dns-search=
method=manual

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

Answer 1

Is the interface (enp2s0) up at all ? It needs to have an ipv4 address added and then started (up)

It shouldn't matter if any clients is connected to the hub/switch.

Edit: Network Manager ?

I hate that thing with a passion, but either way: if the iface isn't up with a correct address dhcpd wont start, so you need to figure out how to with nmcli create a static configuration which is always up.

Edit: What shows this ?

nmcli connection show lan

The connection.autoconnection property is interesting.

Edit: What shows this:

  nmcli -f name,autoconnect connection show

Ok, what is the status

  nmcli -f name,autoconnect connection show

after reboot without your hack ? The autoconnect property should be enough to bring up the interface... not knowing why somethings fails in something which is basically very simple is one of my dislikes about NetworkManager (to much complexity for unknown benefits, i see the point for clients which is constantly on the move but servers which must simply work??)

Edit: any files in etc/NetworkManger/system-connections ? That is at least how i configured the devices in my system (it is a bridged config), so i do use NetworkManager to bring up the machine. The machine is host for three guests so the enp1s0 device is a slave.

Edit: what happens if you define the lan device (remove it completely first) ie something like:

nmcli connection down lan 
nmcli connection delete lan
nmcli connection add type ethernet ifname enp2s0 con-name lan autoconnect on
nmcli connection modify lan   ipv4.method manual ipv4.addresses 192.168.2.2/24 
nmcli connection lan up

Answer 2

IN CASE IT HELPS ANYONE I've just been right through this exasperating issue, on DietPi (Debian Buster) on a Pi Zero W and HAVE BOTTOMED THE PROBLEM.

isc-dhcp-server is excellent but DOES HAVE this quirk, as noted by the original enquirer above. I've bottomed the problem - it's not a bug - and this is the detail of the reason:

1. isc-dhcp-server refuses (throws an error) if it cannot see an UP ethernet network subnet at launch time; it DOESN'T (contrary to some commentators) require an actual connection TO the ethernet port to which it is associated.

2. When developing a WiFi Hotspot device, its normally a case of using hostapd as the AP server function (which re-configures the WiFi hardware to switch to AP mode) and alongside hostapd, you need a dhcp server like isc-dhcp-server to provide the IP address leasing service.

3. SO: normally the start point, is a WiFi device which at boot, was configured as a CLIENT device, but needs to be switched to HOST mode to act as hotspot. So an early step is to set wlan0 (or whatever) DOWN, prior to launching hostapd.

BUT that situation, is immediately one of those which isc-dhcp-server does not like: if you try to start it before hostapd, it will fail, complaining that there is no subnet for it to listen on.

4. So you may innocently then try, adding a new IP address (for the host) to your wlan0 (or equiv) and re-trying: THAT WON'T WORK EITHER, because although you now have a new IP attached to the Ethernet port, you will also find you cannot set it 'UP' (ip link set wlan0 up will FAIL). This is because the port is 'tainted' by the still-active stale address and the wpa-supplicant process which was using it.

5. LONG STORY SHORT: you need to kill wpa-supplicant, to "free" the old address / FLUSH the ip settings for the port / THEN add the new IP address for host ; EVEN THEN, you'll find isc-dhcp-server STILL won't start, because you can't set the interface up - yet. Finally - run hostapd now, before isc, and IT will (in reconfiguring the chipset) also SET the wlan0 interface, to UP. So now - finally - you CAN run isc-dhcp-server, and it will start cleanly, and your hotspot will be up.

It's taken me about five hours, I hope this saves someone some time. My distilled note:

SORTING ISC-DHCP-SERVER alongside HOSTAPD: THE SOLUTION

YOU HAVE TO follow THIS SEQUENCE:

1. KILL the wpa-supplicant process (that's sustaining the client conn) this way:

    kill -2  $( cat /run/wpa_supplicant.wlan0.pid )
   
    sleep 1
   
    kill -9  $( cat /run/wpa_supplicant.wlan0.pid )
   

2. FLUSH the WLAN IP setup, using:

   ip addr flush dev wlan0
   

3. ADD the new host IP ADDRESS, using:

   ip addr add 10.1.1.1/24 dev wlan0
   

4. START hostapd, which will also put wlan0 UP:

    /usr/sbin/hostapd /etc/hostapd/hostapd.conf &
   

5. START isc-dhcp-server ( WLAN is up, as host now ):

    sudo service isc-dhcp-server restart
   

THEN the Access Point should be UP and ready to accept clients.

Those are my addresses of course / edit to suit your need.

TWO MORE TIPS: Config files hostapd.conf and dhcp.conf can drive you mad also: -here are working samples. IMPORTANT: do not sweat the 'drivername' in hostapd.conf: it's not needed. 'Commented out' is fine:

hostapd.conf

interface=wlan0

#driver=brcmfmac

ssid=THIS-IS-MY-AP

country_code=US

hw_mode=g

channel=6

macaddr_acl=0

auth_algs=1

ignore_broadcast_ssid=0

wpa=2

wpa_passphrase=12345678

wpa_key_mgmt=WPA-PSK

wpa_pairwise=CCMP

wpa_group_rekey=86400

ieee80211n=1

wme_enabled=1

dhcpd.conf

# COMMENT OUT BOTH OF THE TEMPLATES' 'option domain..' lines.. 
# then ADD THIS AT BOTTOM
#
#
subnet 10.1.1.0 netmask 255.255.255.0 {
        range 10.1.1.100 10.1.1.109;
        option broadcast-address 10.1.1.255;
        option routers 10.1.1.1;
        default-lease-time 600;
        max-lease-time 7200;
        option domain-name "mynetwork.org";
        option domain-name-servers 8.8.8.8, 8.8.4.4;
}
#
#

Though this work on Pi it was on DietPi which is straight Debian, so this same advice should suit many Linuxes, including Ububtus of many flavours.

GOOD LUCK ALL

Answer 3

Unless there's a better solution, for now this works for me: When my web app starts, the first two things it does are:

1. sudo nmcli conn up lan ('lan' is the NetworkManager connection name assigned to enp2s0)
2. sudo service isc-dhcp-server restart

The web app is cron-scheduled to start @reboot, so NetworkManager has started by that point.

isc-dhcp-server always fails if enp2s0 isn't yet "up", so I have to set it "up", and then restart the isc-dhcp-server service. It's not very elegant, but it does the job for now.