ntpdate 4.2.6p2@1.2194-o: "no server suitable for synchronization found" - works with 4.2.4p8@1.1612-o

Bug #787551 reported by Roman Fiedler
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
NTP
Unknown
Unknown
Gentoo Linux
Expired
Medium
ntp (Debian)
Fix Released
Unknown
ntp (Fedora)
Fix Released
Medium
ntp (Ubuntu)
Fix Released
Medium
Dave Walker
Natty
Fix Released
Medium
Dave Walker
Oneiric
Fix Released
Medium
Dave Walker

Bug Description

IMPACT: When attempting to sync to some ntp servers, a failure is consistently produced.
FIXED: In oneiric and upstream >4.2.6p3-RC9 or >4.2.7p80
PATCH: debdiff attached.
REPRODUCE: On Natty run ntpdate against an NTP server where receive and transmit timestamps are equal (Includes windows server 2003).

Test: ntpdate xxx.xxx.xxx.xxx

Expected failure is:
  ntpdate[7149]: no server suitable for synchronization found

Expected success is (example):
  ntpdate[13959]: adjust time server 66.36.239.66 offset 0.144635 sec

DISCUSSION:
Regression potential is considered low. It is a patch cherry picked from upstream, and has been fixed in some other distros since December 2010.

Revision history for this message
In , Rose-g (rose-g) wrote :
Download full text (5.4 KiB)

We have a rather slow inhouse timeserver:
root@cheetah:/home/rose(53)# ping 10.101.10.20
PING 10.101.10.20 (10.101.10.20) 56(84) bytes of data.
64 bytes from 10.101.10.20: icmp_seq=1 ttl=127 time=6.88 ms
64 bytes from 10.101.10.20: icmp_seq=2 ttl=127 time=1.22 ms
64 bytes from 10.101.10.20: icmp_seq=3 ttl=127 time=2.15 ms
64 bytes from 10.101.10.20: icmp_seq=4 ttl=127 time=0.538 ms
64 bytes from 10.101.10.20: icmp_seq=5 ttl=127 time=87.9 ms
64 bytes from 10.101.10.20: icmp_seq=6 ttl=127 time=6.77 ms
64 bytes from 10.101.10.20: icmp_seq=7 ttl=127 time=7.13 ms
64 bytes from 10.101.10.20: icmp_seq=8 ttl=127 time=1.24 ms
64 bytes from 10.101.10.20: icmp_seq=9 ttl=127 time=0.354 ms
64 bytes from 10.101.10.20: icmp_seq=10 ttl=127 time=79.5 ms
64 bytes from 10.101.10.20: icmp_seq=11 ttl=127 time=0.416 ms
64 bytes from 10.101.10.20: icmp_seq=12 ttl=127 time=0.427 ms
64 bytes from 10.101.10.20: icmp_seq=13 ttl=127 time=1.90 ms
^C
--- 10.101.10.20 ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 12011ms
rtt min/avg/max/mdev = 0.354/15.118/87.950/29.409 ms

Setting the system time with net-misc/ntp-4.2.6_p2 fails with:
root@cheetah:/home/rose(33)# ntpdate -v -d -d -b -u 10.101.10.20
23 Jul 12:54:11 ntpdate[813]: ntpdate 4.2.6p2@1.2194-o Mon Jul 19 02:43:33 UTC 2010 (1)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
10.101.10.20: Server dropped: no data
server 10.101.10.20, port 123
stratum 5, precision -17, leap 00, trust 000
refid [10.101.10.20], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: cff3f35a.029c6b63 Fri, Jul 23 2010 12:54:18.010
originate timestamp: cff3f35a.029c6b63 Fri, Jul 23 2010 12:54:18.010
transmit timestamp: cff3f35a.02f5a519 Fri, Jul 23 2010 12:54:18.011
filter delay: 0.00000 0.00000 0.00000 0.00000
         0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

23 Jul 12:54:19 ntpdate[7112]: no server suitable for synchronization found

If I downgrade to net-misc/ntp-4.2.6_p1-r1 I can set the system time:

root@cheetah:/home/rose(35)# emerge -v1 =net-misc/ntp-4.2.6_p1-r1
...
>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

 * IMPORTANT: 13 config files in '/etc' need updating.
 * See the CONFIGURATION FILES section of the emerge
 * man page to learn how to update config files.
root@cheetah:/home/rose(36)# ntpdate -v -d -d -b -u 10.101.10.20
23 Jul 13:06:26 ntpdate[17815]: ntpdate 4.2.6p1@1.2158-o Fri Jul 23 10:59:23 UTC 2010 (1)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
server...

Read more...

Revision history for this message
In , Rose-g (rose-g) wrote :

I have the same issue with net-misc/ntp-4.2.6_p2-r1.

Revision history for this message
In , S-paul-n (s-paul-n) wrote :

I noticed a few days ago that this version's daemon fails to keep my home (behind a broadband router) computer's time correct, and because it doesn't bother saying anything at all about what it's doing in syslog anymore, I had no idea where the problem might lie. Since the ntp documentation is also appallingly opaque, I just downgraded again.

Revision history for this message
In , Michel (michel-redhat-bugs) wrote :

Description of problem:
There is a regression in ntp in the latest version; communication with certain other time servers is really slow and would then be dropped before completion. See logs of the ntpdate -d with both p1 and p2 versions below. This affects Debian testing and Gentoo as well.

Debian report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599793
Gentoo report: http://bugs.gentoo.org/show_bug.cgi?id=329571

Version-Release number of selected component (if applicable):
ntp-4.2.6p2-7.fc14

How reproducible:
Always

Steps to Reproduce:
1. ntpdate -d 131.188.65.129 (unfortunately not available from outside)

Actual results:
Looking for host 131.188.65.129 and service ntp
host found : 131.188.65.129
transmit(131.188.65.129)
receive(131.188.65.129)
transmit(131.188.65.129)
receive(131.188.65.129)
transmit(131.188.65.129)
receive(131.188.65.129)
transmit(131.188.65.129)
receive(131.188.65.129)
transmit(131.188.65.129)
131.188.65.129: Server dropped: no data
server 131.188.65.129, port 123
stratum 2, precision -24, leap 00, trust 000
refid [131.188.65.129], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: d07bfebd.f851ee30 Wed, Nov 3 2010 16:31:09.970
originate timestamp: d07bff47.c624df50 Wed, Nov 3 2010 16:33:27.774
transmit timestamp: d07bff3d.a9463163 Wed, Nov 3 2010 16:33:17.661
filter delay: 0.00000 0.00000 0.00000 0.00000
         0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

 3 Nov 16:33:19 ntpdate[3893]: no server suitable for synchronization found

Expected results:
Looking for host 131.188.65.129 and service ntp
host found : 131.188.65.129
transmit(131.188.65.129)
receive(131.188.65.129)
transmit(131.188.65.129)
receive(131.188.65.129)
transmit(131.188.65.129)
receive(131.188.65.129)
transmit(131.188.65.129)
receive(131.188.65.129)
transmit(131.188.65.129)
server 131.188.65.129, port 123
stratum 2, precision -24, leap 00, trust 000
refid [131.188.65.129], delay 0.02696, dispersion 0.00131
transmitted 4, in filter 4
reference time: d07c02bd.f851ee30 Wed, Nov 3 2010 16:48:13.970
originate timestamp: d07c02ea.991688d0 Wed, Nov 3 2010 16:48:58.598
transmit timestamp: d07c02e0.84b5aed6 Wed, Nov 3 2010 16:48:48.518
filter delay: 0.02869 0.02727 0.02696 0.02783
         0.00000 0.00000 0.00000 0.00000
filter offset: 10.07619 10.07781 10.07629 10.07849
         0.000000 0.000000 0.000000 0.000000
delay 0.02696, dispersion 0.00131
offset 10.076294

 3 Nov 16:48:48 ntpdate[4149]: step time server 131.188.65.129 offset 10.076294 sec

Additional info:

Revision history for this message
In , Miroslav (miroslav-redhat-bugs) wrote :

Can you please repeat the test with ntpdate -dddd and attach also "tcpdump -v port 123" output?

Revision history for this message
In , Michel (michel-redhat-bugs) wrote :

Created attachment 458163
working ntp -dddd log

Revision history for this message
In , Michel (michel-redhat-bugs) wrote :

Created attachment 458164
working ntp tcpdump output

Revision history for this message
In , Michel (michel-redhat-bugs) wrote :

Created attachment 458165
broken ntp -dddd log

Revision history for this message
In , Michel (michel-redhat-bugs) wrote :

Created attachment 458166
broken ntp tcpdump output

Revision history for this message
In , Michel (michel-redhat-bugs) wrote :

Logs attached

Revision history for this message
In , Miroslav (miroslav-redhat-bugs) wrote :

The problem seems to be that the server replies with equal receive and transmit timestamps which fails in a newly added check.

Upstream bugreport filed here:
https://bugs.ntp.org/show_bug.cgi?id=1709

Revision history for this message
In , Rose-g (rose-g) wrote :

More than two month later I still have this problem. The connection to the timeserver seems to be faster:
root@cheetah:/root(34)# ping 10.101.10.20
PING 10.101.10.20 (10.101.10.20) 56(84) bytes of data.
64 bytes from 10.101.10.20: icmp_req=1 ttl=127 time=0.286 ms
64 bytes from 10.101.10.20: icmp_req=2 ttl=127 time=0.315 ms
64 bytes from 10.101.10.20: icmp_req=3 ttl=127 time=0.298 ms
64 bytes from 10.101.10.20: icmp_req=4 ttl=127 time=0.197 ms
64 bytes from 10.101.10.20: icmp_req=5 ttl=127 time=0.354 ms
64 bytes from 10.101.10.20: icmp_req=6 ttl=127 time=0.395 ms
64 bytes from 10.101.10.20: icmp_req=7 ttl=127 time=0.516 ms
64 bytes from 10.101.10.20: icmp_req=8 ttl=127 time=0.388 ms
64 bytes from 10.101.10.20: icmp_req=9 ttl=127 time=0.496 ms
64 bytes from 10.101.10.20: icmp_req=10 ttl=127 time=0.535 ms
64 bytes from 10.101.10.20: icmp_req=11 ttl=127 time=0.221 ms
^C
--- 10.101.10.20 ping statistics ---
11 packets transmitted, 11 received, 0% packet loss, time 9997ms
rtt min/avg/max/mdev = 0.197/0.363/0.535/0.112 ms

But ntpdate still says "Server dropped: no data":

root@cheetah:/root(35)# ntpdate -o 2 -t 5.0 -p 8 -d -d 10.101.10.20
 9 Nov 21:31:30 ntpdate[3227]: ntpdate 4.2.6p2@1.2194-o Wed Jul 28 02:36:37 UTC 2010 (1)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
transmit to 10.101.10.20
receive(10.101.10.20)
transmit(10.101.10.20)
10.101.10.20: Server dropped: no data
server 10.101.10.20, port 123
stratum 5, precision -17, leap 00, trust 000
refid [10.101.10.20], delay 0.00000, dispersion 64.00000
transmitted 8, in filter 8
reference time: d084190a.bc06b19f Tue, Nov 9 2010 20:01:30.734
originate timestamp: d084190a.bc06b19f Tue, Nov 9 2010 20:01:30.734
transmit timestamp: d0842e30.a4d34fbb Tue, Nov 9 2010 21:31:44.643
filter delay: 0.00000 0.00000 0.00000 0.00000
         0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

 9 Nov 21:31:46 ntpdate[3227]: no server suitable for synchronization found

Nmap identifies the timeserver as:

IP ID Sequence Generation: Busy server or unknown class
Service Info: Host: *.*.*.*; OSs: NetWare, Unix

Any idea besides downgrading of ntp to solve the problem?

There is a similar bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599793

Revision history for this message
In , Rose-g (rose-g) wrote :

I posted this bug upstream, compare URL, and got the answer that ntpdate is deprecated. Perhaps gentoo should modify /etc/init.d/ntp-client.

Revision history for this message
In , Mike Frysinger (vapier) wrote :

ntpdate has been "deprecated" for almost a decade at this point. see Bug 21527.

Revision history for this message
In , Rose-g (rose-g) wrote :

If I run 'ntpd -g -q -x -d' instead of 'ntpdate -v -d -d -b -u 10.101.10.20', I see:
root@moose:/tmp/tiff_test(76)# ntpd -g -q -x -d
ntpd 4.2.6p2@1.2194-o Thu Nov 11 09:53:35 UTC 2010 (1)
addto_syslog: proto: precision = 0.102 usec
event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
Finished Parsing!!
addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
addto_syslog: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
addto_syslog: Listen and drop on 1 v6wildcard :: UDP 123
addto_syslog: Listen normally on 2 lo 127.0.0.1 UDP 123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags 00000001
addto_syslog: Listen normally on 3 br0 192.168.2.20 UDP 123
restrict: op 1 addr 192.168.2.20 mask 255.255.255.255 mflags 00003000 flags 00000001
addto_syslog: Listen normally on 4 virbr0 192.168.100.1 UDP 123
restrict: op 1 addr 192.168.100.1 mask 255.255.255.255 mflags 00003000 flags 00000001
addto_syslog: Listen normally on 5 br0 fe80::21f:d0ff:fea1:b79c UDP 123
restrict: op 1 addr fe80::21f:d0ff:fea1:b79c mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
addto_syslog: Listen normally on 6 eth0 fe80::21f:d0ff:fea1:b79c UDP 123
restrict: op 1 addr fe80::21f:d0ff:fea1:b79c mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
addto_syslog: Listen normally on 7 lo ::1 UDP 123
restrict: op 1 addr ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 00000090
restrict: op 1 addr :: mask 0.0.0.0 mflags 00000000 flags 00000090
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags 00000000
key_expire: at 0 associd 55448
peer_clear: at 0 next 1 associd 55448 refid INIT
event at 0 10.101.10.20 8011 81 mobilize assoc 55448
newpeer: 192.168.2.20->10.101.10.20 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0 key 00000000
event at 0 0.0.0.0 c016 06 restart
event at 0 0.0.0.0 c012 02 freq_set ntpd 105.462 PPM
transmit: at 1 192.168.2.20->10.101.10.20 mode 3 len 48
auth_agekeys: at 1 keys 1 expired 0
receive: at 1 192.168.2.20<-10.101.10.20 mode 4 len 48
event at 1 10.101.10.20 8024 84 reachable
clock_filter: n 1 off 0.016817 del 0.000711 dsp 7.937504 jit 0.000000
transmit: at 3 192.168.2.20->10.101.10.20 mode 3 len 48
receive: at 3 192.168.2.20<-10.101.10.20 mode 4 len 48
clock_filter: n 2 off 0.016646 del 0.000439 dsp 3.937513 jit 0.000171
transmit: at 5 192.168.2.20->10.101.10.20 mode 3 len 48
receive: at 5 192.168.2.20<-10.101.10.20 mode 4 len 48
clock_filter: n 3 off 0.016624 del 0.000485 dsp 1.937522 jit 0.000137
transmit: at 7 192.168.2.20->10.101.10.20 mode 3 len 48
receive: at 7 192.168.2.20<-10.101.10.20 mode 4 len 48
clock_filter: n 4 off 0.016485 del 0.000336 dsp 0.937528 jit 0.000227
select: combine offset 0.016485415 jitter 0.000227401
event at 7 10.101.10.20 963a 8a sys_peer
clock_update: at 7 sample 7 associd 55448
addto_syslog: ntpd: time slew +0.016485 s
ntpd: time slew +0.016485s
root@moose:/tmp/tiff_test(77)# echo $?
0

It looks OK for me.

Revision history for this message
In , Michel (michel-redhat-bugs) wrote :

Wonderful, thanks. Will you be building an update, or are we waiting for the next 4.2.6 release?

Revision history for this message
In , Michel Lind (michel-slm) wrote :

The same bug affects Fedora (see the upstream bug report that superceded 1716) and has now been fixed upstream.

https://bugs.ntp.org/show_bug.cgi?id=1709

Revision history for this message
In , Miroslav (miroslav-redhat-bugs) wrote :

Waiting for 4.2.6p3, hopefully it will be released soon. I'd like to make also backports for some other bugs recently fixed in ntp-dev.

Revision history for this message
In , John (john-redhat-bugs) wrote :

I can confirm this bug occurs with Hewlett Packard's internal NTP server at ntp.hp.net. This is probably not available from outside HP's internal LAN. This is the only NTP server accessible by HP employees (external NTP servers are blocked).

This bug is currently blocking our plans to upgrade to Fedora 14.

Revision history for this message
In , Miroslav (miroslav-redhat-bugs) wrote :

I've updated the package to 4.2.6p3-RC10. Upstream said that they are now working only on some build related issues and final release should be here soon.

RC10 can now go to updates-testing and if final 4.2.6p3 is released in a week or so, I'll make a quick update.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

ntp-4.2.6p3-0.1.rc10.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/ntp-4.2.6p3-0.1.rc10.fc14

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

ntp-4.2.6p3-0.1.rc10.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update ntp'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ntp-4.2.6p3-0.1.rc10.fc14

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

ntp-4.2.6p3-0.1.rc10.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message
In , Jeremy Olexa (darkside-gentoo) wrote :

To the best of my knowledge, this bug was fixed in 4.2.6_p3. I've opened a stablereq for that version in bug 365097

Revision history for this message
In , Jeremy Olexa (darkside-gentoo) wrote :

Resolved, obsolete because net-misc/ntp-4.2.6_p2 version isn't even in the tree. Feel free to re-open if I am incorrect. Thanks.

Revision history for this message
David Harper (inquisitivedave) wrote :

Can confirm this doesn't work in Natty, but does in Lucid.

sudo ntpdate 0.pool.ntp.org
31 May 12:14:34 ntpdate[7104]: no server suitable for synchronization found

Is 4.2.6p3 due to be uploaded into Natty (or backports)?

Revision history for this message
Dave Walker (davewalker) wrote :

Confirmed on natty and oneiric. Thanks to Patrick Domack (~patrickdk) for allowing me access to a Windows 2003 ntp server.

Changed in ntp (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ntp - 1:4.2.6.p2+dfsg-1ubuntu8

---------------
ntp (1:4.2.6.p2+dfsg-1ubuntu8) oneiric; urgency=low

  * debian/patches/ntpdate-accept-same-timestamp-replies.patch:
    Resolving regression where ntpdate ignores replies from some
    ntp servers where recieve and transmit timestamps are equal.
    Patch cherry picked from upstream commit. (LP: #787551)
 -- Dave Walker (Daviey) <email address hidden> Mon, 13 Jun 2011 15:22:29 +0100

Changed in ntp (Ubuntu Oneiric):
status: Triaged → Fix Released
Revision history for this message
Dave Walker (davewalker) wrote :
description: updated
Revision history for this message
Dave Walker (davewalker) wrote :
Changed in ntp (Ubuntu Oneiric):
assignee: nobody → Dave Walker (davewalker)
Changed in ntp (Ubuntu Natty):
assignee: nobody → Dave Walker (davewalker)
importance: Undecided → Medium
Changed in ntp (Debian):
status: Unknown → New
Changed in gentoo:
importance: Unknown → Medium
status: Unknown → Expired
Revision history for this message
Vide (vide80) wrote :

Hi

will this be fixed to Natty as well?

Revision history for this message
Dave Walker (davewalker) wrote :

Vide, I have uploaded it to the natty-proposed queue. Need to wait for the ~ubuntu-sru team to review the upload.

Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Accepted ntp into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in ntp (Ubuntu Natty):
status: New → Fix Committed
tags: added: verification-needed
Revision history for this message
Christian Bell (cshbell) wrote :

We were experiencing this problem with ntpdate on our 11.04 server trying to NTP sync with our Windows NTP servers. Tested the version of ntpdate from natty-proposed on our 11.04 server, and it’s working now.

Martin Pitt (pitti)
tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ntp - 1:4.2.6.p2+dfsg-1ubuntu5.1

---------------
ntp (1:4.2.6.p2+dfsg-1ubuntu5.1) natty-proposed; urgency=low

  * debian/patches/ntpdate-accept-same-timestamp-replies.patch:
    Resolving regression where ntpdate ignores replies from some
    ntp servers where recieve and transmit timestamps are equal.
    Patch cherry picked from upstream commit. (LP: #787551)
 -- Dave Walker (Daviey) <email address hidden> Mon, 13 Jun 2011 15:43:57 +0100

Changed in ntp (Ubuntu Natty):
status: Fix Committed → Fix Released
Changed in ntp (Debian):
status: New → Fix Released
Changed in ntp (Fedora):
importance: Unknown → Medium
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.