Busybox-ntpd only works on LAN, not on WLAN


I would like to use the Omnia as IoT central for my own ESP8266 and ESP32 based projects. All of my planned projects so far will need the local time. Some of them will go to deep sleep and wake up every 5 minutes only for a few seconds and it will be multiple devices doing so. In the ESP8266 world, “wake up from deep sleep” means device reset, querying the time again. I was told that the NTP servers in the internet may block my IP when they receive too many requests.

The (probably only) solution to that is a local NTP server.

I’ve followed the instructions in How to activate the NTP server? and at first it seemed to work. But after rebooting the Omnia next time, it stopped working. According to /var/log/messages, ntpd could not start because port 123 was already taken. According to netstat, it is ntpclient.

Well … I’ve uninstalled ntpclient as stated in the instructions. But there are two problems with that:

  1. During uninstall (via LuCi), it warned me that this is a required package and it will return. Obviously, it did.
  2. It is running although it’s not listed in System -> Startup (again LuCi)

So how can I get rid of ntpclient or at least disable it permanently ?

the client component of ntp would/should not have a listening socket/port open, only the server component should do.

Which ntp package(s) did you install and how, e.g. via LuCI - which runs opkg install - or pkgupdate?

What is the output of opkg list-installed | grep ntp?

bysubox is providing both ends of ntp - client and server. Whilst former usually works out of the box latter needs to be manually activated in /etc/config/sytem, there is currently no option in Foris/LuCi

config timeserver 'ntp'
	option enabled '1'
	option enable_server '1'

requires are restart of sysntpd

I’ve installed/uninstalled everything via LuCi.

  • uninstalled ntpclient (but it returned)
  • installed ntpd
root@turris:~$ opkg list-installed | grep ntp
ntp-utils - 4.2.8p13-1
ntpclient - 2010_365-2
ntpd - 4.2.8p13-1
ntpdate - 4.2.8p13-1

Indeed, the enable_server '1' line was missing in my /etc/config/system, but adding it and rebooting the Omnia did not change anything:

root@turris:~$ grep ntp /var/log/messages
2019-06-12 21:09:29 err ntpdate[2379]: name server cannot be used: Try again (-3)
2019-06-12 21:09:29 notice root[]: starting ntpclient
2019-06-12 21:09:35 notice ntpdate[2588]: step time server offset 0.013785 sec
2019-06-12 21:09:41 notice ntpd[3649]: ntpd 4.2.8p13@1.3847-o Thu Apr 11 14:04:22 UTC 2019 (1): Starting
2019-06-12 21:09:41 info ntpd[3649]: Command line: /sbin/ntpd -g -u ntp:ntp -p /var/run/ntpd.pid -n
2019-06-12 21:09:41 info ntpd[3649]: proto: precision = 0.800 usec (-20)
2019-06-12 21:09:41 info ntpd[3649]: basedate set to 2019-03-30
2019-06-12 21:09:41 info ntpd[3649]: gps base set to 2019-03-31 (week 2047)
2019-06-12 21:09:41 info ntpd[3649]: Listen and drop on 0 v6wildcard [::]:123
2019-06-12 21:09:41 err ntpd[3649]: unable to bind to wildcard address - another process may be running - EXITING
2019-06-12 21:09:51 info procd[]: Instance sysntpd::instance1 s in a crash loop 6 crashes, 0 seconds since last crash
root@turris:~$ netstat -atulpen | grep 123
udp        0      0      ESTABLISHED 2653/ntpclient

this is exactly the problem that was described in the instructions I followed (see link in original post):

  1. Uninstall ntpclient (otherwise, it takes the port 123)

That is not the preferred method for TOS since it features its very own pkgupdate which is patched on top of opkg.

There might be some interdependency between ntpclient and ntpd and thus you probably need to remove both and neither should return after reboot.

ntpd is colliding with busybox’s ntp implementation

It should though once you get rid of ntpd and ntpclient

Whow, some success. Now it starts. I also had to restore the symlink /sbin/ntpd pointing to /bin/busybox. This symlink was removed when I installed ntpd.

There is just one thing … it only works on LAN, but not on WLAN. And the netstat line looks a bit strange, at least for IPV4.

root@turris:~$ netstat -atulpen | grep 123
udp        0      0 :::123                  :::*                                2565/ntpd

That is normal output for listening globally on ipv4 and ipv6.

Firewall? How are determining the ipv4/6 connectivity for ntp traffic on LAN/WLAN?

I am curios what your output on the TO is for ntpq -p, because on my node it is producing

localhost: timed out, nothing received
***Request timed out

I’ll check the firewall thing tomorrow, going to bed now. But I have to admit I’m surprised that this matters at all … I thought that ntpd (OK, busybox) would listen on all interfaces.

For your curiosity … I did not test on the router. I tested on the PC (for LAN) and the Laptop (for WLAN). This is the output on the PC:

root@PC:~$ ntpdate -q turris
server, stratum 2, offset -0.000711, delay 0.02785
12 Jun 22:17:44 ntpdate[29545]: adjust time server offset -0.000711 sec

You are right, it should not matter since is does listen on all interfaces indeed.

Anyway, when you get the chance after your beauty sleep please post output ntpq -p on the TO.

Whow, that’s interesting … ntp does not exist (or not exist anymore):

root@turris:~$ ntpq -p
-ash: ntpq: not found

Could it have been part of the ntputils package that was uninstalled implicitly when I uninstalled ntpd and ntpclient?
What’s even more strange … I can’t find ntpd and ntputils anymore. Neither in LuCi nor with opkg. In between, I ran opkg update, maybe this is how I lost these packages from the list.

At least, I can run

root@turris:~$ ntpdate -q localhost
server, stratum 2, offset 0.000014, delay 0.02766
13 Jun 21:44:00 ntpdate[21172]: adjust time server offset 0.000014 sec

on the TO and I get a similar result as on the PC.

Yes, it is indeed.

try this

  • create file /etc/updater/conf.d/user.lua
  • add in user.lua Install("ntp-utils")
  • save file
  • run from ssh cli pkgupdate

Later on when you want install other packages just extend Install("ntp-utils", "package name") and run pkgupdate again. For removal just delete the package name from that file, save and pkgupdate again.

And if you want to uninstall packages that came pre-installed add e.g. Uninstall( "openssh-sftp-client", "openssh-sftp-server").

The curious thing though is that running ntpdate localhost on the TO produces

ntpdate no server suitable for synchronization found

which makes me wonder whether the busybox ntpd implementation is working properly since

ntpdate 0.openwrt.pool.ntp.org on the TO produces

ntpdate: adjust time server offset 0.000341 sec

OK, I could reinstall ntp-utils. I think I really need to learn lua as I came across it in other environments too, e.g. conky configuration … :slight_smile:

ntpq -p fails with a timeout. First, I thought that my previous success was also gone, but I still could run ntpdate -q localhost:

root@turris:~$ ntpq -p
localhost: timed out, nothing received
***Request timed out
root@turris:~$ ntpdate -q localhost
server, stratum 5, offset 0.000281, delay 0.02832
15 Jun 18:12:07 ntpdate[20848]: adjust time server offset 0.000281 sec

The curious thing though is that running ntpdate localhost on the TO produces

ntpdate no server suitable for synchronization found

This is what I get when I test it from WLAN.

from the WLAN client you ran ntpdate localhost or ntpdate router ip?

I ran ntpdate -q router ip of course.

1 Like

With the output of ntpdate [host], ntpq -p, ntptime -c and ntpdc -lnps I am growing concerned that that the ntpd server implementation in busybox is flawed. At least all the output seems to be indicative of it.

Lodged an issue with the TO devel

And upstream https://bugs.openwrt.org/index.php?do=details&task_id=2318

OK, this means I need a plan B. I think I’m going to equip one of the ESP8266’s with a RTC and set up an ntp server there.

Thanks a lot for your time and effort.

It might turn out not to be a bug but rather some misconfig on my end, but I do not see where really.

And ntpdate -q does not prove to me that the server is actually (capable of) serving time to clients and everything else seems to be pointing to the contrary. Which is not a reliable scenario really to depend on

And thank you for your feedback, establishing that the output is not just happening on my node.

alternative might be an lxc guest container on the router that provides a ntpd server

Oh, that’s a really nice idea. And an opportunity to learn about the LXC feature.

ntpq | ntpdc queries relying on NTPv2 mode (6) which is not supported by busybox.

Whilst ntpdate -v localhost | ntpdate localhost strangely fail ntpdate -q localhost | ntpdate -d localhost however work.