Dear Maintainer,


I've been trying for a while, and failing, to get a hotspot working on
my (testing) desktop, so my phone can connect through it.

At first, it was a problem with autentication. But that has been solved
now. The phone connects to the access points, and once I added
kdeconnect as a service to the shared-zone configuration on the
firewall, I can use that -- but I don't get access to the internet. I
don't get it even when the firewall is off.

When I look at it at kernel level:

	cat /proc/sys/net/ipv4/conf/*/forwarding

prints just a series of "1"s.

I had suspected it might have something to do with earlier messing with
the hotspot connection. So I deleted it and created a new one. No
change. The way I created it was with the "Hotspot" button in the
network panel applet.

This bug report is submitted following advice given on the
debian-kde list:
https://lists.debian.org/debian-kde/2025/05/msg00012.html

There you can also see an image showing exactly the button in the
panel applet referred to above:
https://lists.debian.org/debian-kde/2025/05/pngk5Az5p3DJ2.png

Thanks,
        Shai.

Dear Maintainer,

I was able to solve this for myself, but I suspect it will bite others,
so I'm keeping the bug open. It may well be that it belongs in another
package, though.

It took me some searching to find out that firewalld (which is
"the firewall" that now "comes with" plasma) actually uses nftables
behind the scenes. When I looked at the nftables rules, things still
looked ok. It was only after I added some tracing rules, and used
the nft tools to trace packets, that I found the culprit.
(see https://wiki.nftables.org/wiki-nftables/index.php/Ruleset_debug/tracing)

The nft table for the hotspot was fine:

table ip nm-shared-wlo1 {
	chain nat_postrouting {
		type nat hook postrouting priority srcnat; policy accept;
		ip saddr 10.42.0.0/24 ip daddr != 10.42.0.0/24 masquerade
	}

	chain filter_forward {
		type filter hook forward priority filter; policy accept;
		ip daddr 10.42.0.0/24 oifname "wlo1" ct state { established, related } accept
		ip saddr 10.42.0.0/24 iifname "wlo1" accept
		iifname "wlo1" oifname "wlo1" accept
		iifname "wlo1" reject
		oifname "wlo1" reject
	}
}

But tracing showed that, once packets were accepted by this chain, they
were passed to the "filter" table, specifically to its FORWARD chain. That
chain had been probably set up by docker:

	chain FORWARD {
		type filter hook forward priority filter; policy drop;
		counter packets 951 bytes 86070 jump DOCKER-ISOLATION-STAGE-1
		counter packets 951 bytes 86070 jump DOCKER-USER
		oifname "docker0" ct state related,established counter packets 0 bytes 0 accept
		oifname "docker0" counter packets 0 bytes 0 jump DOCKER
		iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept
		iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept
	}

(I have no idea what these numbers actually mean)

After going through this chain, the packets (which, of course, had
"docker0" as neither input nor output interface) were dropped according
to the chain policy.

I added two rules:

$ sudo nft add rule ip filter FORWARD oifname "wlo1"  ct state related,established counter packets 0 bytes 0 accept
$ sudo nft add rule ip filter FORWARD iifname "wlo1" oifname != "wl01" counter packets 0 bytes 0 accept

(modeled after the docker rules)

And now the hotspot provides a proper internet connection.