pppd & ntpd
Hi list,
the question is a bit of topic, but
has someone a dial-in server with ntpd running ? we have noticed that 'ntpd 4.2.4p6' seems to have problems accepting connections from ppp0.
i "fixed" the problem with a kill -1 in ip-up.
did someone see such problem before ?
re,
wh
Quoted 9 lines · walter harms
Hi list,
the question is a bit of topic, but
has someone a dial-in server with ntpd running ? we have noticed that 'ntpd 4.2.4p6' seems to have problems accepting connections from ppp0.i "fixed" the problem with a kill -1 in ip-up.
did someone see such problem before ?
Yes. Most of the ntpd/xntpd variants out there read the system interfaces just once when they start (SIOCGIFCONF) in order to bind a local address on every interface, and then do not check automatically for new interfaces (either by periodic SIOCGIFCONF or more reasonably by routing sockets).
I know there are folks in the OpenSolaris world working on this problem (specifically by using socket options that eliminate the need for binding all addresses individually in the first place), but I'm not sure what's going on for Linux. It's worth asking the ntp folks about.
In the meantime, a kill -HUP sounds fairly reasonable.
Signature · 1 line
James Carlson 42.703N 71.076W <[email protected]>
Quoted 6 lines · walter harms
Hi list,
the question is a bit of topic, but
has someone a dial-in server with ntpd running ?
we have noticed that 'ntpd 4.2.4p6' seems
to have problems accepting connections from ppp0.
Lets understand your problem a bit better. You have a machine which is connected to the net via ppp. That machine is listed as an ntp server on another machine. That other machine is having trouble syncing to this machine.
What evidence do you have that the the problem is "accepting connections"? Do you have a tcpdump which shows that the ntp packets are being dropped by the server (ie not being processed ) (up the poll interval to 4 on the outside machine so you can see the packets over a reasonable period of time)
Quoted 1 line
i "fixed" the problem with a kill -1 in ip-up.
I have no idea how a kill -1 ( of what?) would fix anything.
Quoted 11 lines
did someone see such problem before ?
re,
wh--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 4 lines
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | [email protected] Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
Quoted 9 lines · Bill Unruh
Quoted 6 lines · walter harms
Hi list,
the question is a bit of topic, but
has someone a dial-in server with ntpd running ? we have noticed that 'ntpd 4.2.4p6' seems to have problems accepting connections from ppp0.
Quoted 4 lines
Lets understand your problem a bit better. You have a machine which is connected to the net via ppp. That machine is listed as an ntp server on another machine. That other machine is having trouble syncing to this machine.
the box in question has 2 interfaces: 1.permanent eth0 2. demand ppp0 the box is running the ntpd and it works.
now a 2. box is connecting via modem (ppp0) and tries to get time vi ntp. This fails often.
Quoted 3 lines
What evidence do you have that the the problem is "accepting connections"? Do you have a tcpdump which shows that the ntp packets are being dropped by
no, i took a look with "netstat -l" and you can see the daemon listen to ip:ntp
Quoted 8 lines
the server (ie not being processed ) (up the poll interval to 4 on the outside
machine so you can see the packets over a reasonable period of time)Quoted 1 line
i "fixed" the problem with a kill -1 in ip-up.
I have no idea how a kill -1 ( of what?) would fix anything.
As James pointed out ntpd is reading the interface list at start (i did not read the code so do not take it literal). so when ip-up is called by pppd it does a "kill -HUP $(pidof ntpd)". This causes ntpd to reread the interfaces (confirmed with netstat -l) and it replys propperly.
It seems that ntpd is scanning the interfaces from time to time because it notice sometimes that ppp0 is there and stays for a while. That means if someone is testing and it works, it may work again if the redail is soon enought (interface not droped yet) but if it takes a bit longer (e.g. you have a phonecall) it does not work anymore.
hope that helps,
wh
Quoted 5 lines · walter harms
It seems that ntpd is scanning the interfaces from time to time because it notice sometimes that ppp0 is there and stays for a while. That means if someone is testing and it works, it may work again if the redail is soon enought (interface not droped yet) but if it takes a bit longer (e.g. you have a phonecall) it does not work anymore.
Good that it's rescanning from time to time (probably 10 minute intervals or so, I'd guess), but that's just a band-aid over a design flaw in the daemon. If the system architecture really requires all those separate bound sockets, then it should be listening on a routing socket to get a timely notification of interfaces coming and going, and using a scan only as a back-up in case a message gets lost (the kernel's writes into routing socket listeners are non-blocking and thus not entirely reliable under stress).
Of course, if the system architecture doesn't require a zillion open sockets, then that's even better.
In any event, not really a pppd issue, but rather an ntpd/xntpd issue.
Signature · 1 line
James Carlson 42.703N 71.076W <[email protected]>
Easiest solution to your problem is likely to be having your client do ntp sync against a different server - plenty exist.
Quoted 4 lines · Charlie Brady
Easiest solution to your problem is likely to be having your client do ntp sync against a different server - plenty exist.
This is no solution for this special case, there is only one server in reach and that is exactly the server that does have the problem.
re,
wh