when i run ps auxgww | grep dnsmasq all I see is the grep dnsmasq process, which sort of makes sense because NetworkManager fails to start dnsmasq.
The story so far...
From my original post and @yubiuser answer, I have methodically worked out that dnsmasq is causing the problem. But it is a "cutdown" or "private" instance. The man on NetworkManager & dnsmasq have been the source of my understanding. The loading of the configuration files or more particularly the link you provided conf-file you gave in your last answer showed where I was going wrong.
I have tried to add a dnsmasq.conf containing " port=0 " to the /etc/NetworkManager/dnsmasq.d directory but it makes no difference. ( I suspect I have a wrong file name but dnsmasq.conf seems reasonable, what do you think?)
The original problem seemed to be that NetworkManager tried to start its private version of dnsmasq but it fails because pihole-FTL is using port53. Putting port =0 in the pihole.conf (in the /etc/pihole/dnsmasq.d directory) kills pihole-FTL, which actually solves the dnsmasq port53 issue but I now suspect it kills the Hotspot connection not because dnsmasq fails to start, but because there is an incomplete dns server running.
I did find a link to disable port53 and will test that but I am uncertain whether that is really a solution.
I have asked the general question of using pihole-FTL as the dhcp/dns server on the askubuntu forum (11 days ago actually) but so far no replies
I will do as you suggested and ask specifically how to disable the port 53 in the dnsmasq of NetworkManager.
The name of the file wouldn't matter much, as long as it is in the correct directory.
I'd guess /etc/NetworkManager/dnsmasq-shared.d/ would seem a more likely candidate for the hotspot related configuration, as a hotspot is about sharing your internet conection (but that really is just a guess based on the naming scheme - I am not fluent with NetworkManager).
I'd try both locations, and I'd look for a way to reliably restart the respective NM administered dnsmasq service. Most options are only read at startup, so a restart of dnsmasq is likely required to put your custom configuration in action. If in doubt, try rebooting the machine.
Ah yes you are right, this is only effective for dnsmasq as own local resolver.
I did some testing now:
NetworkManager has no builtin dnsmasq but pulls in the dnsmasq-base package (core/binaries only) as recommendation and executes it automatically when starting any kind of shared connection, including the WiFi hotspot. I am able to replicate it with a shared Ethernet connection here. With this package removed, the shared connection fails:
start sharing failed: could not start dnsmasq due to Could not find "dnsmasq" binary
It however explicitly sets --conf-file=/dev/null ... --conf-dir=/etc/NetworkManager/dnsmasq-shared.d so that none of the default config files or directories is used. It can be easily verified by adding some random invalid characters to /etc/dnsmasq.conf and /etc/dnsmasq.d/01-pihole.conf which makes pihole-FTL and dnsmasq commands both fail and throw a related error "dnsmasq: bad option at line 21 of /etc/dnsmasq.d/01-pihole.conf" while the instance started by NetworkManager starts and runs successfully as expected.
/etc/NetworkManager/dnsmasq.d/ is used for the processing mode dnsmasq, hence when using dns=dnsmasq, but is not relevant for the hotspot.
So there is no issue with overlapping configuration files. NetMan uses dnsmasq not only as DNS server but also as DHCP server. It is however trivial to disable the DNS server part:
You can specify the alternative DNS server passed to DHCP clients (not sure what is default here when the internal one is disabled) by additionally adding:
dhcp-option=6, x.x.x.x[, y.y.y.y]
This can be Pi-hole, but you may need to allow requests from all origins in Pi-hole first, if the hotspot is a different subnet.
I could neither find a way to disable dnsmasq's DHCP server completely (unsetting the --dhcp-range command line option used by NetMan), nor preventing NetMan from starting dnsmasq at all, so it keeps blocking UDP port 67 and hence Pi-hole cannot be used as DHCP server. There is an option to prevent dnsmasq from listening on a particular interface, but it keeps binding to the port:
Thanks @Bucking_Horn
As usual, when there is a choice of 2 locations I will always choose the wrong one.
But I don't think made any difference.
Thanks @MichaIng
That's what I found.
But i went a little further in the conf-file in the link @Bucking_Horn first mentioned in a previous post.
There is this interesting line in the conf-file, 400 /* dnsmasq exits if the conf dir is not present */
That seems to set the CONFDIR to null, then does something called nm-assert but then it spawns dnsmasq, but it has a return test to see if it actually got a PID, so that means it can handle? not having dnsmasq started.
I am not a programmer and following through to see what everything does is, for me, a very long and tedious process
(hell i never even heard of NetworkManager or dnsmasq before I ran into this problem)
I deleted the 3 conf locations conf.d (probably not necessary) dnsmasq.d, dnsmasq-shared.d
However it now still fails but with a slightly different message. Instead of the dnsmasq message it fails with the dhcp bind failure message as you alluded to.
Doing to do a full reinstall so I have a full "virgin" install and repeat the testing in case I have missed something.
I must have been nasty in a past life.
New installation of 21.04 has "unattended-upgrade" on as default. One of the upgrades (haven't worked out which) causes the graphics to fail on reboot - not even a terminal. Just wasted time learning how to fix that before i start retesting.
Anyhow putting the port=0 in a file in /etc/NetworkManager/dnsmasq-shared.d/ certainly stops dnsmasq from starting as a dns server.
By setting a static ip to the wlan it will allow a client to connect but the client wont have internet access because the gateway/dns is not provided because NetworkManager can't bind the interface address to a dhcp service. (Probably the routing to the interface is not done either)
I still will look further but need to sort out the desktop graphic problem so I don't have to jump through hoops at each reboot.
While DNS is not provided anymore by NetMan (with port=0), DHCP still is, so it shouldn't be required to set a static IP on clients. Of course when you set a static IP on clients, you need to include a static gateway and static DNS. When keep using DHCP, you only need to tell dnsmasq which DNS server to provide via DHCP, with the setting mentioned above.
Thankyou @MichaIng
Sorry I did not get back sooner.
The DHCP provided by NetMan isn't very feature rich. I was going to install DHCPD which NetMan can use and I was going to fiddle with that.
But the problem I encountered with a new install with unattended upgrade (there must have been a recent change because nothing I did changed) on as default actually breaks the gnome desktop on this version of Ubuntu, and even though I have a work around, its tedious (it's not permanent) and I have decided it is just too hard to try and solve the DHCP & DNS while Ubuntu is a bit unstable.
I will go to Debian instead and just buy another pihole as a dedicated hotspot.
