search

davesteele / comitup

Bootstrap Wifi support over Wifi
https://davesteele.github.io/comitup/
GNU General Public License v2.0
322 stars 54 forks source link

systemd-resolved is listening on port 53, too #51

Closed muelli closed 4 years ago

muelli commented 5 years ago

I have a fairly standard and small raspbian installation on a RPi3B+ and I have installed the latest comitup from the PPA.

Comitup starts, but the wifi clients don't get an IP. The log suggest that dnsmasq fails to start:

$ sudo systemctl status comitup
● comitup.service - Comitup Wifi Management
   Loaded: loaded (/lib/systemd/system/comitup.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-07-30 14:55:20 UTC; 1min 50s ago
     Docs: man:comitup(8)
 Main PID: 3141 (comitup)
    Tasks: 1 (limit: 2319)
   Memory: 11.8M
   CGroup: /system.slice/comitup.service
           └─3141 /usr/bin/python3 /usr/sbin/comitup

Jul 30 14:54:58 raspberry-find3-01 dnsmasq[3326]: FAILED to start up
Jul 30 14:54:59 raspberry-find3-01 comitup[3141]: dnsmasq: failed to create listening socket for port 53: Address already in use
Jul 30 14:54:59 raspberry-find3-01 dnsmasq[3328]: failed to create listening socket for port 53: Address already in use
Jul 30 14:54:59 raspberry-find3-01 dnsmasq[3328]: FAILED to start up
Jul 30 14:54:59 raspberry-find3-01 comitup[3141]: dnsmasq: failed to create listening socket for port 53: Address already in use
Jul 30 14:54:59 raspberry-find3-01 dnsmasq[3330]: failed to create listening socket for port 53: Address already in use
Jul 30 14:54:59 raspberry-find3-01 dnsmasq[3330]: FAILED to start up
Jul 30 14:55:01 raspberry-find3-01 comitup[3141]: OK
Jul 30 14:55:01 raspberry-find3-01 comitup[3141]: OK
Jul 30 14:55:20 raspberry-find3-01 systemd[1]: Started Comitup Wifi Management.

Would it be interesting to check whether dnsmasq started successfully?

Investigating the port usage it seems systemd-resolved is the culprit:

$ sudo netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name    
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      102        9197       201/systemd-resolve 
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          27092      3142/python3        
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      102        9204       201/systemd-resolve 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          12480      362/sshd            
tcp6       0      0 :::5355                 :::*                    LISTEN      102        9200       201/systemd-resolve 
tcp6       0      0 :::22                   :::*                    LISTEN      0          12482      362/sshd            
udp        0      0 0.0.0.0:33251           0.0.0.0:*                           107        12372      291/avahi-daemon: r 
udp        0      0 127.0.0.53:53           0.0.0.0:*                           102        9203       201/systemd-resolve 
udp        0      0 0.0.0.0:68              0.0.0.0:*                           0          13498      312/dhcpcd          
udp        0      0 169.254.110.128:123     0.0.0.0:*                           104        28177      351/ntpd            
udp        0      0 10.42.0.1:123           0.0.0.0:*                           104        25041      351/ntpd            
udp        0      0 192.168.5.161:123       0.0.0.0:*                           104        12889      351/ntpd            
udp        0      0 127.0.0.1:123           0.0.0.0:*                           0          11247      351/ntpd            
udp        0      0 0.0.0.0:123             0.0.0.0:*                           0          11243      351/ntpd            
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           107        12370      291/avahi-daemon: r 
udp        0      0 0.0.0.0:5355            0.0.0.0:*                           102        9196       201/systemd-resolve 
udp6       0      0 fe80::ba27:ebff:feb:123 :::*                                104        27966      351/ntpd            
udp6       0      0 fe80::bcb6:31fb:6d3:123 :::*                                104        14364      351/ntpd            
udp6       0      0 ::1:123                 :::*                                0          11249      351/ntpd            
udp6       0      0 :::123                  :::*                                0          11240      351/ntpd            
udp6       0      0 :::5353                 :::*                                107        12371      291/avahi-daemon: r 
udp6       0      0 :::5355                 :::*                                102        9199       201/systemd-resolve 
udp6       0      0 :::46971                :::*                                107        12373      291/avahi-daemon: r

After stopping that service I get an IP address with my WiFi client.

davesteele commented 5 years ago

Ok, so there is port contention for DHCP. I don't know why you see this and I don't.

Note that hotspot dhcp responsibility was moved from NetworkManager to Comitup in v1.6. If you have upgraded from v1.5, you need to manually remove the "dnsmasq sabotage" file stored under /etc/NetworkManager.

It will be a couple of weeks before I could investigate.

davesteele commented 5 years ago

Can you post the contents of your /etc/network/interfaces file? resolv.conf?

Have you edited resolved.conf or systemd.network?

muelli commented 5 years ago 
$ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

$ ls /etc/network/interfaces.d/
50-cloud-init.cfg

$ cat /etc/network/interfaces.d/50-cloud-init.cfg 
# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

I haven't edited those files.

I can send you image I run on the Raspberry Pi. Or my way of building the image (which is a bit convoluted).

davesteele commented 4 years ago

FWIW, the systemd-resolved service is disabled in a Comitup Raspbian image run.

I've added a note to the package install instructions to disable that service.

muelli commented 4 years ago

hm. would it be better to express that conflict in systemd terms with a Conflicts= stanza?

davesteele commented 4 years ago

Comitup already requires systemd.

muelli commented 4 years ago

Sure. What I'm wondering is whether the comitup.service unit file should have a Conflicts=systemd-resolved.service line.

davesteele commented 4 years ago

"Configures negative requirement dependencies. If a unit has a Conflicts= setting on another unit, starting the former will stop the latter and vice versa"

I'm not sure that's an improvement, but it's worth looking into someday.

muelli commented 4 years ago

it would then stop the offending service and allow comitup to run. Do you not see that as an improvement?

davesteele commented 4 years ago

Only if there is an assurance that the opposite doesn't happen.

marcelstoer commented 4 years ago

I've added a note to the package install instructions to disable that service.

That helps but a list of specific commands to run like e.g. here https://askubuntu.com/a/907249/980058 would be useful for the non-experts I guess.

muelli commented 4 years ago

I think what would really help is to express that conflict in terms of systemd, i.e. Conflicts=systemd-resolved.service

davesteele commented 4 years ago

In the general case, the two services are not incompatible - systemd-resolved can be configured to coexists. Thanks for pointing out the issue. #120 remains with the mitigations implemented.

muelli commented 4 years ago

In the general case [...]

sure. I guess I'm mostly interested in the default case, rather than a situation that you can end up with with manual intervention. That is, whatever ends up being the default configuration visible to the user based on what upstream ships (or maybe what distributions make out of it).

For my future self: here is another thing to consider to work around this bug: https://unix.stackexchange.com/a/304798/71928

davesteele commented 4 years ago

For additional future reference, the recommended "it just works" option is the Comitup iso image.