Wi-Fi Hotspot DHCP (on Linux Mint) not supplying IP adress - In conflict with Pihole-FTL

Help Community Help
1

I stumbled across this thread, which seems to be experiencing the same problem (albeit on Ubuntu):
https://discourse.pi-hole.net/t/wifi-hotspot-not-suppling-ip-kills-ftldns/49223. For more in-depth information, look at this thread.

Please note that I use Pi-Hole in combination with Unbound.

Let me summarize my problem:
"NetworkManager (NetMan)" uses "dnsmasq", but so does Pi-Hole.
When creating a Wi-Fi hotspot on Linux Mint, NetMan tries to use dnsmasq in order to assign IP adresses to other devices that try to connect through the hotspot.
But since dnsmasq is already configured and in use by Pihole, NetMan fails to assign any IP adresses through dnsmasq.

What's also interesting is that, quote:

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.
This is true as dnsmasq isn't actually installed on my system. I've tried installing it, but then it overrules pihole-ftl.

Enabling the DHCP component within Pihole doesn't work, since Pihole is handling the DHCP itself, and it can't share it with NetMan.

When running systemctl status NetworkManager with the wireless hotspot enabled, I get the following output:

may 01 18:00:00 NetworkManager[876]: [1651420884.9634] Executing: /usr/sbin/iptables --table nat --insert POSTROUTING --source 10.42.0.0/255.255.25>
may 01 18:00:00 NetworkManager[876]: [1651420884.9675] dnsmasq-manager: starting dnsmasq...
may 01 18:00:00 NetworkManager[876]: [1651420884.9706] device (wlp3s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'manag>
may 01 18:00:00 dnsmasq[10788]: failed to create listening socket for 10.42.0.1: Address already in use
may 01 18:00:00 NetworkManager[10788]: dnsmasq: failed to create listening socket for 10.42.0.1: Address already in use
may 01 18:00:00 dnsmasq[10788]: FAILED to start up
may 01 18:00:00 NetworkManager[876]: [1651420884.9920] dnsmasq-manager: dnsmasq exited with error: Network access problem (address in use, permissi>
may 01 18:00:00 : [1651420885.0070] device (wlp3s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'man>
may 01 18:00:00 : [1651420885.0090] device (wlp3s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'ma>
may 01 18:00:00 : [1651420885.0152] device (wlp3s0): Activation: successful, device activated.

When checking what is running on the DNS port (lsof -i:53), I get the following:

pihole-FT 6442 pihole 4u IPv4 82524 0t0 UDP *:domain
pihole-FT 6442 pihole 5u IPv4 82525 0t0 TCP *:domain (LISTEN)
pihole-FT 6442 pihole 6u IPv6 82526 0t0 UDP *:domain
pihole-FT 6442 pihole 7u IPv6 82527 0t0 TCP *:domain (LISTEN)
Which of course, is to be expected.

When checking what is running on the DHCP port (lsof -i:67), I get nothing.
This is also to be expected, and pihole-FTL would be listening if I were to enable its DHCP component.

So my question is: Has anyone got a solution to make my Linux Laptop's (with Pi-Hole and Unbound) Wifi hotspot work?

I have seen a fork of pihole out there that does the job, but I'd like to get it to work with Pi-Hole itself.

Thanks.

2

A possible solution approach has been been explained in the topic you've linked.

No, as explained at length in the thread you've linked:
Pi-hole does not use dnsmasq, but brings its own pihole-FTL binary, (which happens to be a tailored fork of dnsmasq, but that isn't relevant here).
pihole-FTL is configured via configuration files from /etc/dnsmasq.d/ and /etc/pihole/.

NetworkManager is able to start dnsmasq processes as required.
NM configures them via configuration files from /etc/NetworkManager/dnsmasq-shared.d (for its hotspot service) and /etc/NetworkManager/dnsmasq.d/ (for its DNS service).

While configuration files are cleanly separated, still both pihole-FTL and NetworkManager's dnsmasq would try to claim port 53 (DNS), port 67 (DHCP) and port 547 (DHCPv6) at startup - if they would be configured to do so.
So for NM's dnsmasq DHCP service and pihole-FTL's DNS service to coexist, you 'd have to make sure that neither one uses the ports of the other.

If you want Pi-hole to handle DNS, the way to avoid this is described and explained in yubiuser's first reply to that post you've linked:

To disable specifically the hotspot's DNS service, you'd have to create /etc/NetworkManager/dnsmasq-shared.d/disable-dns.conf with a contents of port=0. Configuration changes would require a restart of the services to be affected.

The topic you've linked also details additional measures to concert coexistence as provided by MichaIng, e.g.:

3 Likes
3

This actually did it. Can't believe I decided to skip this particular setting.
Thanks for pointing it out! :smiley:

So what does this accomplish exactly? Right now my wifi hotspot is using the DNS of Pi-Hole. Does this line go in:

/etc/NetworkManager/dnsmasq-shared.d/disable-dns.conf
or
/etc/NetworkManager/dnsmasq.d/insertcustomname.conf (I Assume it's this one)

The subnet of my home network is 192.168.2.*, while the hotspot subnet is 10.42.0.10 - 10.42.0.254.

Since the wireless network reroutes traffic over the wired network interface, shouldn't "Respond only on interface enp2s0" suffice, instead of "allow requests from all origins"?

Isn't this option redundant in the first place, since it already routes traffic through the Pi-Hole DNS?

Would dhcp-option=6, 127.0.0.1[, ip.to.another.alternative.dns] make sense?

Thanks again.

4

Those would be more like network configuration issues, rather than Pi-hole ones.

I can't really provide a sensible answer, as that would largely depend on your network's and your hotspot's configuration, and I am not familiar with NetworkManager's behaviour.

If NetworkManager would have picked up Pi-hole as DNS server (as perhaps configured by your router), then it may also configure its hotspot to use it, either by distributing it to its clients (via dhcp-option=6, which could also be written as dhcp-option=dns-server) or by redirecting DNS requests to Pi-hole via some firewall rules for its hotspot.
And if NM would NAT requests from its hotspot subnet, then those requests would arrive at Pi-hole from your hotspot's gateway address within your Pi-hole's subnet, sparing you from having to configure it to permit all origins.

1 Like
6

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.