Ntp not working when using wildcard as interface

Christian_S · December 26, 2024, 9:07pm

I've installed pihole in a linux system with multiple virtual nics for different vlans (192.168.1.2, 192.168.2.2, ... 3rd octet. = vlan id).
When I use "" for ntp.ipv4.address I can see that ntp is listening in all interfaces:

$ lsof -i:123
COMMAND     PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pihole-FT 44598 pihole   41u  IPv4 582094      0t0  UDP *:ntp

But tests always fail:

$ ntpdig -d 192.168.2.2
ntpdig: querying 192.168.2.2 (192.168.2.2)
ntpdig: no eligible servers

But when I use any specific interface by ip 192.168.2.2 for ntp.ipv4.address it works:

$ ntpdig -d 192.168.2.2
ntpdig: querying 192.168.2.2 (192.168.2.2)
org t1: eb184351.4902f000 rec t2: eb184350.4945b6c3
xmt t3: eb184350.4a2f5989 dst t4: eb184351.4b342000
org t1: 1735247057.285201 rec t2: 1735247056.286220
xmt t3: 1735247056.289785 dst t4: 1735247057.293764
rec-org t21: -0.998981  xmt-dst t34: -1.003979
2024-12-26 22:04:16.289785 (+0100) -1.001480 +/- 0.002500 192.168.2.2 s2 no-leap

What am I doing wrong?

BR Chris

deHakkelaar · December 27, 2024, 4:40am

Did you give it some time to settle before performing the ntpdig ... wait a minute or so?
I made same mistake

github.com/pi-hole/FTL

NTP gone after web port change

opened 01:28AM - 15 Dec 24 UTC

closed 02:06AM - 15 Dec 24 UTC

deHakkelaar

### Versions ``` $ sudo pihole version Core Version is v5.18.3-578-g4dbf9a0…b (Latest: null) Branch is development Hash is 4dbf9a0b (Latest: 4dbf9a0b) Web Version is v5.21-1042-g87b19772 (Latest: null) Branch is development Hash is 87b19772 (Latest: 87b19772) FTL Version is vDev-91ea8d4 (Latest: null) Branch is development Hash is 91ea8d49 (Latest: 91ea8d49) ``` ### Platform Paravirtualized VM. ``` $ hostnamectl Static hostname: ph6c Icon name: computer-vm Chassis: vm Virtualization: xen Operating System: Debian GNU/Linux 12 (bookworm) Kernel: Linux 6.1.0-23-amd64 Architecture: x86-64 ``` - Platform: Hypervisor host is an Intel NUC i3 ### Expected behavior To have the NTP listener survive a web port change. ### Actual behavior / bug When changing web port, NTP (123) disappears. ### Steps to reproduce Before I change the OOTB defaults: ``` $ pihole-FTL --config webserver.port 80,[::]:80,443s,[::]:443s ``` ``` $ sudo ss -nltup | grep pihole udp UNCONN 0 0 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=174034,fd=16)) udp UNCONN 0 0 0.0.0.0:123 0.0.0.0:* users:(("pihole-FTL",pid=174034,fd=36)) udp UNCONN 0 0 [::]:53 [::]:* users:(("pihole-FTL",pid=174034,fd=18)) udp UNCONN 0 0 [::]:123 [::]:* users:(("pihole-FTL",pid=174034,fd=37)) tcp LISTEN 0 200 0.0.0.0:80 0.0.0.0:* users:(("pihole-FTL",pid=174034,fd=29)) tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=174034,fd=17)) tcp LISTEN 0 200 0.0.0.0:443 0.0.0.0:* users:(("pihole-FTL",pid=174034,fd=31)) tcp LISTEN 0 200 [::]:80 [::]:* users:(("pihole-FTL",pid=174034,fd=30)) tcp LISTEN 0 32 [::]:53 [::]:* users:(("pihole-FTL",pid=174034,fd=19)) tcp LISTEN 0 200 [::]:443 [::]:* users:(("pihole-FTL",pid=174034,fd=32)) ``` After I change the web port: ``` $ sudo pihole-FTL --config webserver.port '8080,[::]:8080' 8080,[::]:8080 ``` ``` $ sudo ss -nltup | grep pihole udp UNCONN 0 0 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=174034,fd=16)) udp UNCONN 0 0 [::]:53 [::]:* users:(("pihole-FTL",pid=174034,fd=18)) tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=174034,fd=17)) tcp LISTEN 0 200 0.0.0.0:8080 0.0.0.0:* users:(("pihole-FTL",pid=174034,fd=31)) tcp LISTEN 0 32 [::]:53 [::]:* users:(("pihole-FTL",pid=174034,fd=19)) tcp LISTEN 0 200 [::]:8080 [::]:* users:(("pihole-FTL",pid=174034,fd=32)) ``` ## Debug Token - URL: https://tricorder.pi-hole.net/ilNqGEyX/ ### Additional context Changing back to OOTB defaults doesnt return NTP. I need to restart FTL to get it back.

Christian_S · December 27, 2024, 5:06am

Thanks for the tip. But that doesn't seem to be the problem.

I can query the NTP server via the physical NIC (enp0s31f6).
But not via any of the virtual NICs assigned with VLAN (enp0s31f6.1 - enp0s31f6.4).

I have not been able to narrow it down any further.

deHakkelaar · December 27, 2024, 5:09am

Better upload a debug log so the devs can have a look:

sudo pihole debug

Only post the resulting token URL here thats displayed after the upload was successful!

Christian_S · December 27, 2024, 10:31am

debug log created and uploaded.
https://tricorder.pi-hole.net/BSmgn4YB/

DL6ER · December 27, 2024, 11:20am

I'm currently not at home so I haven't had a chance to look at your uploaded debug log, so far, but I was wondering if there might be relevant additional output if you enable NTP logging like

sudo pihole-FTL --config debug.ntp true

And then compare once in the case where it works and once where you don't specify an interface. Let's hope there will be some visible difference, otherwise, we can later extend debug logging to maybe better fit to your specific corner case.

DL6ER · December 28, 2024, 7:32am

I did just look at your Tricorder log and - in addition to my debug logging question above - I have more questions because I don't understand your network configuration:

You are talking about 192.168.x.0/24 networks and I can see you have rev-server settings for a few such subnets. However, none of your existing interfaces actually has an 192.168.x.0 address - they are all in the 10.y.0.0/16 ranges each (at least on enp0s31f6 and its virtual children, I have not seen any other meaningful NIC on your machine).

This is in agreement with a few errors we are seeing when Pi-hole tries to access such networks:

INFO: Tried to resolve PTR "2.1.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)
ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server

According to your configuration, 192.168.2.0/24 lookups are forwarded to 192.168.2.1 internally and the timeout here means that there was never a reply from said forwarding destination. That's probably because your entire machine also has no defined route to send/receive something to/from this address.

This is also in agreement with your NTP observation: When you specify the "wildcard address", Linux does not listen for "all" addresses but only for "reachable" ones. IN your particular setup, 192.168.x.y is not actually reachable on your machine. If you, however, specify a single address, the kernel knows that this specific address is to be routed to this specific application. However, I'd still have expected an Cannot assign requested address error so something in how you configured your network is still unclear to me.

Christian_S · December 28, 2024, 2:10pm

First of all, thank you for looking at the debug log!

Then - my mistake, sorry!

The network configuration has changed due to our move a few weeks ago. The 192.168.x from the initial post is now 10.x.0.y. I still have the old config in my “fingers” when writing.

My networks are - in accordance with the debug log

10.1.0.0/24: Management for router, switch and access point
10.2.0.0/24: Office network
10.3.0.0/24: IoT
10.4.0.0/24: Guests

192.168.0.0/24 is a family location connected via S2S VPN.
Routing takes place here on the router, not on the pihole

The same applies to 192.168.1.0/24 and 192.168.2.0/24.
The S2S connections are always briefly offline due to the DSL forced disconnection.

The configure nics are:

enp0s31f6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 10.2.0.199 netmask 255.255.255.0 broadcast 10.2.0.255
        [...]

enp0s31f6.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 10.1.0.2 netmask 255.255.255.0 broadcast 10.1.0.255
        [...]

enp0s31f6.2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 10.2.0.2 netmask 255.255.255.0 broadcast 10.2.0.255
        [...]

enp0s31f6.3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 10.3.0.2 netmask 255.255.255.0 broadcast 10.3.0.255
        [...]

enp0s31f6.4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 10.4.0.2 netmask 255.255.255.0 broadcast 10.4.0.255
        [...]

enp0s31f6 is the default nic and route used. The nic is set to (reserverd) dhcp to be always available during the ip adress changes from the last weeks. When I use ntp with wildcard I get an ntp reply on just this interface but on none other.

Could the vlan tag assignment an issue?

Target          Route           Genmask         Flags Metric Ref      Use Iface
default         _gateway        0.0.0.0         UG    0      0        0 enp0s31f6
10.1.0.0        0.0.0.0         255.255.255.0   U     0      0        0 enp0s31f6.1
10.2.0.0        0.0.0.0         255.255.255.0   U     0      0        0 enp0s31f6
10.2.0.0        0.0.0.0         255.255.255.0   U     0      0        0 enp0s31f6.2
10.3.0.0        0.0.0.0         255.255.255.0   U     0      0        0 enp0s31f6.3
10.4.0.0        0.0.0.0         255.255.255.0   U     0      0        0 enp0s31f6.4
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 enp0s31f6

$ lsof -i:123
COMMAND     PID   USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
pihole-FT 44598 pihole   33u  IPv4 1067467      0t0  UDP *:ntp

DNS service offered by pihole is reachable on all nics from all vlans.

BR Chris

DL6ER · December 28, 2024, 4:38pm

I don't know.

Did you try ntpdig also with the correct addresses (10.x.y.z)?
Also, have you tried enabling debug mode and see what is the difference?