ntpd is broken after an IP-change of the WAN-IP: ntpd[18049]: sendto(192.53.103.104) (fd=23): Invalid argument
So fix your configuration and restart it? Or what are you exactly complaining about?
ntpd is not designed to restart a better way is: configure ntpd with LOCAL: server 127.127.1.1 fudge 127.127.1.1 stratum 10 broadcastdelay 0.008 On IP-Down: use unconfig to remove all servers except LOCAL so it looks like: *LOCAL(1) 127.0.0.1 10 64 17 0.00000 0.000000 0.96858 The ntpd is running with the LOCAL server without interuption. On IP-UP: use addserver to add all servers again, now it should look like: =LOCAL(1) 127.0.0.1 10 64 17 0.00000 0.000000 0.96858 =ptbtime2.ptb.de 0.0.0.0 1 64 17 0.02345 0.001455 0.96895 *ptbtime1.ptb.de 0.0.0.0 1 64 17 0.02438 0.001508 0.96858 =ntps1-0.cs.tu-b 0.0.0.0 1 64 13 0.02193 0.000333 1.39236 This works fine with ntp version net-misc/ntp-4.2.0.20040617-r3 and earlier. With this ntp-version after an IP-change ntpd does not honor unconfig and addserver correctly, the servers get added but aren't synced. I consider this as a bug since restarting ntpd on an IP change is a rather dirty hack.
I found a patch which adds ifreload (interface reload) command to ntpdc: http://lists.ntp.isc.org/pipermail/bk-ntp-dev-send/2006-June/000599.html It would be nice to have that as an option in an ebuild, i.e. with useflag: dynamicIP
Additional info to the patch: http://www.ece.udel.edu/~mills/ntp/html/ntpdc.html
Another solution may be to make ntpd listen on wildcard-interface. It seems with this version of ntpd listening on wildcard interface is disabled: ntpd[6719]: Listening on interface wildcard, 0.0.0.0#123 Disabled ntpd[6719]: Listening on interface wildcard, ::#123 Disabled
SORRY FOR THIS; BUT I HAD CONNECTION PROBLEMS SO HERE IS THE FULL TEXT: Another solution may be to make ntpd listen on wildcard-interface. It seems with this version of ntpd listening on wildcard interface is disabled: ntpd[6719]: Listening on interface wildcard, 0.0.0.0#123 Disabled ntpd[6719]: Listening on interface wildcard, ::#123 Disabled The previous ntpd listens on the wildcard-interface: ntpd[20142]: Listening on interface wildcard, 0.0.0.0#123 ntpd[20142]: Listening on interface wildcard, ::#123 I have no idea, why this version of ntpd does not listen on wildcard-interface.
this will be part of the next release
*** Bug 156602 has been marked as a duplicate of this bug. ***
This is not a bug. This is an intended feature. Packets arriving on any of the wildcard ports will be unceremoniously dropped. What you really need here is the dynamic interface code that is now in 4.2.3 development. The 4.2.4 release version due out shortly will contain this code. Danny NTP Development
(In reply to comment #9) > This is not a bug. This is an intended feature. Packets arriving on any of the > wildcard ports will be unceremoniously dropped. > > What you really need here is the dynamic interface code that is now in 4.2.3 > development. The 4.2.4 release version due out shortly will contain this code. > > Danny > NTP Development > thanks Danny for pointing this out
ntp-4.2.2_p4: same bug
ntp 4.2.4 is not working after an IP-change, ifreload does not reload the WAN-interface, addserver still refuses to work. See: https://ntp.isc.org/bugs/show_bug.cgi?id=416
*** Bug 163147 has been marked as a duplicate of this bug. ***
Since all versions of net-misc/ntp-4.2.2 and ntp-4-2-4 have this bug I suggest to add net-misc/ntp-4.2.0.20040617-r3 to portage again, which is the last known version where the addserver command is working and so usable on servers, which dynamic IP.
Informed Upstream
conclusion so far: EITHER make ntpd listen on wildcard interface again OR make the commands ifreload and addserver usable.
(Why is this message form at the top? It means scrolling back and forth a lot.) There is no need for addserver or anything else as of 4.2.4. If the server is nonreachable then it will just continue on. ntpd will rescan the interfaces and use whatever's available for interface addresses. You can adjust the rescan frequency on the command line (I think that's where it is). If you use ntpdc you need to set up a key that you use authenticate so you can make changes. Bug #416 may be due to an issue that Frank just fixed in ntp_intres.c (see bug #761 which needs to be updated). If you aren't using IPv6 or you are looking up a record which only has IPv4 addresses you shouldn't need to worry about this. As far as I know, ifreload works. If not please file a bug report in ntp bugzilla. Make sure that you have authenticated yourself before you issue this command. You would only need it for IP-UP and even then if will do it by itself when the time interval for rescanning expires. We will *not* be reenabling the wildcard interfaces in the future, it causes to many problems. If you have a problem please include the log containing the errors and make sure that you are running ntp 4.2.4 or later. you can check this by running ntpq -c rv against the ntpd server. BTW why do you have broadcastdelay in the configuration file? You don't have any broadcast or multicast clients. Danny
I tested ntp 4.2.4 after an IP-change, which means device ppp0 got a new IP. After the IP-change, the server does not sync anymore to public servers, but switches to LOCAL as per configuration. The log is showing the following errors: Jan 23 03:38:56 pluto ntpd[17912]: sendto(192.53.103.104) (fd=23): Invalid argument Jan 23 03:38:56 pluto ntpd[17912]: sendto(192.53.103.108) (fd=23): Invalid argument Jan 23 03:39:59 pluto ntpd[17912]: sendto(192.53.103.108) (fd=23): Invalid argument Jan 23 03:39:59 pluto ntpd[17912]: sendto(130.149.17.21) (fd=23): Invalid argument Jan 23 03:40:01 pluto ntpd[17912]: sendto(192.53.103.104) (fd=23): Invalid argument Jan 23 03:41:02 pluto ntpd[17912]: sendto(130.149.17.21) (fd=23): Invalid argument Jan 23 03:41:03 pluto ntpd[17912]: sendto(192.53.103.108) (fd=23): Invalid argument Jan 23 03:41:05 pluto ntpd[17912]: sendto(192.53.103.104) (fd=23): Invalid argument Jan 23 03:42:06 pluto ntpd[17912]: sendto(130.149.17.21) (fd=23): Invalid argument Jan 23 03:42:07 pluto ntpd[17912]: sendto(192.53.103.108) (fd=23): Invalid argument Jan 23 03:42:09 pluto ntpd[17912]: sendto(192.53.103.104) (fd=23): Invalid argument Jan 23 03:43:10 pluto ntpd[17912]: sendto(130.149.17.21) (fd=23): Invalid argument Jan 23 03:43:11 pluto ntpd[17912]: sendto(192.53.103.108) (fd=23): Invalid argument Jan 23 03:43:14 pluto ntpd[17912]: sendto(192.53.103.104) (fd=23): Invalid argument Jan 23 03:44:15 pluto ntpd[17912]: sendto(192.53.103.108) (fd=23): Invalid argument Jan 23 03:44:15 pluto ntpd[17912]: sendto(130.149.17.21) (fd=23): Invalid argument Jan 23 03:44:20 pluto ntpd[17912]: sendto(192.53.103.104) (fd=23): Invalid argument ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== ptbtime1.ptb.de .PTB. 1 u 970 64 0 30.867 -0.841 0.000 ptbtime2.ptb.de .PTB. 1 u 969 64 0 31.073 -0.651 0.000 ntps1-0.cs.tu-b .PPS. 1 u 965 64 0 65.565 16.410 0.000 *LOCAL(1) .LOCL. 10 l 63 64 377 0.000 0.000 0.001 I tried to use ifreload from the commandline: ntpdcntpdc> ifreload Keyid: 888 MD5 Password: ***Server reports data not foundntpdc> I double checked with ifstats and the ppp0 device still lists the old IP-address. My Conclusion: ntp 4.2.4 can't handle ip-changes of the wan-interface, may be ifreload does not work. ntpq -c rv assID=0 status=0564 leap_none, sync_local_proto, 6 events, event_peer/strat_chg,version="ntpd 4.2.4@1.1437-o Tue Jan 23 02:22:20 UTC 2007 (1)",processor="i686", system="Linux/2.6.18.6", leap=00, stratum=11,precision=-20, rootdelay=0.000, rootdispersion=11.680, peer=21810,refid=LOCAL(1),reftime=c95ff607.bb6086f2 Tue, Jan 23 2007 3:48:39.731, poll=8,clock=c95ff639.aa74dbeb Tue, Jan 23 2007 3:49:29.665, state=4,offset=0.000, frequency=87.389, jitter=0.001, noise=0.209,stability=0.145, tai=0 @Danny How do you know I don't have any broadcast clients?
i really dont see anything here that is Gentoo specific ... the issues seem to be known upstream and i'm not going to work on it ... i'll just pull down whatever updates upstream puts together so really, you should be posting to an upstream bug report, not here
The only gentoo-specific is related to my comment: https://bugs.gentoo.org/show_bug.cgi?id=147136#c14 I vote for adding that version to portage until we have a ntp which handles ip-changes properly. (btw, I informed Danny (upstream))
no thanks ... viewcvs exists if you want to fetch an older version
Yes this discussion should be taken to the ntp bugzilla. You should also look at bug #765 and #766 over there which deal with some privilege issues. This may be what's happening. You don't show any broadcastclient setup in your conf file and your display of the billboard tells me for sure. Danny
Hi Danny, I am sick dealing with this issue. I switched to the old version of ntp which works perfectly, since it listens on wildcard interface and addserver is working. Well, I still hope you will release a ntp which can handle ip-changes and where addserver is working. Additionally, I would suggest to add "listen on wildcard" as a compiler-option - leave it up to the user. Thanks for your assistance & good luck.
That may be but we will not be putting back support for wildcards and we will not be making this an option. There are too many problems with wildcards to support it. You are free to change the code in any way you want. If you have an issue with the NTP code please take it to the NTP bugzilla and not continue this here. This has already been marked as Resolved Upstream. And please don't add me to the CC list. If I wanted to be notified I would have done that myseld. Danny
Bug @ upstream: https://ntp.isc.org/bugs/show_bug.cgi?id=772
Workaround: Switch back to net-misc/ntp-4.2.0.20040617-r3 This version has been removed from portage, so browse and get it here: http://sources.gentoo.org/ and add it to portage overlay.
2nd Workaround: Use ntp-4.2.4 but without -u ntp:ntp, run as root. Otherwise ifreload is not working.
*** Bug 173548 has been marked as a duplicate of this bug. ***
