pppd & ntpd

pppd & ntpd

[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 ?

re,
 wh

Re: pppd & ntpd

[James Carlson]

walter harms wrote:
> 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.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: pppd & ntpd

[Bill Unruh]

On Fri, 30 Oct 2009, walter harms wrote:

> 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)


> i "fixed" the problem with a kill -1 in ip-up.

I have no idea how a kill -1 ( of what?) would fix anything.

>
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
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 |     unruh@physics.ubc.ca
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

Re: pppd & ntpd

[walter harms]

Bill Unruh schrieb:
> On Fri, 30 Oct 2009, walter harms wrote:
> 
>> 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.

	
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.
 	

> 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


> 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)
> 
> 
>> 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

Re: pppd & ntpd

[James Carlson]

walter harms wrote:
> 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.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: pppd & ntpd

[Charlie Brady]

Easiest solution to your problem is likely to be having your client do ntp 
sync against a different server - plenty exist.

Re: pppd & ntpd

[walter harms]

Charlie Brady schrieb:
> 
> 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