KDE wifi hotspot randomly not working, cannot be enabled due to stuck dnsmasq

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.

I think the topic is very appropriate though I have never tried your scenario so have no concrete advice.

You did mention vpn and that dns seems to be using the 10.42 address, which it could not without the address already being available. This may be a race condition between activating the hot spot interface and enabling dns for that hot spot.

Why not simply use ip a and peruse the full config without the grep so you can get more detail? ip r may also provide some hints.

You did mention vpn and that dns seems to be using the 10.42 address, which it could not without the address already being available. This may be a race condition between activating the hot spot interface and enabling dns for that hot spot.

I did indeed use vpn this time, but dnsmasq is not triggered by the vpn, so those are unrelated. Also, the 10.42 is not DNS but it’s the wifi hotspot which appears as gateway for the clients (like laptop B).

Why not simply use ip a and peruse the full config without the grep so you can get more detail?

The grep -c command above counts how many times the ‘10.42’ address appears for all interfaces and it did not appear, i.e., no interface was using the address, therefore the “address in use” error did not come from an active interface.

Check when the issue happens:

rpm -V dnsmasq NetworkManager
find /etc/dnsmasq* /etc/NetworkManager/dnsmasq*
nmcli connection show
pgrep -f -a [d]nsmasq
sudo ss -lnpAinet | grep -e dnsmasq

BTW, it works fine for me in Fedora 40.

$ find /etc/dnsmasq* /etc/NetworkManager/dnsmasq*
/etc/dnsmasq.conf
/etc/dnsmasq.d
/etc/NetworkManager/dnsmasq.d
/etc/NetworkManager/dnsmasq-shared.d

Since you mention pgrep [dnsmasq], that actually now got me thinking what may have started dnsmasq in the first place. I guess I need to check my config, thanks for the hint.

Either way, when the hotspot cannot be enabled (“connect” → “deactivated”), it would be really useful to get the error message instead of “deactivated”…

BTW, it works fine for me in Fedora 40.

Sure, works for me, too - most of the time. Have been using it for years in different scenarios. Just recently, the hotspot sometimes won’t come up and without any error being shown, it feels like KDE’s connect menu is buggy.

Added networking

Added kde