Hello,

	I'm having an issue with ntp 4.2.0-a on FreeBSD 5.4-p4 system.  It
seems that ntpd is recording bad file descriptor errors in the system
log.  This seems to happen every 9-10 minutes or so.  I have a copy of
the logs below as well as my /etc/ntp.conf file.  This has been going on
for awhile now, and I'm not sure when it started.  Any idea as to what
is causing this problem?


----FILE: /var/log/messages
Aug  3 03:18:00 wildfire ntpd[933]: sendto(198.60.22.240): Bad file
descriptor
Aug  3 03:18:01 wildfire ntpd[933]: sendto(204.123.2.5): Bad file descriptor
Aug  3 03:18:01 wildfire ntpd[933]: sendto(207.46.130.100): Bad file
descriptor
Aug  3 03:18:02 wildfire ntpd[933]: sendto(198.60.22.240): Bad file
descriptor
Aug  3 03:18:02 wildfire ntpd[933]: sendto(18.72.0.3): Bad file descriptor
Aug  3 03:18:03 wildfire ntpd[933]: sendto(192.36.144.23): Bad file
descriptor
Aug  3 03:18:03 wildfire ntpd[933]: sendto(204.123.2.5): Bad file descriptor
Aug  3 03:18:03 wildfire ntpd[933]: sendto(207.46.130.100): Bad file
descriptor
Aug  3 03:18:03 wildfire ntpd[933]: sendto(209.81.9.7): Bad file descriptor
Aug  3 03:18:04 wildfire ntpd[933]: sendto(198.60.22.240): Bad file
descriptor



----FILE: /etc/ntp.conf
server time.windows.com iburst
server clepsydra.dec.com iburst
server bitsy.mit.edu iburst
server time.xmission.com iburst
server clock.via.net iburst
server clock.isc.org iburst
server ntp2.sth.netnod.se iburst
server ntp2.sp.se iburst
server us.pool.ntp.org iburst

restrict 192.168.0.0 mask 255.255.255.0 nopeer nomodify notrap kod
restrict 127.0.0.1 mask 255.0.0.0




Any help is appriciated.  Thank you.

-- 
Daniel Rudy

Email address has been encoded to reduce spam.
Remove all numbers, then remove invalid, email, no, and spam to reply.

It makes no sense to have so many iburst options - on all time servers.
You may have one or maybe two servers with iburst - but you MUST have
the server administrator aproval to use it.

Make a test with no iburst option and see what's hapenning.

Please include the "ntpq -c pe" command result in your next post.

On 2005-08-05, Eugen COCA <ecoca@eed.usv.ro> wrote:

> It makes no sense to have so many iburst options - on all time servers.

Using iburst on all your remote time servers does not hurt. In fact,
doing so is a good way to insure that you achieve the fastest possible
synchronization in the event that some your remote time servers are
unreachable.

> You may have one or maybe two servers with iburst

There is no such limit.

>- but you MUST have the server administrator aproval to use it.

Absolutely not.

You are confusing 'burst' and 'iburst'. The former multiplies the number
of packets sent by the 'client' at every poll interval; effectively
turning one client into many. The latter only multiplies the number of
packets sent during the intial synchronization.

Only 'burst' is considered unfriendly when used without permission.

> Make a test with no iburst option and see what's hapenning.

The original poster's problem is nothing to do with his use of 'iburst'.

-- 
Steve Kostecke <kostecke@ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/

Sorry, I misunderstood the problem.

At about the time of 8/5/2005 12:07 PM, Eugen COCA stated the following:

> Sorry, I misunderstood the problem.
> 

No problem, no harm done.

Anyways, I did take iburst off all servers and I still have the same
problem.  Here is the output of the command that you requested:

wildfire:/etc 1035 ### ->ntpq -c pe
No association ID's returned


-- 
Daniel Rudy

Email address has been encoded to reduce spam.
Remove all numbers, then remove invalid, email, no, and spam to reply.

Daniel Rudy wrote:
> Hello,
> 
> 	I'm having an issue with ntp 4.2.0-a on FreeBSD 5.4-p4 system.  It
> seems that ntpd is recording bad file descriptor errors in the system
> log.  This seems to happen every 9-10 minutes or so.  I have a copy of
> the logs below as well as my /etc/ntp.conf file.  This has been going on
> for awhile now, and I'm not sure when it started.  Any idea as to what
> is causing this problem?
> 
> 
> ----FILE: /var/log/messages
> Aug  3 03:18:00 wildfire ntpd[933]: sendto(198.60.22.240): Bad file
> descriptor
> Aug  3 03:18:01 wildfire ntpd[933]: sendto(204.123.2.5): Bad file descriptor
> Aug  3 03:18:01 wildfire ntpd[933]: sendto(207.46.130.100): Bad file
> descriptor
> Aug  3 03:18:02 wildfire ntpd[933]: sendto(198.60.22.240): Bad file
> descriptor
> Aug  3 03:18:02 wildfire ntpd[933]: sendto(18.72.0.3): Bad file descriptor
> Aug  3 03:18:03 wildfire ntpd[933]: sendto(192.36.144.23): Bad file
> descriptor
> Aug  3 03:18:03 wildfire ntpd[933]: sendto(204.123.2.5): Bad file descriptor
> Aug  3 03:18:03 wildfire ntpd[933]: sendto(207.46.130.100): Bad file
> descriptor
> Aug  3 03:18:03 wildfire ntpd[933]: sendto(209.81.9.7): Bad file descriptor
> Aug  3 03:18:04 wildfire ntpd[933]: sendto(198.60.22.240): Bad file
> descriptor
> 
> 
> 
> ----FILE: /etc/ntp.conf
> server time.windows.com iburst
> server clepsydra.dec.com iburst
> server bitsy.mit.edu iburst
> server time.xmission.com iburst
> server clock.via.net iburst
> server clock.isc.org iburst
> server ntp2.sth.netnod.se iburst
> server ntp2.sp.se iburst
> server us.pool.ntp.org iburst
> 
> restrict 192.168.0.0 mask 255.255.255.0 nopeer nomodify notrap kod
> restrict 127.0.0.1 mask 255.0.0.0
> 
> 
> 
> 
> Any help is appriciated.  Thank you.
> 

   I have not checked the code, but you appear to have a very 
pesssimistic list of servers. As this is just something that appears 
intermittently it may be related to the number you have defined.
Five should be enough even for the purists. Try that and see if it fixes 
the issue.

At about the time of 8/6/2005 8:26 AM, mike stated the following:

> Daniel Rudy wrote:
> 
>>Hello,
>>
>>	I'm having an issue with ntp 4.2.0-a on FreeBSD 5.4-p4 system.  It
>>seems that ntpd is recording bad file descriptor errors in the system
>>log.  This seems to happen every 9-10 minutes or so.  I have a copy of
>>the logs below as well as my /etc/ntp.conf file.  This has been going on
>>for awhile now, and I'm not sure when it started.  Any idea as to what
>>is causing this problem?
>>
>>Any help is appriciated.  Thank you.
>>
> 
> 
>    I have not checked the code, but you appear to have a very 
> pesssimistic list of servers. As this is just something that appears 
> intermittently it may be related to the number you have defined.
> Five should be enough even for the purists. Try that and see if it fixes 
> the issue.

New Config File:

wildfire:/etc 1033 ### ->cat ntp.conf
#server time.windows.com iburst
#server clepsydra.dec.com iburst
#server time.xmission.com iburst
#server ntp2.sth.netnod.se iburst
#server ntp2.sp.se iburst
server bitsy.mit.edu iburst
server clock.via.net iburst
server clock.isc.org iburst
server us.pool.ntp.org iburst

restrict 192.168.0.0 mask 255.255.255.0 nopeer nomodify notrap kod
restrict 127.0.0.1 mask 255.0.0.0



Aug  7 13:01:06 wildfire ntpd[8337]: sendto(209.81.9.7): Bad file descriptor
Aug  7 13:01:06 wildfire ntpd[8337]: sendto(24.130.207.189): Bad file
descriptor
Aug  7 13:01:07 wildfire ntpd[8337]: sendto(204.152.184.72): Bad file
descriptor
Aug  7 13:01:07 wildfire ntpd[8337]: sendto(18.72.0.3): Bad file descriptor
Aug  7 13:01:08 wildfire ntpd[8337]: sendto(209.81.9.7): Bad file descriptor
Aug  7 13:01:08 wildfire ntpd[8337]: sendto(24.130.207.189): Bad file
descriptor
Aug  7 13:01:09 wildfire ntpd[8337]: sendto(204.152.184.72): Bad file
descriptor
Aug  7 13:01:09 wildfire ntpd[8337]: sendto(18.72.0.3): Bad file descriptor
Aug  7 13:01:10 wildfire ntpd[8337]: sendto(209.81.9.7): Bad file descriptor
Aug  7 13:01:10 wildfire ntpd[8337]: sendto(24.130.207.189): Bad file
descriptor


Same problem with only 4 servers.  And as someone else suggested, I did
remove the iburst option to no avail.

wildfire:/etc 1034 ### ->/usr/sbin/ntpd --version
/usr/sbin/ntpd: ntpd 4.2.0-a Tue Jul 19 00:50:14 PDT 2005 (1)

wildfire:/etc 1035 ### ->uname -a
FreeBSD wildfire..org 5.4-RELEASE-p4 FreeBSD 5.4-RELEASE-p4 #4: Tue Jul
19 02:29:40 PDT 2005 root@strata:/usr/obj/usr/src/sys/WILDFIRE  i386


-- 
Daniel Rudy

Email address has been encoded to reduce spam.
Remove all numbers, then remove invalid, email, no, and spam to reply.

Daniel Rudy wrote:
> At about the time of 8/6/2005 8:26 AM, mike stated the following:
> 
> 
>>Daniel Rudy wrote:
>>
>>
>>>Hello,
>>>
>>>	I'm having an issue with ntp 4.2.0-a on FreeBSD 5.4-p4 system.  It
>>>seems that ntpd is recording bad file descriptor errors in the system
>>>log.  This seems to happen every 9-10 minutes or so.  I have a copy of
>>>the logs below as well as my /etc/ntp.conf file.  This has been going on
>>>for awhile now, and I'm not sure when it started.  Any idea as to what
>>>is causing this problem?
>>>
>>>Any help is appriciated.  Thank you.
>>>
>>
>>
>>   I have not checked the code, but you appear to have a very 
>>pesssimistic list of servers. As this is just something that appears 
>>intermittently it may be related to the number you have defined.
>>Five should be enough even for the purists. Try that and see if it fixes 
>>the issue.
> 
> 
> New Config File:
> 
> wildfire:/etc 1033 ### ->cat ntp.conf
> #server time.windows.com iburst
> #server clepsydra.dec.com iburst
> #server time.xmission.com iburst
> #server ntp2.sth.netnod.se iburst
> #server ntp2.sp.se iburst
> server bitsy.mit.edu iburst
> server clock.via.net iburst
> server clock.isc.org iburst
> server us.pool.ntp.org iburst
> 
> restrict 192.168.0.0 mask 255.255.255.0 nopeer nomodify notrap kod
> restrict 127.0.0.1 mask 255.0.0.0
> 
> 
> 
> Aug  7 13:01:06 wildfire ntpd[8337]: sendto(209.81.9.7): Bad file descriptor
> Aug  7 13:01:06 wildfire ntpd[8337]: sendto(24.130.207.189): Bad file
> descriptor
> Aug  7 13:01:07 wildfire ntpd[8337]: sendto(204.152.184.72): Bad file
> descriptor
> Aug  7 13:01:07 wildfire ntpd[8337]: sendto(18.72.0.3): Bad file descriptor
> Aug  7 13:01:08 wildfire ntpd[8337]: sendto(209.81.9.7): Bad file descriptor
> Aug  7 13:01:08 wildfire ntpd[8337]: sendto(24.130.207.189): Bad file
> descriptor
> Aug  7 13:01:09 wildfire ntpd[8337]: sendto(204.152.184.72): Bad file
> descriptor
> Aug  7 13:01:09 wildfire ntpd[8337]: sendto(18.72.0.3): Bad file descriptor
> Aug  7 13:01:10 wildfire ntpd[8337]: sendto(209.81.9.7): Bad file descriptor
> Aug  7 13:01:10 wildfire ntpd[8337]: sendto(24.130.207.189): Bad file
> descriptor
> 
> 
> Same problem with only 4 servers.  And as someone else suggested, I did
> remove the iburst option to no avail.
> 
> wildfire:/etc 1034 ### ->/usr/sbin/ntpd --version
> /usr/sbin/ntpd: ntpd 4.2.0-a Tue Jul 19 00:50:14 PDT 2005 (1)
> 
> wildfire:/etc 1035 ### ->uname -a
> FreeBSD wildfire..org 5.4-RELEASE-p4 FreeBSD 5.4-RELEASE-p4 #4: Tue Jul
> 19 02:29:40 PDT 2005 root@strata:/usr/obj/usr/src/sys/WILDFIRE  i386
> 
> 
Doing some googling finds that this is not a new problem.
albus  cialug@cialug.org
Mon, 14 Mar 2005 16:57:05 -0600
  found that he had 2 instances of ntpd running at the time the messages 
occured. When he fixed that, the problem was corrected. Have you checked 
that?

At about the time of 8/7/2005 1:38 PM, mike stated the following:
> 
> Doing some googling finds that this is not a new problem.
> albus  cialug@cialug.org
> Mon, 14 Mar 2005 16:57:05 -0600
>   found that he had 2 instances of ntpd running at the time the messages 
> occured. When he fixed that, the problem was corrected. Have you checked 
> that?

No, I didn't even consider checking that.  After doing so, I found 3
instances of ntpd running.  I terminated all three and restarted ntpd
and now it seems to be working properly.  Now that I think about it, I
have a pretty good idea as to what happened.  Thank you for your assistance.

-- 
Daniel Rudy

Email address has been encoded to reduce spam.
Remove all numbers, then remove invalid, email, no, and spam to reply.

Dear all,

The problem I met concerns ntpd when a changes in the network interface
set occurs.

My Linux system (on which runs ntpd-2.4.0) has two links to Internet:
one is permanent (except upon hardware failure), the second is a backup
modem line.

Actually the "permanent" link is broken so the dialup modem line is in
action, and a ppp0 interface goes up and down upon request. If I launch
ntpd when the link is down, ntpd will never synchronize with peers even 
when the link comes back short after: it has a wildcard UDP socket 
opened on port 123 and for each other interfaces that existed when ntpd 
was launched, it has an UDP interface specific socket on port 123 too 
(information given by the netstat command). The problem is that when the 
link goes up then ntpd does not seems using the wildcard socket to try 
to reach peers and does not create a new UDP interface specific socket 
for this new interface (ppp0) so peers stay unreachable as reported by 
ntpdc, even long after the link came back (tried more than 2 hours).

In the other way, if I launch ntpd when the link is up, it properly
exchange time information with its peers, but when the link goes down,
it keeps its UDP interface specific socket opened on ppp0 interface
while this ppp0 interface is now down. At that time I start having

	"ntpd[11911]: sendto(x.x.x.x): Invalid argument"

messages as reported by syslog (with x.x.x.x rotating with all the IP
address of the configured peers). The worse thing is that when the link
comes back, ntpd still has his old socket opened, but still are reported
a lot of "Invalid Socket" messages and of course, ntpd cannot anymore
synchronize with ntp peers.

- What is the use of this wildcard UDP socket (it does not seems used)?
- Why does ntpd uses theses UDP specific interfaces sockets, while the
configuration file does not specify any interface to listen on or to not
listen on?
- How to have ntpd be able to work with a dialup link?


Any help is (very) welcome. :-)


Regards,
Denis.

--
edrusba@free.fr
remove the a letter in the email above

At 10:09 PM +0200 2005-08-12, Edrusb wrote:

>  The problem I met concerns ntpd when a changes in the network interface
>  set occurs.

	When the network interface changes, you need to restart ntpd. 
This is a known limitation in the current code and something that 
we're hoping to get fixed soon, but this is the way it currently is.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

See:

 http://ntp.isc.org/bin/view/Support/ConfiguringNTP#Section_6.8.

H

On 2005-08-12, Edrusb <edrusba@free.fr> wrote:

> The problem I met concerns ntpd when a changes in the network interface
> set occurs.

<snip>

> - How to have ntpd be able to work with a dialup link?

1. Run your ntpd (that uses remote time servers) on an a system that is
"behind" the one with the dynamic IP addresses.

or

2. Restart ntpd in your DHCP ip-change script. If you use 'iburst' on
your server lines you will acquire sync in 15-30 seconds after ntpd
restarts.

-- 
Steve Kostecke <kostecke@ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/

At about the time of 8/12/2005 1:09 PM, Edrusb stated the following:

> Dear all,
> 
> The problem I met concerns ntpd when a changes in the network interface
> set occurs.
> 
> My Linux system (on which runs ntpd-2.4.0) has two links to Internet:
> one is permanent (except upon hardware failure), the second is a backup
> modem line.
> 

I actually ran into this problem myself.  If the IP address on the
interface changes, ntpd needs to be restarted to bind to the new
address.  AFAIK, the development team is working to resolve this issue.

-- 
Daniel Rudy

Email address has been encoded to reduce spam.
Remove all numbers, then remove invalid, email, no, and spam to reply.

In article <hmvidd.pdc.ln@barnabe.home.fr>, Edrusb <edrusba@free.fr> wrote:

> - What is the use of this wildcard UDP socket (it does not seems used)?

Handles incoming requests?

> - Why does ntpd uses theses UDP specific interfaces sockets, while the
> configuration file does not specify any interface to listen on or to not
> listen on?

I believe this is because the security features require the origin
address to be known by the sender (possibly only for servers).

> - How to have ntpd be able to work with a dialup link?

NTP is not designed for use over intermittent connections.  The real
reason that this interface address problem is an issue is that some
low cost broadband suppliers deliberately mis-operate DHCP to make
their customers' IP addresses unstable and prevent them running servers
on home user accounts.

What I do with intermittent connections is to trim out the static
component of the frequency error using ntptime and tickadj and then
occassionally re-correct the phase using ntpdate, making sure that I
do it when the line is idle.

> Any help is (very) welcome. :-)

As noted elsewhere, you can do IP address masquerading down stream so that
ntpd sees a fixed address.

David Woolley wrote:
> In article <hmvidd.pdc.ln@barnabe.home.fr>, Edrusb <edrusba@free.fr> wrote:
> 
> 
>>- What is the use of this wildcard UDP socket (it does not seems used)?
> 
> 
> Handles incoming requests?

Yes probably, it is too bad the same socket has not been used to send 
data too, just leting the system put the appropriate Source IP and 
select the adequate output interface according to system's routing 
decision. This way there would not have any need to scan available 
network interfaces for changes.

 >>- Why does ntpd uses theses UDP specific interfaces sockets, while the
 >>configuration file does not specify any interface to listen on or to not
 >>listen on?
 >
 >
 > I believe this is because the security features require the origin
 > address to be known by the sender (possibly only for servers).

the outgoing IP packets have their IP source field set by the system in 
any way I guess, even when sending from a wildcard socket.


> 
[...]
> 
>>Any help is (very) welcome. :-)
> 
> 
> As noted elsewhere, you can do IP address masquerading down stream so that
> ntpd sees a fixed address.

Thanks for the idea, but public servers still have static IP address :-) 
masquerading them would not help :-/

I have a "tap" interfaces that handles the traffic when the link is down 
for dial on demand (see "diald" interesting and powerful program), 
unfortunately, ntpd does not bind a socket to this interface! Too bad.

I guess, the best solution waiting for next ntpd release, as described 
by Steve Kostecke, is to have my local ntpd server for my local network 
be "inside" the network without any dynamic IP address.


Thansk to all,

Cheers,
Denis.

At 12:18 PM +0200 2005-08-13, Edrusb wrote:

>  Yes probably, it is too bad the same socket has not been used to send
>  data too, just leting the system put the appropriate Source IP and
>  select the adequate output interface according to system's routing
>  decision. This way there would not have any need to scan available
>  network interfaces for changes.

	Nice theory, but it doesn't work that way in practice.  Dig deep 
into the code of programs like ntpd, BIND, and sendmail if you want 
to understand why, but be prepared to spend a significant amount of 
time learning about cross-platform issues, problems with IPv4 versus 
IPv6, guaranteeing that reply packets always come from the same 
interface and IP address that the query was sent to, and a whole host 
of other problems.

	It's just not that simple.

>  I have a "tap" interfaces that handles the traffic when the link is
>  down for dial on demand (see "diald" interesting and powerful
>  program), unfortunately, ntpd does not bind a socket to this
>  interface! Too bad.

	Well, ntpd should bind to all interfaces that are up at the time 
it starts, and remain bound to them until it is restarted.  So, if 
that tap interface works at all times, and remains consistent at all 
times, you shouldn't have any problems.

>  I guess, the best solution waiting for next ntpd release, as described
>  by Steve Kostecke, is to have my local ntpd server for my local network
>  be "inside" the network without any dynamic IP address.

	Either that, or stopping and restarting ntpd every time the 
dynamic IP address changes.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

In article <6ehkdd.mjj.ln@barnabe.home.fr>, Edrusb <edrusba@free.fr> wrote:

> the outgoing IP packets have their IP source field set by the system in 
> any way I guess, even when sending from a wildcard socket.

But too late to be included in the message authentication code, so the
packets will have an invalid authentication code and will be rejected
by an authenticating client.

> Thanks for the idea, but public servers still have static IP address :-) 
> masquerading them would not help :-/

It is the client address that will be masqueraded.

> I guess, the best solution waiting for next ntpd release, as described 
> by Steve Kostecke, is to have my local ntpd server for my local network 
> be "inside" the network without any dynamic IP address.

Note that I believe that the proposed solution is to either periodically
scan for new interfaces or to scan when a server fails.

At 8:55 PM +0100 2005-08-13, David Woolley wrote:

>>  I guess, the best solution waiting for next ntpd release, as described
>>  by Steve Kostecke, is to have my local ntpd server for my local network
>>  be "inside" the network without any dynamic IP address.
>
>  Note that I believe that the proposed solution is to either periodically
>  scan for new interfaces or to scan when a server fails.

	Personally, I think you probably need to do both.  You need to 
periodically rescan the interfaces, in case a new interface has been 
added but no old ones have gone away, and you need to also detect 
when old ones have disappeared.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Edrusb wrote:
> Dear all,
> 
> The problem I met concerns ntpd when a changes in the network interface
> set occurs.
> 
> My Linux system (on which runs ntpd-2.4.0) has two links to Internet:
> one is permanent (except upon hardware failure), the second is a backup
> modem line.
> 
> Actually the "permanent" link is broken so the dialup modem line is in
> action, and a ppp0 interface goes up and down upon request. If I launch
> ntpd when the link is down, ntpd will never synchronize with peers even 
> when the link comes back short after: it has a wildcard UDP socket 
> opened on port 123 and for each other interfaces that existed when ntpd 
> was launched, it has an UDP interface specific socket on port 123 too 
> (information given by the netstat command). The problem is that when the 
> link goes up then ntpd does not seems using the wildcard socket to try 
> to reach peers and does not create a new UDP interface specific socket 
> for this new interface (ppp0) so peers stay unreachable as reported by 
> ntpdc, even long after the link came back (tried more than 2 hours).
> 
> In the other way, if I launch ntpd when the link is up, it properly
> exchange time information with its peers, but when the link goes down,
> it keeps its UDP interface specific socket opened on ppp0 interface
> while this ppp0 interface is now down. At that time I start having
> 
>     "ntpd[11911]: sendto(x.x.x.x): Invalid argument"
> 
> messages as reported by syslog (with x.x.x.x rotating with all the IP
> address of the configured peers). The worse thing is that when the link
> comes back, ntpd still has his old socket opened, but still are reported
> a lot of "Invalid Socket" messages and of course, ntpd cannot anymore
> synchronize with ntp peers.
> 
> - What is the use of this wildcard UDP socket (it does not seems used)?
> - Why does ntpd uses theses UDP specific interfaces sockets, while the
> configuration file does not specify any interface to listen on or to not
> listen on?
> - How to have ntpd be able to work with a dialup link?
> 

See bug #51. Yes, as Brad says, we will be fixing this, but it's not a 
simple thing to implement so it won't be soon.

Danny

> 
> Any help is (very) welcome. :-)
> 
> 
> Regards,
> Denis.
> 
> -- 
> edrusba@free.fr
> remove the a letter in the email above

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Brad Knowles wrote:
> At 12:18 PM +0200 2005-08-13, Edrusb wrote:
> 
>>  Yes probably, it is too bad the same socket has not been used to send
>>  data too, just leting the system put the appropriate Source IP and
>>  select the adequate output interface according to system's routing
>>  decision. This way there would not have any need to scan available
>>  network interfaces for changes.
> 
> 
>     Nice theory, but it doesn't work that way in practice.  Dig deep 
> into the code of programs like ntpd, BIND, and sendmail if you want to 
> understand why, but be prepared to spend a significant amount of time 
> learning about cross-platform issues, problems with IPv4 versus IPv6, 
> guaranteeing that reply packets always come from the same interface and 
> IP address that the query was sent to, and a whole host of other problems.
> 
>     It's just not that simple.

:-)))

Yes, you are right, it is easy to find things simple when you are far 
away from the problem... Anyway, don't imagine I said or even thought 
ntpd was bad designed or something like that, I really appreciate this 
nice and useful program!

Thank you for your clear answers.

> [...]

Best Regards,
Denis.

-- 
Edrusb
edrusba@free.fr remove the a letter

Edrusb wrote:
> David Woolley wrote:
> 
>> In article <hmvidd.pdc.ln@barnabe.home.fr>, Edrusb <edrusba@free.fr> 
>> wrote:
>>
>>
>>> - What is the use of this wildcard UDP socket (it does not seems used)?
>>
>>
>>
>> Handles incoming requests?
> 

The wildcard addresses are not used for anything except to prevent other
applications grabbing the addresses and ports.

> 
> Yes probably, it is too bad the same socket has not been used to send 
> data too, just leting the system put the appropriate Source IP and 
> select the adequate output interface according to system's routing 
> decision. This way there would not have any need to scan available 
> network interfaces for changes.
> 

No, we need to send out responses with the correct IP address to ensure
that it can be authenticated. You cannot do this with the wildcard port
as you have no control over the address it will used.

>  >>- Why does ntpd uses theses UDP specific interfaces sockets, while the
>  >>configuration file does not specify any interface to listen on or to not
>  >>listen on?
>  >
>  >
>  > I believe this is because the security features require the origin
>  > address to be known by the sender (possibly only for servers).
> 
> the outgoing IP packets have their IP source field set by the system in 
> any way I guess, even when sending from a wildcard socket.
> 

No. If you send from the wildcard port the system will choose which
address to use. We need to control that. If you send a request to
address A and got a response from address B, it will be assumed to be an
invalid response to the request to address A.

Danny
> 
>>
> [...]
> 
>>
>>> Any help is (very) welcome. :-)
>>
>>
>>
>> As noted elsewhere, you can do IP address masquerading down stream so 
>> that
>> ntpd sees a fixed address.
> 
> 
> Thanks for the idea, but public servers still have static IP address :-) 
> masquerading them would not help :-/
> 

No, it's your server that is being protected from changes not the public
servers.

Danny

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Brad Knowles wrote:
> At 8:55 PM +0100 2005-08-13, David Woolley wrote:
> 
>>>  I guess, the best solution waiting for next ntpd release, as described
>>>  by Steve Kostecke, is to have my local ntpd server for my local network
>>>  be "inside" the network without any dynamic IP address.
>>
>>
>>  Note that I believe that the proposed solution is to either periodically
>>  scan for new interfaces or to scan when a server fails.
> 
> 
>     Personally, I think you probably need to do both.  You need to 
> periodically rescan the interfaces, in case a new interface has been 
> added but no old ones have gone away, and you need to also detect when 
> old ones have disappeared.
> 

Detecting when an old interface has "disappeared" should be possible 
looking at the errno global variable when sendto() system call returns 
an error (errno = EINVAL). And I guess, like Bind does, a periodic 
interface scanning plus an "on event" scanning (when sendto() returns an 
error) should be "large" enough to address this problem?

Regards,
Denis.

"Edrusb" <edrusba@free.fr> wrote in message
news:mquqdd.beh.ln@barnabe.home.fr...
> Detecting when an old interface has "disappeared" should be possible
> looking at the errno global variable when sendto() system call returns
> an error (errno = EINVAL). And I guess, like Bind does, a periodic
> interface scanning plus an "on event" scanning (when sendto() returns an
> error) should be "large" enough to address this problem?
>
> Regards,
> Denis.

Checking errno might be one way to detect when an interface has disappeared.
Assuming that you already have code to read up the list of interfaces on a
server, another simple approach is to run that code again and then compare
the current interface list to what NTP was using previously.

Abandoning the right to remain silent, Brad Knowles at Fri, 12 Aug 2005
20:48:43 +0000 said:

> At 10:09 PM +0200 2005-08-12, Edrusb wrote:
> 
>>  The problem I met concerns ntpd when a changes in the network interface
>>  set occurs.
> 
> 	When the network interface changes, you need to restart ntpd. 
> This is a known limitation in the current code and something that 
> we're hoping to get fixed soon, but this is the way it currently is.

You don't have to restart. You can use some scripting and  ntpdc to remove
and readd any servers which have become unreachable. This has been
explained here several times in the past.

-- 
Avoid reality at all costs.
$email =~ s/n(.)a(.)n(.)a(.)e(.+)invalid/$1$2$3$4$5au/;
icbm: 33.43.46S 150.59.27E

At 10:01 PM +0000 2005-08-22, You have no need to know wrote:

>>  	When the network interface changes, you need to restart ntpd.
>>  This is a known limitation in the current code and something that
>>  we're hoping to get fixed soon, but this is the way it currently is.
>
>  You don't have to restart. You can use some scripting and  ntpdc to remove
>  and readd any servers which have become unreachable. This has been
>  explained here several times in the past.

	That doesn't work when the interface IP address changes, because 
the current code doesn't watch for interface changes, drop old 
interfaces from the list, add new ones as they come along, etc....

	With the current code, your solution will only work when the 
interface keeps the same IP address, and your connectivity is only 
interrupted.  If you're behind a NAT/router which gets its IP address 
changed but your local hosts keep theirs, you might still have 
issues.  Certainly, you'll be likely to have to drop and re-add.


	As I said, we're working on fixing this.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions