ntpdate not working? (BW64 10.0.2)

[MochiMoppel]

I use ntpdate to fetch the local time from a time server

Works fine in F96-CE:

Code: Select all

# ntpdate ntp.nict.jp
28 Oct 09:39:26 ntpdate[8303]: step time server 133.243.238.164 offset -3605.355448 sec

Does not work in BW64:

Code: Select all

# ntpdate ntp.nict.jp
Traceback (most recent call last):
  File "/bin/ntpdig", line 418, in <module>
    returned += queryhost(server=server,
                ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/bin/ntpdig", line 104, in queryhost
    s = socket.socket(family, socktype)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/socket.py", line 232, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
OSError: [Errno 97] Address family not supported by protocol

Same problem with other time servers, e.g. ntp.ubuntu.com
While in F96-CE ntpdate is a binary, in BW64 it's a script, supposedly emulating the binary.

[radky]

@MochiMoppel

In initial testing, I can't confirm ntpdate errors in BW64.

Code: Select all

# ntpdate ntp.nict.jp
2023-10-27 23:08:27.125491 (-0400) -0.023776 +/- 0.131237 ntp.nict.jp 133.243.238.243 s1 no-leap

Code: Select all

# ntpdate ntp.ubuntu.com
2023-10-27 23:10:38.130921 (-0400) -0.016621 +/- 0.087503 ntp.ubuntu.com 185.125.190.58 s2 no-leap

Maybe other forum members will also test the ntpdate script for output errors.

[bigpup]

I get this:

Code: Select all

# ntpdate ntp.nict.jp
2023-10-28 01:23:14.171264 (-0400) -0.002120 +/- 0.108280 ntp.nict.jp 133.243.238.164 s1 no-leap
# 
# 
# ntpdate ntp.ubuntu.com
2023-10-28 01:25:16.577415 (-0400) +0.000641 +/- 0.062914 ntp.ubuntu.com 185.125.190.58 s2 no-leap

#

[dimkr]

If you're using ntpdate to sync the clock, connman already implements a NTP client and should fix your clock when you go online. (It's patched so it doesn't adjust the hardware clock, multiple Puppy users asked for this).

This is why web browsing over HTTPS "just works" in a Puppy with connman when you boot it for the first time, even if you don't sync the clock manually first and even if the hardware clock is wrong or if its battery is dead.

If the clock is wrong, maybe something in your network or a misconfigured firewall blocks UDP traffic.

EDIT: @MochiMoppel can you install strace and share the output of strace -f ntpdate ntp.nict.jp? I wonder why your Python thinks UDP is unsupported

[MochiMoppel]

EDIT: @MochiMoppel can you install strace and share the output of strace -f ntpdate ntp.nict.jp? I wonder why your Python thinks UDP is unsupported

Sure.

strace.log.gz

(37.22 KiB) Downloaded 21 times

What I find puzzling is that many time servers do work fine in BW64.
For example the script /usr/sbin/psync uses servers belonging to the NTP Pool Project, and all work, e.g.
oceania.pool.ntp.org
europe.pool.ntp.org
This is why the "Time from Internet" option in the QuickSetup dialog works.

Also NIST servers (https://tf.nist.gov/tf-cgi/servers.cgi) work without problems, e.g.
utcnist3.colorado.edu

However GOOGLE servers do not work:

Code: Select all

# ntpdate time.google.com
Traceback (most recent call last):
  File "/bin/ntpdig", line 418, in <module>
    returned += queryhost(server=server,
                ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/bin/ntpdig", line 104, in queryhost
    s = socket.socket(family, socktype)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/socket.py", line 232, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
OSError: [Errno 97] Address family not supported by protocol

[dimkr]

@MochiMoppel It looks like IPv6 support is disabled on your machine, and ntp.nict.jp supports IPv6. ntpdate fails because it tries IPv6, but IPv6 support is missing on your computer. Are you using the stock kernel? Any changes to your system?

[MochiMoppel]

Any changes to your system?

Yes. I changed kernel back to 5.4.53 with an associated zdrv (discussed here). I do the same with in F96-CE, and there I have no problems with the NICT server. I also had no problem using Slacko 5.6 or Lucid 5.8.2 , which use even older kernels (3.4.52 and 2.6.332), so I didn't suspect the kernels to have anything to do with it.

I added a question mark to my thread title. Seems like ntpdate is innocent ...