If I enable Wifi Hotspot FTLDNS start/restart fails with "port 53 already in use
If I disable Wifi Hotspot, FTLDNS starts/restarts OK. If I then enable Wifi hotspot FTLDNS continues to run but the Wifi Hotspot fails to connect a new connection with "failed to obtain IP"
I am running Ubuntu 21.04 on a RP4. I go understand it is an unsupported system.
It installed and ran OK BUT in order to do this I first installed Lighttpd manually (this ensures the permission problems are avoided).
I have also installed lighttpd after a clean Pihole installation (as a test)and it too functioned correctly.
The reason for going down this path (Ubuntu 21.04) was that I wanted to use the RP as a print server (USB low use legacy Laser printer) and using Raspian gave me all sorts of problems to the point I just gave up. Ubuntu just worked out of the box, along with Pihole and Unbound.
(though at this stage I haven't installed Ubound on this fresh install-one problem? at a time...)
I know only enough unix to get myself in trouble, so I really need spoon feeding
What I would like is someone to point me to an overview of the wifi hotspot, how it works, what it uses to perform DHCP. There are many, many articles/post/blogs on how to setup Wifi Hotspots but almost nothing I can find on how it actually works which I need to troubleshoot.
I assume (and i do know assume makes an ass out of u & me) that it would normally be using a dnsmasq and that there is probably be a configuration error in either FTLDNS or the config the Wifi Hotspot is using points to the wrong place.
Sorry to be long winded.
Actually, I think this might not be the right forum for your questions. Your main concern is
I don't know which software/script you use to turn your RPi into a Hotspot but I would start looking for help in their respective forum. Maybe even an Ubuntu forum.
After you figured out which software the Hotspot really uses, try to solve the port conflict.
DNS runs on port 53, so Pi-hole really needs it.
If your Hotspot uses dnsmasq your could add -port=0 to the dnsmasq config files to disable DNS functionality and only leave DHCP.
Did you try to search this forum already? I know other users have turned RPis into access points along with Pi-hole...
Thanks for your reply.
I did do a search but mostly the questions and replies were how to actually do it, not what happens when something goes wrong.
I understand what you mean about this may not be the appropriate forum.
This concerns Pi-Hole directly. Ubuntu works seamlessly as a hotspot without Pi-hole. But the installation of Pi-hole changes the DNS functionality by combining dnsmasq with FTLDNS (according to the pihole documentation)
The reason for posting here is that I assume that there will be a installation of Pi-Hole for Ubuntu 21.04 and these will be the sorts of problems that will be encountered.
I would assume also that changes needed would be similar for the other versions of Ubuntu (which already have tested full Pi-Hole installations).
I was sort of hoping that someone that has previously done that work may well have a hint.
I will review the link you gave and see what I can work out.
I guess i really should start with the scripts as you suggested but that is likely to be a longish job, but I guess I can treat it as a learning experience.
Bit more testing
Ubuntu 20.x does not work either. Same problem still working on it
(video card ave up the ghost in PC so have to use the Raspberrypi to test with so hard going)
I will not continue with this till the next release because dnsmasq is being updated as part of that update.
Now I know it is NOT just Ubuntu 21.04 it is more than likely to be a problem within the dnsmasq configuration or the way other scripts interact with FTL-DNS compare to dnsmasq in its original state.
If i had to guess I would say the configuration of the hotspot is using dnsmasq rather than FTL-DNS and starts dnsmasq (or attempts to) and they both use the same port. Just stopping dnsmasq using port 53 kills the hotspot anyway so its an either or case.
I haven't investigated it as yet. Since FTLDNS (according to the documentation) contains the dnsmasq code, any changes will also be reflected in FTLDNS. Rather than take off on a tangent, and take the chance of maybe have to investigate twice or at least do a confirmation investigation I will wait until the next version of PI-Hole which will include the new code. I believe the release is imminent, awaiting only a resolution of one more minor bug.
Perhaps when I have more time I will further investigate further.
Thanks for the reply.
Yes I did. It made no difference.
It was just too hard to debug and learn with the live raspberry pi
I now have a new graphics card for the PC so am able to test a bit more. I will setup a new sd card/installation for the pi and upgrade to the beta version and work on that. Have other things to do at the moment though so will be a few days.
The basic problem is that Pi-hole is using Netplan to set up
ubuntu 21.042 uses Network manager with the Netplan config pointing to NetworkManage
Looks like they aren't playing nice together
Nop that is Not the problem
There was a new release to 2.043 which apparently solved the problem of Pi-hole crashing but the Hotspot still does not get an IP address.
Hotspot is set with NetworkManager (well at least from the Gnome desktop)
I haven't had time to go further and see what the actual problem is but there is a new release of Pi-hole and I will try that before I start to delve more deeply. I don't want to risk reinventing the wheel.
Upgrading pihole did nothing
I have a little time so will just compare with/without pihole
Pretty sure I have nailed the problem. Background:
With the installation of the operating system (in this case Ubuntu 21.4 but also for 20.xx) the network is setup using network manager with the network configuration file called "Wired Connection1.nmconnections" in /run/NetworkManager/ system-connections.
Subsequent network alterations are placed in the file called "Wired Connections1.nmconnections" /etc/NetworkManager/NetworkManager/systen-connections/
When NetorkManager is invoked (at any change to the network) it reads these files in order, and parses the results into what it uses. Any differences or anomalies are handled by starting at the /run.... then moving to /etc.... file/s, overwriting any inconsistencies along the way. (it also looks in /var/lib/NetworkManager-intern but that doesn't effect us in this case)
Network manager is pretty complete. It has most of its parameters as sensible defaults. In this way it is only necessary to alter specific parameters for individual connections.
NetwokManager handles the dhcp requests in the following order. It uses the parameter specified in DHCP= to find which DHCP process to handle requests. If no DHCP= is present it attempts to use a DHCPclient process and if that is not present it uses an internal very lightweight DHCP/DNS client.
In most cases that is all that is needed. (it is NOT dnsmasq-that is not yet installed.) Problem
When Pi-hole is installed and enabled it provides the DNS services by using DNSFTL and handles DHCP as well if enabled.
Trouble is that NetworkManager is not aware of DNSFTL so it tries to use its internal server which also attempts listens on port 53 so it fails as port 53 is already used by DNSFTL.
The solution will be to make NetworkManager "aware" of DNSFTL whenever Pi-hole is enabled.
There is also the possibility of setting a flag/parameter to allow multiple instances of listening on port 53, but that is a developer decision.
I have not offered a solution (yet) because I think it qualifies as a bug in the pi-hole installation.
So why doesn't it affect other installations? Any other operating systems that do not use NetworkManager are not affected because in reality these network connections are made manually.
My solution (as yet untried) will to alter the NetworkManager.conf to add the DHCP= but that is going to take some time as testing involves several re-installations to check it is not just a one off single installation solution.
Thanks for the quick reply.
The operating system works fine UNTIL pi-hole is installed. In these operating system ubuntu 20.xx (and it will be the same for 21.xx), the installation files fail to update the NetworkManager config or handle the anomaly in any other way.
The expectation is that if I install a full package for a standard or default operating system installation, then it should work.
Surely any installation of software that breaks existing standard or default system software or processors is a bug in the installation.
Obviously NetMan by default wants to play DNS server when this WiFi hotspot feature is used. This can be seen as convenience feature so that it behaves like a router which usually also serves as DNS server/cache for the local network.
Pi-hole naturally is a DNS server as well, so the conflict.
You cannot have two services listening on the same port. How should the system know which of both should answer on an incoming request on that port? Reasonably the port is hence blocked by the first process binding to it so that on a conflicting attempt you are informed of this misconfiguration instead.
You need to either configure NetMan or Pi-hole to listen on a different port, or disable DNS at NetMan competely and have it instead passing Pi-hole as DNS server via DHCP.
No it is not a setup issue. Think it through.
NetworkManager handles all the network. There are existing network configurations set by NetworkManager. It is part and parcel of the operating system.
These are not convenience features any more than any other program or hardware installation.
They maybe for you but not for other installations they most certainly are not.
The installation of Pi-hole breaks these configurations because it does not set itself up correctly.
Remember this is an installation of Pi-hole specifically for ubuntu 20.xx. It checks for the operating system at installation.
You can have more than one process listening on a single port but it involves changes to those processes to set a parameter to allow that. (that is for the developers to do though) Other servers/daemons do it under some circumstances.
The installation file should set up NetworkManager correctly and the scripts in PI-hole should set this configuration when it is enabled and check each time it is enabled that it is set.
It is a bug not only in the setup of pi-hole installation but also when it is enabled.
Have you done a "ss -tulpn" ?
It will show only DNSFTL listening on port 53.
The problem occurs only when NetworkManager changes any network configuration involving DHCP.
Even if DHCP is NOT enabled in Pi-hole the port is still used by pi-hole. Because Pi-hole has not configured NetworkManager properly when NetworkManager invokes/needs DHCP services it attempts to start and use its internal DHCP on port 53 but fails.
It would be silly to alter the operating system (by changing DHCP ports) and introduce who knows how many problems down the track to provide a work around for a failure in installation of pi-hole.
Please upload a debug log and post just the token that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
Thanks for the reply.
When I started looking it wasn't a supported system. The same thing happens on 20.xx anyway so there was a pretty good reason to wait for the upgrade.
I will load the debug file up a bit later as I am somewhat busy with other things at the moment (you know, golf to play, food to cook & eat and that whiskey isn't going to drink itself.....).
One thing to note is that with Pihole running and the Raspberry pi having a static address, this problem won't be seen normally because NetworkManager will not be involved in setting up new connections and wont provide DHCP services for itself, all dhcp requests will originate from the (existing) network.
It is only when a new local connection is attempted (as in connecting a Hotspot or connecting to a different network via Wifi? ).
I will supply the token when I get a chance but I am not sure it will give much information.
Pretty sure it wont show anything with the pi-hole installation, the problem only occurs when network manager is invoked by the connection "Hotspot" to complete a new connection.
