Bug 34304 - qa0328 ntpdate only works in DEBUG mode?
qa0328 ntpdate only works in DEBUG mode?
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: ntp (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-01 15:23 EDT by Stephen John Smoogen
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-02 10:24:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephen John Smoogen 2001-04-01 15:23:22 EDT
I am trying to adjust my clock with daylight savings time and realized
that it was time to set up ntp on my home lan. LAN is a 192.168.2.x network
behind a masquerading firewall that is connected to Time Warner cable
network. On the network there are 5 machines (4 of them Red Hat Linux 7.0
and 1 with RHL7.1-qa0328 on it.

On the 7.0 machines I get the following:

root:{smooge}# ntpdate ntp2.usno.navy.mil
 1 Apr 15:19:05 ntpdate[6342]: adjust time server 192.5.41.209 offset
0.093178 sec


root:{smooge}# ntpdate -d -v ntp2.usno.navy.mil
 1 Apr 15:22:26 ntpdate[6346]: ntpdate 4.0.99j Wed Aug 23 13:11:25 EDT 2000 (1)
transmit(192.5.41.209)
receive(192.5.41.209)
transmit(192.5.41.209)
receive(192.5.41.209)
transmit(192.5.41.209)
receive(192.5.41.209)
transmit(192.5.41.209)
receive(192.5.41.209)
transmit(192.5.41.209)
server 192.5.41.209, port 123
stratum 1, precision -17, leap 00, trust 000
refid [USNO], delay 0.12823, dispersion 0.00041
transmitted 4, in filter 4
reference time:    be71fe72.a6589000  Sun, Apr  1 2001 15:22:26.649
originate timestamp: be71fe72.b085b000  Sun, Apr  1 2001 15:22:26.689
transmit timestamp:  be71fe72.a43d9a95  Sun, Apr  1 2001 15:22:26.641
filter delay:  0.12880  0.12936  0.12823  0.12834 
         0.00000  0.00000  0.00000  0.00000 
filter offset: -0.00444 -0.00309 -0.00409 -0.00367
         0.000000 0.000000 0.000000 0.000000
delay 0.12823, dispersion 0.00041
offset -0.004094

 1 Apr 15:22:26 ntpdate[6346]: adjust time server 192.5.41.209 offset
-0.004094 sec

However on the 7.1 box I get the following:

root:{RPMS}# ntpdate -v -v ntp2.usno.navy.mil
 1 Apr 15:14:25 ntpdate[1461]: ntpdate 4.0.99k Mon Mar  5 12:08:05 EST 2001 (1)
 1 Apr 15:14:29 ntpdate[1461]: no server suitable for synchronization found

HOWEVER on the 7.1 box if I go into debug mode it seems to work

root:{RPMS}#  ntpdate -d -v ntp2.usno.navy.mil
 1 Apr 15:17:41 ntpdate[1489]: ntpdate 4.0.99k Mon Mar  5 12:08:05 EST 2001 (1)
transmit(192.5.41.209)
receive(192.5.41.209)
transmit(192.5.41.209)
receive(192.5.41.209)
transmit(192.5.41.209)
receive(192.5.41.209)
transmit(192.5.41.209)
receive(192.5.41.209)
transmit(192.5.41.209)
server 192.5.41.209, port 123
stratum 1, precision -16, leap 00, trust 000
refid [USNO], delay 0.13148, dispersion 0.00220
transmitted 4, in filter 4
reference time:    be71fe87.4f835000  Sun, Apr  1 2001 15:22:47.310
originate timestamp: be71fe93.50b0d000  Sun, Apr  1 2001 15:22:59.315
transmit timestamp:  be71fd55.f1ed4a1a  Sun, Apr  1 2001 15:17:41.945
filter delay:  0.13364  0.13412  0.13148  0.13965 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 317.3146 317.3154 317.3171 317.3129
         0.000000 0.000000 0.000000 0.000000
delay 0.13148, dispersion 0.00220
offset 317.317177

 1 Apr 15:17:42 ntpdate[1489]: step time server 192.5.41.209 offset
317.317177 sec
Comment 1 Glen Foster 2001-04-02 09:51:26 EDT
This defect considered MUST-FIX for Florence Gold
Comment 2 Preston Brown 2001-04-02 10:07:04 EDT
I don't think we have really identified the problem:

[pbrown@dionysus pbrown]$ sudo ntpdate -d ntp2.usno.navy.mil
 2 Apr 10:07:16 ntpdate[20497]: ntpdate 4.0.99k Mon Mar  5 12:08:05 EST 2001 
(1)transmit(192.5.41.209)
transmit(192.5.41.209)
transmit(192.5.41.209)
transmit(192.5.41.209)
transmit(192.5.41.209)
server 192.5.41.209, port 123
stratum 0, precision 0, leap 00, trust 000
refid [0.0.0.0], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  1:28:16.000
originate timestamp: 00000000.00000000  Thu, Feb  7 2036  1:28:16.000
transmit timestamp:  be730617.c38af3e4  Mon, Apr  2 2001 10:07:19.763
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
 
 2 Apr 10:07:20 ntpdate[20497]: no server suitable for synchronization found

I believe this is a firewall issue.
Comment 3 Preston Brown 2001-04-02 10:08:54 EDT
notice the lack of receives.  They are getting filtered/firewalled.
Comment 4 Preston Brown 2001-04-02 10:24:39 EDT
now note something definitely not firewalled off:

[pbrown@dionysus pbrown]$ sudo ntpdate -d clock.corp.redhat.com
 2 Apr 10:25:25 ntpdate[20965]: ntpdate 4.0.99k Mon Mar  5 12:08:05 EST 2001 
(1)transmit(207.175.43.182)
receive(207.175.43.182)
transmit(207.175.43.182)
receive(207.175.43.182)
transmit(207.175.43.182)
receive(207.175.43.182)
transmit(207.175.43.182)
receive(207.175.43.182)
transmit(207.175.43.182)
server 207.175.43.182, port 123
stratum 3, precision -17, leap 00, trust 000
refid [152.2.21.1], delay 0.02582, dispersion 0.00000
transmitted 4, in filter 4
reference time:    be7309b5.e20f3cb3  Mon, Apr  2 2001 10:22:45.883
originate timestamp: be730a55.93ea704b  Mon, Apr  2 2001 10:25:25.577
transmit timestamp:  be730a55.945a5fc7  Mon, Apr  2 2001 10:25:25.579
filter delay:  0.02588  0.02583  0.02582  0.02582
         0.00000  0.00000  0.00000  0.00000
filter offset: -0.00183 -0.00184 -0.00184 -0.00184
         0.000000 0.000000 0.000000 0.000000
delay 0.02582, dispersion 0.00000
offset -0.001841
 
 2 Apr 10:25:25 ntpdate[20965]: adjust time server 207.175.43.182 offset 
-0.001841 sec

Are you sure you have no firewall settings in effect on the 7.1 box at home?

Note You need to log in before you can comment on or make changes to this bug.