Error: I/O Error in DHCP: Address already in use (os error 98)

[stappersg]

Hi,

Here a progress report from my exploring erbium expedition ;-).

I'm stuck at

Error: I/O Error in DHCP: Address already in use (os error 98)

But I don't understand that fatal error message.

With sudo strace target/debug/erbium I can see

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 15
bind(15, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 \
  EADDRINUSE (Address already in use)
close(15) 

With ss -n | grep :67 I did found a dhcp client, but after switching network configuration of my Linux laptop to static config, the error persists.

What should be done to get beyond the EADDRINUSE?

[isomer]

Hmm. This is saying that something is already using that port. What does ss -nulp | grep :67 say? It should list the process name/pids of things that have that port already open.

[stappersg]

Yes, the l of listen makes the difference.

$ sudo ss -n | grep :67
$ sudo ss -nl | grep :67 | sed -e 's/    / /g'
udp   UNCONN 0   0                         0.0.0.0%virbr0:67       0.0.0.0:*     
udp   UNCONN 0   0                         0.0.0.0%ovsbr0:67       0.0.0.0:*     
$ 

Silly me.

Running the request test:

$ sudo ss -nulp | grep :67 | sed -e 's/    / /g'
UNCONN 0   0           0.0.0.0%virbr0:67   0.0.0.0:* users:(("dnsmasq",pid=1621,fd=3))   
UNCONN 0   0           0.0.0.0%ovsbr0:67   0.0.0.0:* users:(("dnsmasq",pid=1393,fd=4))  

That indeed does explain the EADDRINUSE. Now how to get beyond it 😃

dnsmasq does bind on interface name and each dnsmasq only claims one interface.

To get ( to trick? ) erbium to only use eth0 I have in erbium.conf this line

  addresses: [ 172.24.0.37/26 ]

because

$ ip -4 address show dev eth0
7: enxe4b97a90028f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 172.24.0.37/26 brd 172.24.0.63 scope global noprefixroute enxe4b97a90028f
       valid_lft forever preferred_lft forever

I think the strace shown

bind(15, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("0.0.0.0")}, 16)

should become something like

bind(15, {sa_family=AF_INET, sin_port=htons(67), sin_addr=inet_addr("172.24.0.37")}, 16)

to honor

  addresses: [ 172.24.0.37/26 ]

from erbium.conf.

[isomer]

erbium, currently, always listens on 0.0.0.0. I want to support interfaces coming and going without needing to restart erbium, as well as erbium dropping permissions (which, to be fair, it doesn't do at the moment), so it wouldn't be able to start listening on a new interface after startup.

I could, I guess, add a "dhcp-listen-addresses: [192.0.2.1]" or similar for people who specifically don't want it to listen on all interfaces.

[stappersg]

FWIW:

• When an interface goes, it is fine that it takes erbium with it.
• I have no idea how network daemons should cope with bouncing interfaces, but I fear the idea of a running network daemon that is unaware of a returned network interface.
• Listening on 1 interface will allow running various erbium instances for various interfaces.

[stappersg]

Listening on 1 interface will allow running various erbium instances for various interfaces.

is to express that

I could, I guess, add a "dhcp-listen-addresses: [192.0.2.1]" or similar for people who specifically don't want it to listen on all interfaces

is indeed a solution to Error: I/O Error in DHCP: Address already in use (os error 98)

[isomer]

I've given this quite a bit of thought over the last few weeks, trying to figure out the right balance.

• Do I have a global listen-addresses (or possibly listen-interfaces) for all protocols? Or do I have a per protocol dhcp-listen-addresses / radv-listen-addresses / dns-listen-addresses (or their equivalent ${protocol}-listen-interfaces)? Or both? What should the semantics be if you, say, specify listen-interface: ['eth0'] and dhcp-listen-address: 192.0.2.1? Are you interested in listening on an interface, or listening on an address?

• Having one erbium process process per interface is a bit odd when I finish up the DNS support, as you'll end up with an unique DNS cache per interface. Is this the right thing to do?

• I still would like to make it that you can (although don't necessarily have to) start erbium before an interface is available, and let erbium handle the interface coming and going.