Bug 173972 - ntp fails when IP address changes
ntp fails when IP address changes
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: ntp (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Raszyk
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-23 03:40 EST by Avi Kivity
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-30 10:12:19 EST
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 Avi Kivity 2005-11-23 03:40:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.2 (like Gecko)

Description of problem:
If ntp runs on machine which has changing IPs (like my adsl-connected 
machine), and the IP changes, ntpd loses synchronization and does not recover. 
 
For example, my log shows: 
 
Nov 23 08:40:52 firebolt pppd[5367]: local  IP address 82.81.29.35 
Nov 23 08:48:40 firebolt ntpd[2162]: sendto(192.114.62.249): Invalid argument 
(repeats every few minutes) 
 
and 
 
[avi@firebolt ~]$ ntpstat 
synchronised to local net at stratum 11 
   time correct to within 12 ms 
   polling server every 1024 s 
 
some hours later 

Version-Release number of selected component (if applicable):
ntp-4.2.0.a.20040617-8

How reproducible:
Always

Steps to Reproduce:
1. Run ntp normally 
2. Cause your IP to be changed by kicking the modem 
3. Watch ntp lose synchronization 
   

Actual Results:  ntp lost sync  

Expected Results:  ntp should work with the new address 

Additional info:

[avi@firebolt ~]$ /sbin/ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:C0:F0:0A:46:9F 
          inet addr:10.10.0.1  Bcast:10.10.0.255  Mask:255.255.255.0 
          inet6 addr: fe80::2c0:f0ff:fe0a:469f/64 Scope:Link 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
          RX packets:2119261 errors:0 dropped:0 overruns:0 frame:1 
          TX packets:1898649 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:40 txqueuelen:1000 
          RX bytes:584922091 (557.8 MiB)  TX bytes:260773178 (248.6 MiB) 
          Interrupt:5 Base address:0x300 
 
lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0 
          inet6 addr: ::1/128 Scope:Host 
          UP LOOPBACK RUNNING  MTU:16436  Metric:1 
          RX packets:957844 errors:0 dropped:0 overruns:0 frame:0 
          TX packets:957844 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:0 txqueuelen:0 
          RX bytes:136897698 (130.5 MiB)  TX bytes:136897698 (130.5 MiB) 
 
ppp0      Link encap:Point-to-Point Protocol 
          inet addr:82.81.29.35  P-t-P:82.81.29.1  Mask:255.255.255.255 
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1452  Metric:1 
          RX packets:10077 errors:0 dropped:0 overruns:0 frame:0 
          TX packets:11022 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:0 txqueuelen:3 
          RX bytes:4645132 (4.4 MiB)  TX bytes:1145894 (1.0 MiB) 
 
tun0      Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:10.8.0.14  P-t-P:10.8.0.13  Mask:255.255.255.255 
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1 
          RX packets:193057 errors:0 dropped:0 overruns:0 frame:0 
          TX packets:191354 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:0 txqueuelen:100 
          RX bytes:26245104 (25.0 MiB)  TX bytes:10760095 (10.2 MiB) 
 
tun6to4   Link encap:IPv6-in-IPv4 
          inet6 addr: 2002:5251:1d23::1/16 Scope:Global 
          UP RUNNING NOARP  MTU:1480  Metric:1 
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0 
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Comment 1 Petr Raszyk 2005-11-28 06:25:10 EST
If your IP-address has been changed, you must restart ntpd.

Or you can run 'ntpdate' in a batch (as root):
------------------------------------------

 for ((;;))
   do
      sleep 10;
      echo 'I try sinc my date/time';
      ntpdate -b pool.ntp.org

  done
------------------------------------------

Comment 2 Avi Kivity 2005-11-28 12:38:23 EST
Servers should not fail randomly; there is no one to restart them. 
 
In this case, the server doesn't even exit, it just stops syncing and time 
begins to drift. 
 
Running ntpdate in a loop is not a solution since it does not do frequency 
compensation and is probably a drain on timeserver resources. 
Comment 3 Petr Raszyk 2005-11-29 07:30:51 EST
Servers should not fail randomly;            YES
there is no one to restart them              YES (but cron can ...)
....the server doesn't even exit,..          GREAT
Running ntpdate in a loop is not a solution  YES

RESUME:
Your IP-address should be fixed (not changing)
Comment 4 Avi Kivity 2005-11-29 14:35:32 EST
>Servers should not fail randomly;            YES     
Agree     
     
>there is no one to restart them              YES (but cron can ...)    
Random users should not need to write cron jobs to restart servers. 
   
>....the server doesn't even exit,..          GREAT   
It does no useful work, either. 
   
>Running ntpdate in a loop is not a solution  YES  
And?  
  
>RESUME: 
>Your IP-address should be fixed (not changing) 
 
Dynamic IP addressed are a reality. Right now ntpd is useless for most ADSL 
users. 
 
Please fix this bug. It is embarrassing to have ntpd fail on such a common 
scenario as dynamic IP. 
Comment 5 Petr Raszyk 2005-11-30 10:11:35 EST
I assume you will use ntpd as a client (instead of ntpdate).
A primary goal of ntpd is to work as a server.
A server is a 'service' for a clients.
A client can connect to a server via fixed IP-address.
If the address of a server is not 'fix', the client cannot connect to them.


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