Luis Peromarta
2024-Jun-17 18:51 UTC
[Samba] Time sync problem samba 4.20.0 chrony debian11
There must be something wrong with your setup. I have 4.20.1 and W10 22H2 (latest daily updates) and it works just fine. S:\>w32tm /monitor cwing.mad.caponato.es[192.168.0.14:123]: ?? ?ICMP: 0ms delay ?? ?NTP: -0.0000762s offset from awing.mad.mater.int ?? ? ? ?RefID: time.cloudflare.com [162.159.200.123] ?? ? ? ?Stratum: 4 bwing.mad.caponato.es[192.168.0.13:123]: ?? ?ICMP: 0ms delay ?? ?NTP: +0.0002806s offset from awing.mad.mater.int ?? ? ? ?RefID: time.cloudflare.com [162.159.200.123] ?? ? ? ?Stratum: 4 awing.mad.caponato.es *** PDC ***[192.168.0.12:123]: ?? ?ICMP: 0ms delay ?? ?NTP: +0.0000000s offset from awing.mad.mater.int ?? ? ? ?RefID: time.cloudflare.com [162.159.200.1] ?? ? ? ?Stratum: 4 dwing.mad.caponato.es[192.168.0.62:123]: ?? ?ICMP: 0ms delay ?? ?NTP: -0.0003914s offset from awing.mad.mater.int ?? ? ? ?RefID: ntp1.adora.codes [5.250.191.170] ?? ? ? ?Stratum: 3 Warning: Reverse name resolution is best effort. It may not be correct since RefID field in time packets differs across NTP implementations and may not be using IP addresses. S:\>w32tm /query /status Leap Indicator: 0(no warning) Stratum: 5 (secondary reference - syncd by (S)NTP) Precision: -23 (119.209ns per tick) Root Delay: 0.0320375s Root Dispersion: 0.3500638s ReferenceId: 0xC0A8000D (source IP:??192.168.0.13) Last Successful Sync Time: 17/06/2024 19:49:52 Source: bwing.caponato.es Poll Interval: 14 (16384s) LP On Jun 17, 2024 at 19:43 +0100, Peter Milesson via samba <samba at lists.samba.org>, wrote:> > > On 17.06.2024 18:02, Luis Peromarta via samba wrote: > > Without the ?-v? it looks like this: > > > > 15:53:29.013069 IP PCCAP23.mad.caponato.es.ntp > dwing.mad.caponato.es.ntp: NTPv3, Client, length 68 > > 15:53:29.015440 IP dwing.mad.caponato.es.ntp > PCCAP23.mad.caponato.es.ntp: NTPv3, Server, length 68 > > > > > > LP > > On Jun 17, 2024 at 15:55 +0100, wrote: > > > tcpdump udp port 123 > > > tcpdump: verbose output suppressed, use -v[v]... for full protocol > > > decode listening on enp1s0f0, link-type EN10MB (Ethernet), snapshot > > > length 262144 bytes 16:22:47.608803 IP pc2304.tlk.loc.ntp > > > > dom2.tlk.loc.ntp: NTPv3, Client, length 120 > > > 16:22:53.692770 IP schulung6.tlk.loc.ntp > dom2.tlk.loc.ntp: NTPv3, > > > Client, length 120 > Hi folks, > > I have tested with both Windows 10 22H2 and Windows 11 23H2, both domain > joined. Time synchronization with a Samba AD DC 4.20.1 (Debian Bookworm > backports) does not work. Either has M$ changed something, or Chrony. > Unfortunately, I haven't got time to dig deeper in this at the moment. > It worked about 18 months ago... > > Best regards, > > Peter > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba
Peter Milesson
2024-Jun-18 12:32 UTC
[Samba] Time sync problem samba 4.20.0 chrony debian11
On 6/17/24 20:51, Luis Peromarta via samba wrote:> There must be something wrong with your setup. I have 4.20.1 and W10 22H2 (latest daily updates) and it works just fine. > > > S:\>w32tm /monitor > cwing.mad.caponato.es[192.168.0.14:123]: > ?? ?ICMP: 0ms delay > ?? ?NTP: -0.0000762s offset from awing.mad.mater.int > ?? ? ? ?RefID: time.cloudflare.com [162.159.200.123] > ?? ? ? ?Stratum: 4 > bwing.mad.caponato.es[192.168.0.13:123]: > ?? ?ICMP: 0ms delay > ?? ?NTP: +0.0002806s offset from awing.mad.mater.int > ?? ? ? ?RefID: time.cloudflare.com [162.159.200.123] > ?? ? ? ?Stratum: 4 > awing.mad.caponato.es *** PDC ***[192.168.0.12:123]: > ?? ?ICMP: 0ms delay > ?? ?NTP: +0.0000000s offset from awing.mad.mater.int > ?? ? ? ?RefID: time.cloudflare.com [162.159.200.1] > ?? ? ? ?Stratum: 4 > dwing.mad.caponato.es[192.168.0.62:123]: > ?? ?ICMP: 0ms delay > ?? ?NTP: -0.0003914s offset from awing.mad.mater.int > ?? ? ? ?RefID: ntp1.adora.codes [5.250.191.170] > ?? ? ? ?Stratum: 3 > > Warning: > Reverse name resolution is best effort. It may not be > correct since RefID field in time packets differs across > NTP implementations and may not be using IP addresses. > > S:\>w32tm /query /status > Leap Indicator: 0(no warning) > Stratum: 5 (secondary reference - syncd by (S)NTP) > Precision: -23 (119.209ns per tick) > Root Delay: 0.0320375s > Root Dispersion: 0.3500638s > ReferenceId: 0xC0A8000D (source IP:??192.168.0.13) > Last Successful Sync Time: 17/06/2024 19:49:52 > Source: bwing.caponato.es > Poll Interval: 14 (16384s) > > > LP > On Jun 17, 2024 at 19:43 +0100, Peter Milesson via samba <samba at lists.samba.org>, wrote: >> >> On 17.06.2024 18:02, Luis Peromarta via samba wrote: >>> Without the ?-v? it looks like this: >>> >>> 15:53:29.013069 IP PCCAP23.mad.caponato.es.ntp > dwing.mad.caponato.es.ntp: NTPv3, Client, length 68 >>> 15:53:29.015440 IP dwing.mad.caponato.es.ntp > PCCAP23.mad.caponato.es.ntp: NTPv3, Server, length 68 >>> >>> >>> LP >>> On Jun 17, 2024 at 15:55 +0100, wrote: >>>> tcpdump udp port 123 >>>> tcpdump: verbose output suppressed, use -v[v]... for full protocol >>>> decode listening on enp1s0f0, link-type EN10MB (Ethernet), snapshot >>>> length 262144 bytes 16:22:47.608803 IP pc2304.tlk.loc.ntp > >>>> dom2.tlk.loc.ntp: NTPv3, Client, length 120 >>>> 16:22:53.692770 IP schulung6.tlk.loc.ntp > dom2.tlk.loc.ntp: NTPv3, >>>> Client, length 120 >> Hi folks, >> >> I have tested with both Windows 10 22H2 and Windows 11 23H2, both domain >> joined. Time synchronization with a Samba AD DC 4.20.1 (Debian Bookworm >> backports) does not work. Either has M$ changed something, or Chrony. >> Unfortunately, I haven't got time to dig deeper in this at the moment. >> It worked about 18 months ago... >> >> Best regards, >> >> PeterHi Luis, If I set the Windows machines to use manually defined NTP servers, they sync fine with Chrony. But it seems Chrony has lost the ability to handle NTPv3 requests when using Samba 4.20.1. I'm just visiting a customer, where they run Samba 4.19.6 with chrony 4.3-2+deb12u1. The workstations get their time from the DCs without problems (Windows 10 and Windows 11). Something with ntp_signd? No firewalls involved under Linux. As NTPv3 also uses UDP port 123, it's not a firewall problem under Windows, as NTPv4 sync works OK. Unfortunately, time handling under Windows is a mess... Best regards, Peter