comitup fails on trixie RPi
I'm trying to run 1.43-1 on recently release trixie based RaspiOS with no luck.
While journalctl output says the interface (wlan0) doesn't exist, it does in fact (see shell output below)
The "address in use" output is because dnsmasq process is still there, bound to port 53 according to netstat or ss -tanp actually.
Any idea? Thanks in advance.
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit comitup.service has finished successfully.
░░
░░ The job identifier is 4272.
Oct 09 10:03:47 openhabian dnsmasq[2493]: started, version 2.91 cachesize 150
Oct 09 10:03:47 openhabian dnsmasq[2493]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth D>
Oct 09 10:03:47 openhabian dnsmasq[2493]: warning: interface wlan0 does not currently exist
Oct 09 10:03:47 openhabian dnsmasq-dhcp[2493]: DHCP, IP range 10.41.0.100 -- 10.41.0.150, lease time 10m
Oct 09 10:03:47 openhabian dnsmasq[2493]: reading /etc/resolv.conf
Oct 09 10:03:47 openhabian dnsmasq[2493]: using nameserver 192.168.178.1#53
Oct 09 10:03:47 openhabian dnsmasq[2493]: using nameserver fdf6:102f:db7a:0:de39:6fff:fe40:9d27#53
Oct 09 10:03:47 openhabian dnsmasq[2493]: using nameserver 2003:ea:a725:7d00:de39:6fff:fe40:9d27#53
Oct 09 10:03:47 openhabian dnsmasq[2493]: read /etc/hosts - 7 names
Oct 09 10:03:48 openhabian dnsmasq[2493]: exiting on receipt of SIGTERM
Oct 09 10:03:49 openhabian comitup[2541]: dnsmasq: failed to bind DHCP server socket: Address already in use
Oct 09 10:03:49 openhabian dnsmasq[2541]: failed to bind DHCP server socket: Address already in use
Oct 09 10:03:49 openhabian dnsmasq[2541]: FAILED to start up
Oct 09 10:03:50 openhabian comitup[2546]: dnsmasq: failed to bind DHCP server socket: Address already in use
Oct 09 10:03:50 openhabian dnsmasq[2546]: failed to bind DHCP server socket: Address already in use
Oct 09 10:03:50 openhabian dnsmasq[2546]: FAILED to start up
Oct 09 10:03:50 openhabian comitup[2547]: dnsmasq: failed to bind DHCP server socket: Address already in use
Oct 09 10:03:50 openhabian dnsmasq[2547]: failed to bind DHCP server socket: Address already in use
Oct 09 10:03:50 openhabian dnsmasq[2547]: FAILED to start up
[10:20:46] root@openhabian:/home/openhabian# nmcli g
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN METERED
connected full enabled enabled missing enabled no (guessed)
[10:20:42] root@openhabian:/home/openhabian# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether b8:27:eb:bd:78:4b brd ff:ff:ff:ff:ff:ff
inet 192.168.178.27/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
valid_lft 863058sec preferred_lft 863058sec
inet6 2003:ea:a725:7d00:6cd8:ed63:29b7:1c95/64 scope global dynamic noprefixroute
valid_lft 7039sec preferred_lft 1355sec
inet6 fdf6:102f:db7a:0:625e:fcbc:872a:98d4/64 scope global dynamic noprefixroute
valid_lft 7039sec preferred_lft 3439sec
inet6 fe80::f4ef:8431:a504:2272/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether b8:27:eb:e8:2d:1e brd ff:ff:ff:ff:ff:ff
inet 10.41.0.1/24 brd 10.41.0.255 scope global noprefixroute wlan0
valid_lft forever preferred_lft forever
NetworkManager is starting dnsmasq, even though it is configured not to. I don't see how to stop it at the moment (dns=none in NetworkManager.conf doesn't work).
Everything appears to be working except captive portal detection.
Yes sorry I forgot to mention that ultimately the problem is the missing portal. My mobile connects to the comitup AP but then fails to bring up the browser. I do can access the portal manually from mobile via its IP.
Have you found out anything about the reason why the browser fails to show the portal? That's the remaining major issue. NM doing extra DHCP doesn't seem to harm.
Guess my observation is consistent with others like https://community.openhab.org/t/openhabian-testing/147079/146