KDE has a very useful wifi hotspot feature, which I regularly use in places where I have to use a shared connection on two or three laptops. Sometimes, the hotspot cannot be enabled, reboot helps.
Situation
For example, laptop A would be hooked up to an ethernet cable (wifi may lose connection with too much wireless noise) and laptops B, C and a phone would then connect to the wifi hotspot provided by A. Another example might be a VPN tunnel on A, through which the other devices are then routed.
Symptom
After clicking “connect” in KDE’s network list (network icon on plasma panel), it almost immediately shows a popup saying that the hotspot has been deactivated, no reason given. After that, KDE picks one of the known wifi networks (if any) and connects to that instead.
Error
It seems that when it happens, an old dnsmasq process is preventing the wifi hotspot from creating its virtual interface. And unfortunately, this error message is not shown to the user - who would usually have to restart everything and be annoyed (“KDE not working again”). I took some time to dig through the system logs and found this:
NetworkManager[4051449]: <info> [1729583140.1888] device (wlp4s0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Started Wi-Fi Hotspot "iCable"
NetworkManager[4051449]: <info> [1729583140.1888] device (p2p-dev-wlp4s0): supplicant management interface state: disconnected -> completed
NetworkManager[4051449]: <info> [1729583140.2250] device (wlp4s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
NetworkManager[4051449]: <info> [1729583140.2756] dnsmasq-manager: starting dnsmasq...
NetworkManager[4051449]: <info> [1729583140.2795] device (wlp4s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
NetworkManager[39472]: dnsmasq: failed to create listening socket for 10.42.0.1: Address already in use
dnsmasq[39472]: failed to create listening socket for 10.42.0.1: Address already in use
NetworkManager[4051449]: <warn> [1729583140.2888] dnsmasq-manager: dnsmasq exited with error: Network access problem (address in use, permissions) (2)
dnsmasq[39472]: FAILED to start up
So apparently, it cannot create its virtual network interface because 10.42.0.1, which would be the ip of the hotspot is in use. However, no interface has that ip:
# ip a | grep -cF '10.42'
0
So it must be something else blocking that address and indeed, there’s a process which has a tcp connection listening on that address:
# netstat -ptan | grep -F '10.42'
tcp 0 0 10.42.0.1:53 0.0.0.0:* LISTEN 3765967/dnsmasq
Workaround
Since dnsmasq appears to get stuck, preventing the hotspot from creating its virtual interface because the hotspot ip is still in use, the workaround is to find that process and kill it. After killing it, a click on “connect” in KDE’s dropdown network list immediately connects. In my case, the KDE/Plasma panel froze again right before I could re-enable the hotspot - which unfortunately seems to happen a lot in F39/40 compared to older releases - so I ran pkill plasmashell; plasmashell --replace &
and then was able to open KDE’s network dropdown list to enable the hotspot. Don’t know if the panel froze because of that, but that’s another topic I guess.
This would also allow the VPN to be used again, if necessary (e.g., wg-quick, add iptables mtu fix for ssl to work on other devices, done).
Question
Why? I doubt dnsmasq is the culprit, but what is? Seems like some KDE component is sometimes losing control, though I’m not sure.
Comment
First I thought Bugzilla would be more appropriate but then I decided to write it up here and include the workaround, hoping it helps someone out there. If an admin thinks otherwise, let me know and I will delete this post.