Comitup, pihole, static IPs, (and mDNS?)

[baileyji]

Hi Folks,
I suspect this is not a bug (hence no issue), I'm not quite yet sure how to pin down what happened or still actually is happening. I installed comitup on a fully up to date release of raspbian buster, used it to get online successfully for two different networks, then, while on the second network set up pi-hole and the recommended callback for bringing things up and down. In general things looked good, certainly across several power cycles. After taking the hardware to a new location we found that there was some static IP cruft that the installer for pihole had inserted, as I'd feared, and while comitup was spinning up an AP devices wouldn't pull an IP (e.g. on an iphone it would just perpetually connect).

Some local debugging showed remnants of a static ip from the last location. I can't be more specific here as I'm not very familiar with nmcli, e.g. I don't know the difference between ipv4.addresses and IP.ADDRESS[n] (the latter in [1] is where I was seeing the old IP from the last location we also saw it listed in the applet accessed from the top right of the desktop. Ultimately we mitigated this by setting enable_nuke=1 and using comitup-cli x. We still couldn't get the captive portal but the CLI listed the ap we wanted and we were able to select it by index and connect. The connection is now holding across reboots. The one remaining issue is that mDNS/avahi doesn't seem to be integrating with the local network as expected. E.g. https://.local isn't available but https://<local_ip> is. Other services I've got installed that were previously auto-discovered successfully like raspotify and shairport-sync that depend on avahi also no longer just work.

My suspicion here is that I've got some lingering misconfiguration because of something I did (or didn't do), probably related to the pihole installer script, but as I'm now 3000mi from the hardware debugging is much harder. Beyond general thoughts my specific questions would be:

1. Uninstalling comitup would leave nmcli active, so installing network-manager-gnome might be a good idea to control things graphically. Alternatively how would you expect this to interact with comitup if left installed?
2. Can you think of any way comitup (or it + pihole settings) could be conspiring to preclude proper mDNS announcements?
3. What are some helpful commands that might be useful to better debug this?

[edit]: The connection seemed to hold across a few reboots, but it is now broadcasting its own network again. When we try to connect to that with a phone we are back at square one.

[davesteele]

If the problem is leftover from nmcli/NetworkManager, you can see details in the connection configuration file in /etc/NetworkManager/system-connections.

See /var/log/comitup, and the journalctl log for comitup. Sometimes it is easier to just run comitup as root from the command line.