Hi,

In one of my setups with just one interface I had configured ntp server.
Everything works fine till here. Now I change the IP address of the
interface
and then sendto() starts failing with "Invalid arguments" error. I
understand that
the change in the ip address is not reflected in NTP since it does not
rebind
upon change in the IP address.

My question is How can I make NTP automatically detect this change and
rebind
upon the change in the IP address of the interface ?

Thanks
Kiran

Kiran Shirol wrote:
> 
> In one of my setups with just one interface I had configured ntp server.
> Everything works fine till here. Now I change the IP address of the
> interface

Interface addresses aren't supposed to change, not just for ntp.  You 
will probably also confuse named.

> 
> My question is How can I make NTP automatically detect this change and
> rebind
> upon the change in the IP address of the interface ?

I believe some work has been done on working round broken ISPs who 
deliberately, or otherwise, misoperate DHCP.  I'm not sure what state it 
is in, but you should certainly be using the very latest release 
version, if not a development version.

You are, of course, welcome to submit a patch to the source code.

David Woolley wrote:
> Kiran Shirol wrote:
>>
>> In one of my setups with just one interface I had configured ntp server.
>> Everything works fine till here. Now I change the IP address of the
>> interface
> 
> Interface addresses aren't supposed to change, not just for ntp.  You 
> will probably also confuse named.
> 
>>
>> My question is How can I make NTP automatically detect this change and
>> rebind
>> upon the change in the IP address of the interface ?

Since 4.2.4 ntpd detects changed interface addresses. Depending on the
OS used this happens sooner or later. The fasted detection is on systems
that have the routing socket interface (*BSD and maybe Solaris). For
Windows and Linux interface scans are done every five minutes by 
default. This default can be changed with the -U <secs between scans>
command line switch for faster detects (60s is the current lower limit).

If some good souls from the Linux and Windows communities would
contribute the code needed the for fast detection on these systems 
reaction time would improve there.

> 
> I believe some work has been done on working round broken ISPs who 
> deliberately, or otherwise, misoperate DHCP.

The dynamic interface update code was introduced in 4.2.4 to make
ntpd work correctly in dynamic/mobile environments.

   I'm not sure what state it
> is in, but you should certainly be using the very latest release 
> version, if not a development version.
4.2.4 (the current stable version) is just fine.

> 
> You are, of course, welcome to submit a patch to the source code.

Frank

Frank,

Instead of using a polling approach, would it not be better we use a 
notification model, where in whenever there
is a change in the IP address a notification be generated from the interface 
managing module. I am not sure if
there is such a facility availble currently, I will check the same a get 
back.

My point is , the probability of change in the IP address is low and hence 
periodic polling may not be the best
approach. Let me know your comments.

Thanks
Kiran

"Frank Kardel" <kardel@ntp.org> wrote in message 
news:4867F324.7080506@ntp.org...
>
> David Woolley wrote:
>> Kiran Shirol wrote:
>>>
>>> In one of my setups with just one interface I had configured ntp server.
>>> Everything works fine till here. Now I change the IP address of the
>>> interface
>>
>> Interface addresses aren't supposed to change, not just for ntp.  You 
>> will probably also confuse named.
>>
>>>
>>> My question is How can I make NTP automatically detect this change and
>>> rebind
>>> upon the change in the IP address of the interface ?
>
> Since 4.2.4 ntpd detects changed interface addresses. Depending on the
> OS used this happens sooner or later. The fasted detection is on systems
> that have the routing socket interface (*BSD and maybe Solaris). For
> Windows and Linux interface scans are done every five minutes by default. 
> This default can be changed with the -U <secs between scans>
> command line switch for faster detects (60s is the current lower limit).
>
> If some good souls from the Linux and Windows communities would
> contribute the code needed the for fast detection on these systems 
> reaction time would improve there.
>
>>
>> I believe some work has been done on working round broken ISPs who 
>> deliberately, or otherwise, misoperate DHCP.
>
> The dynamic interface update code was introduced in 4.2.4 to make
> ntpd work correctly in dynamic/mobile environments.
>
>   I'm not sure what state it
>> is in, but you should certainly be using the very latest release version, 
>> if not a development version.
> 4.2.4 (the current stable version) is just fine.
>
>>
>> You are, of course, welcome to submit a patch to the source code.
>
> Frank 

kiran shirol wrote:
> 
> Instead of using a polling approach, would it not be better we use a 
> notification model, where in whenever there

There is no direct event interface, because, when Berkeley sockets were 
designed, interface addresses were fixed at system startup.  TCP was 
designed for peer operation, which requires stable addresses, and DNS 
was designed for very slow changes.

What you are being told is that, on some operating systems, there is an 
event interface for routing, which is dynamic, which provides enough 
information to infer an interface address change.

Thanks David for the clarification.

Kiran

"David Woolley" <david@ex.djwhome.demon.co.uk.invalid> wrote in message 
news:48687e61$0$78078$5a6aecb4@news.aaisp.net.uk...
> kiran shirol wrote:
>>
>> Instead of using a polling approach, would it not be better we use a 
>> notification model, where in whenever there
>
> There is no direct event interface, because, when Berkeley sockets were 
> designed, interface addresses were fixed at system startup.  TCP was 
> designed for peer operation, which requires stable addresses, and DNS was 
> designed for very slow changes.
>
> What you are being told is that, on some operating systems, there is an 
> event interface for routing, which is dynamic, which provides enough 
> information to infer an interface address change. 

On Jun 30, 4:18 am, "kiran shirol" <kiran.shi...@gmail.com> wrote:
> Instead of using a polling approach, would it not be better we use a
> notification model, where in whenever there
>
in my own ntp client implementation i "re-bind" to the server each
time i want to ask for his time.

i could think of an implementation that mixes both approaches
in case of a certain errno after a sendto() call, we re-bind, else we
remember that socket...

-arne

Kirian,

the core for the dynamic interface code *is* actually event based.
ntpd listens to routing messages on the routing socket. The routing 
socket has been part of BSD and BSD derived stacks for quite some time.
Whenever a routing message that indicates a possible routing change
is received a rescan is started within two seconds. This approach is
even better than just watching interface changes as it detects changing
routes for peer associations on the fly.

Unfortunately the BSD routing socket API is not available in every OS. 
Linux has a similar but different mechanism. Windows has another. For 
these systems ntpd currently uses the periodic scan approach to pick up 
changes.

Thus there are two bugs waiting to be closed:
	1) Windows: https://support.ntp.org/bugs/show_bug.cgi?id=991
	2) Linux: https://support.ntp.org/bugs/show_bug.cgi?id=992

For these and other operating systems not supporting the BSD routing
socket interface a small piece of code is needed to support event driven 
re-scans.

I am still waiting for people to provide the respective patches....

Frank

kiran shirol wrote:
> Frank,
> 
> Instead of using a polling approach, would it not be better we use a 
> notification model, where in whenever there
> is a change in the IP address a notification be generated from the interface 
> managing module. I am not sure if
> there is such a facility availble currently, I will check the same a get 
> back.
> 
> My point is , the probability of change in the IP address is low and hence 
> periodic polling may not be the best
> approach. Let me know your comments.
> 
> Thanks
> Kiran
> 
> "Frank Kardel" <kardel@ntp.org> wrote in message 
> news:4867F324.7080506@ntp.org...
>> David Woolley wrote:
>>> Kiran Shirol wrote:
>>>> In one of my setups with just one interface I had configured ntp server.
>>>> Everything works fine till here. Now I change the IP address of the
>>>> interface
>>> Interface addresses aren't supposed to change, not just for ntp.  You 
>>> will probably also confuse named.
>>>
>>>> My question is How can I make NTP automatically detect this change and
>>>> rebind
>>>> upon the change in the IP address of the interface ?
>> Since 4.2.4 ntpd detects changed interface addresses. Depending on the
>> OS used this happens sooner or later. The fasted detection is on systems
>> that have the routing socket interface (*BSD and maybe Solaris). For
>> Windows and Linux interface scans are done every five minutes by default. 
>> This default can be changed with the -U <secs between scans>
>> command line switch for faster detects (60s is the current lower limit).
>>
>> If some good souls from the Linux and Windows communities would
>> contribute the code needed the for fast detection on these systems 
>> reaction time would improve there.
>>
>>> I believe some work has been done on working round broken ISPs who 
>>> deliberately, or otherwise, misoperate DHCP.
>> The dynamic interface update code was introduced in 4.2.4 to make
>> ntpd work correctly in dynamic/mobile environments.
>>
>>   I'm not sure what state it
>>> is in, but you should certainly be using the very latest release version, 
>>> if not a development version.
>> 4.2.4 (the current stable version) is just fine.
>>
>>> You are, of course, welcome to submit a patch to the source code.
>> Frank 
> 
> 

David Woolley wrote:
> kiran shirol wrote:
>>
>> Instead of using a polling approach, would it not be better we use a 
>> notification model, where in whenever there
> 
> There is no direct event interface, because, when Berkeley sockets were 
> designed, interface addresses were fixed at system startup.  TCP was 
> designed for peer operation, which requires stable addresses, and DNS 
> was designed for very slow changes.

This statement needs to be refined slighly. The BSD stack has had for 
quite some time the routing socket interface. This interface allows to 
read notifications about network topology change events. While TCP 
requires stable addresses other protocols like UDP do not. NTP uses
UDP for communication and can perfectly cope with changes of local 
addresses since 4.2.4.
DNS is usually not troubled as the clients just get new addresses and 
thus just other DNS names, Stability of addesses is only required for 
servers. Having a server as moving target is not really fun.

There is, however, a weak spot in the reference implementation. It
resolves DNS names only once. This is problematic for slowly
(administratively) changing server addresses for long running client
daemons. This needs to be fixed in the future.

> 
> What you are being told is that, on some operating systems, there is an 
> event interface for routing, which is dynamic, which provides enough 
> information to infer an interface address change.

Frank

Frank,

That would be good so that the user need not have to worry about any changes 
in the IP addresses in
future. I read some other mail thread on the forum and the solution 
suggested was to restart NTP. But
that approach needs user/admin intervention and thus not a good thing to do. 
I will keep a watch on the
bug IDs too.

Thanks Frank for the responses.

Kiran

"Frank Kardel" <kardel@ntp.org> wrote in message 
news:48694671.8010207@ntp.org...
> Kirian,
>
> the core for the dynamic interface code *is* actually event based.
> ntpd listens to routing messages on the routing socket. The routing socket 
> has been part of BSD and BSD derived stacks for quite some time.
> Whenever a routing message that indicates a possible routing change
> is received a rescan is started within two seconds. This approach is
> even better than just watching interface changes as it detects changing
> routes for peer associations on the fly.
>
> Unfortunately the BSD routing socket API is not available in every OS. 
> Linux has a similar but different mechanism. Windows has another. For 
> these systems ntpd currently uses the periodic scan approach to pick up 
> changes.
>
> Thus there are two bugs waiting to be closed:
> 1) Windows: https://support.ntp.org/bugs/show_bug.cgi?id=991
> 2) Linux: https://support.ntp.org/bugs/show_bug.cgi?id=992
>
> For these and other operating systems not supporting the BSD routing
> socket interface a small piece of code is needed to support event driven 
> re-scans.
>
> I am still waiting for people to provide the respective patches....
>
> Frank
>
> kiran shirol wrote:
>> Frank,
>>
>> Instead of using a polling approach, would it not be better we use a 
>> notification model, where in whenever there
>> is a change in the IP address a notification be generated from the 
>> interface managing module. I am not sure if
>> there is such a facility availble currently, I will check the same a get 
>> back.
>>
>> My point is , the probability of change in the IP address is low and 
>> hence periodic polling may not be the best
>> approach. Let me know your comments.
>>
>> Thanks
>> Kiran
>>
>> "Frank Kardel" <kardel@ntp.org> wrote in message 
>> news:4867F324.7080506@ntp.org...
>>> David Woolley wrote:
>>>> Kiran Shirol wrote:
>>>>> In one of my setups with just one interface I had configured ntp 
>>>>> server.
>>>>> Everything works fine till here. Now I change the IP address of the
>>>>> interface
>>>> Interface addresses aren't supposed to change, not just for ntp.  You 
>>>> will probably also confuse named.
>>>>
>>>>> My question is How can I make NTP automatically detect this change and
>>>>> rebind
>>>>> upon the change in the IP address of the interface ?
>>> Since 4.2.4 ntpd detects changed interface addresses. Depending on the
>>> OS used this happens sooner or later. The fasted detection is on systems
>>> that have the routing socket interface (*BSD and maybe Solaris). For
>>> Windows and Linux interface scans are done every five minutes by 
>>> default. This default can be changed with the -U <secs between scans>
>>> command line switch for faster detects (60s is the current lower limit).
>>>
>>> If some good souls from the Linux and Windows communities would
>>> contribute the code needed the for fast detection on these systems 
>>> reaction time would improve there.
>>>
>>>> I believe some work has been done on working round broken ISPs who 
>>>> deliberately, or otherwise, misoperate DHCP.
>>> The dynamic interface update code was introduced in 4.2.4 to make
>>> ntpd work correctly in dynamic/mobile environments.
>>>
>>>   I'm not sure what state it
>>>> is in, but you should certainly be using the very latest release 
>>>> version, if not a development version.
>>> 4.2.4 (the current stable version) is just fine.
>>>
>>>> You are, of course, welcome to submit a patch to the source code.
>>> Frank
>> 

On 2008-07-01, kiran shirol <kiran.shirol@gmail.com> wrote:

>"Frank Kardel" <kardel@ntp.org> wrote
>
>> [---=| TOFU protection by t-prot: 82 lines snipped |=---]
>
> That would be good so that the user need not have to worry about any
> changes in the IP addresses in future. I read some other mail thread
> on the forum and the solution suggested was to restart NTP. But that
> approach needs user/admin intervention and thus not a good thing to
> do.

Restarting ntpd in response to system events such as DHCP acquiring a
new address is not that difficult on a useful OS. So that's a rather
weak argument.

Although you might be tempted to make the case restarts are undesireable
because that ntpd loses state information when restarted, it should be
pointed out that systems which are subject to interface changes are
usally leaf-nodes and a definitely not high quality time servers. Plus
the warm restart of a properly configured ntpd (i.e. correct ntp.conf,
valid drift.file) takes a mere ~15-20 seconds.

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

Kiran Shirol wrote:
> Hi,
> 
> In one of my setups with just one interface I had configured ntp server.
> Everything works fine till here. Now I change the IP address of the
> interface
> and then sendto() starts failing with "Invalid arguments" error. I
> understand that
> the change in the ip address is not reflected in NTP since it does not
> rebind
> upon change in the IP address.
> 
> My question is How can I make NTP automatically detect this change and
> rebind
> upon the change in the IP address of the interface ?

This is typical when DHCP provides you with a different IP address from 
the one your were previously using. Fixed in 4.2.4.

Danny

David Woolley wrote:
> Kiran Shirol wrote:
>> In one of my setups with just one interface I had configured ntp server.
>> Everything works fine till here. Now I change the IP address of the
>> interface
> 
> Interface addresses aren't supposed to change, not just for ntp.  You 
> will probably also confuse named.
> 

No, named has handled that for a very long time.

>> My question is How can I make NTP automatically detect this change and
>> rebind
>> upon the change in the IP address of the interface ?
> 
> I believe some work has been done on working round broken ISPs who 
> deliberately, or otherwise, misoperate DHCP.  I'm not sure what state it 
> is in, but you should certainly be using the very latest release 
> version, if not a development version.
> 

Well operated ISP's and companies will change your IP address from time 
to time. Even my office network will change my IP address on my laptop 
even though it will renew my existing address if it's available.

> You are, of course, welcome to submit a patch to the source code.

Since this is already fixed there's nothing to do.

Danny

kiran shirol wrote:
> Frank,
> 
> Instead of using a polling approach, would it not be better we use a 
> notification model, where in whenever there
> is a change in the IP address a notification be generated from the interface 
> managing module. I am not sure if
> there is such a facility availble currently, I will check the same a get 
> back.
> 
> My point is , the probability of change in the IP address is low and hence 
> periodic polling may not be the best
> approach. Let me know your comments.

No, that's not true at least in my case. At work I move from one meeting 
to another with my laptop. They may be on different floors and in 
different parts of the building so I get a different IP address each 
time. It's not infrequent at all.

Danny

arne_woerner@yahoo.com wrote:
> On Jun 30, 4:18 am, "kiran shirol" <kiran.shi...@gmail.com> wrote:
>> Instead of using a polling approach, would it not be better we use a
>> notification model, where in whenever there
>>
> in my own ntp client implementation i "re-bind" to the server each
> time i want to ask for his time.
> 
> i could think of an implementation that mixes both approaches
> in case of a certain errno after a sendto() call, we re-bind, else we
> remember that socket...

Yes, we should consider whether or not we should rescan the interfaces 
when we get these kinds of errors so that ntpd can recover from a change 
in IP address. That's certainly a good idea. We'd need to have a check 
so that we don't rescan too frequently otherwise we'd be spending all of 
our time rescanning.

Danny

Danny Mayer wrote:

>> Interface addresses aren't supposed to change, not just for ntp.  You 
>> will probably also confuse named.
>>
> 
> No, named has handled that for a very long time.

The named I have had had for less than a very long time won't even 
detect an interface going from down to up with the same address until 
the next time it scans for new interfaces.  I sometimes have to do rndc 
reload to get connectivity back.

> 
> Well operated ISP's and companies will change your IP address from time 
> to time. Even my office network will change my IP address on my laptop 
> even though it will renew my existing address if it's available.

They should not, because a client that is up should renew the lease long 
before it expires.  Even if the machine is offline, leases should be set 
  long enough to cover most normal offline time.

kiran shirol wrote:
> Frank,
> 
> That would be good so that the user need not have to worry about any changes 
> in the IP addresses in
> future.

This statement seems to be implying that ntpd does not detect interface 
changes. This is *NOT* the case for 4.2.4 and after. ntpd 4.2.4 
*detects* changes in interface addresses and routing. I may take a while 
for some
platforms (Windows/Linux - BSD is almost instant as it is event driven). 
The default rescans every 5 minutes. This can be lowered to 1 minute
with the -U 60 switch. -U 0 disables scanning. The lower limit of 60
seconds will be dropped in the future. The default where choosen for
a reasonable balance between computational load and responsiveness.
Thus don't expect an instant response when you are on a platform where
we have yet to implement the event mechanism. Just wait a bit.

It is documented in the html pages an in the short help of the daemon.

  I read some other mail thread on the forum and the solution
> suggested was to restart NTP. But
> that approach needs user/admin intervention and thus not a good thing to do.
> I will keep a watch on the
> bug IDs too.
> 
> Thanks Frank for the responses.
> 
> Kiran
> 
[snip]

Frank

Ideally nobody should have to restart ntpd for whatever reason.
Interface address changes are already handled automatically.
The last weak spot wrt/ to refreshing addresses is name resolution.

Frank

Steve Kostecke wrote:
> On 2008-07-01, kiran shirol <kiran.shirol@gmail.com> wrote:
> 
>> "Frank Kardel" <kardel@ntp.org> wrote
>>
>>> [---=| TOFU protection by t-prot: 82 lines snipped |=---]
>> That would be good so that the user need not have to worry about any
>> changes in the IP addresses in future. I read some other mail thread
>> on the forum and the solution suggested was to restart NTP. But that
>> approach needs user/admin intervention and thus not a good thing to
>> do.
> 
> Restarting ntpd in response to system events such as DHCP acquiring a
> new address is not that difficult on a useful OS. So that's a rather
> weak argument.
> 
> Although you might be tempted to make the case restarts are undesireable
> because that ntpd loses state information when restarted, it should be
> pointed out that systems which are subject to interface changes are
> usally leaf-nodes and a definitely not high quality time servers. Plus
> the warm restart of a properly configured ntpd (i.e. correct ntp.conf,
> valid drift.file) takes a mere ~15-20 seconds.
> 

Danny Mayer wrote:
> arne_woerner@yahoo.com wrote:
>> On Jun 30, 4:18 am, "kiran shirol" <kiran.shi...@gmail.com> wrote:
>>> Instead of using a polling approach, would it not be better we use a
>>> notification model, where in whenever there
>>>
>> in my own ntp client implementation i "re-bind" to the server each
>> time i want to ask for his time.
>>
>> i could think of an implementation that mixes both approaches
>> in case of a certain errno after a sendto() call, we re-bind, else we
>> remember that socket...
> 
> Yes, we should consider whether or not we should rescan the interfaces 
> when we get these kinds of errors so that ntpd can recover from a change 
> in IP address. That's certainly a good idea. We'd need to have a check 
> so that we don't rescan too frequently otherwise we'd be spending all of 
> our time rescanning.

Well as we already detect changes of interface addresses reliably (but 
not instantaneous on some platforms) there is no need to add more and 
more measurement points to the code just to be worried about rate 
limiting the scan process. We should rather focus to get the last major
platforms event enabled for interface changes. It is not all that hard.

> 
> Danny

Frank

On 2008-07-04, Frank Kardel <kardel@ntp.org> wrote:

> Ideally nobody should have to restart ntpd for whatever reason.
> Interface address changes are already handled automatically.
> The last weak spot wrt/ to refreshing addresses is name resolution.
>
> Frank
>
> Steve Kostecke wrote:
> [---=| TOFU protection by t-prot: 22 lines snipped |=---]

I have no idea what you were replying to.

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

David Woolley wrote:
> Danny Mayer wrote:
> 
>>> Interface addresses aren't supposed to change, not just for ntp.  You 
>>> will probably also confuse named.
>>>
>> No, named has handled that for a very long time.
> 
> The named I have had had for less than a very long time won't even 
> detect an interface going from down to up with the same address until 
> the next time it scans for new interfaces.  I sometimes have to do rndc 
> reload to get connectivity back.

Then there must be something very wrong with your configuration. I was 
testing this at one time during the development of the code and I assure 
you that it does work and has always worked in BIND9.

>> Well operated ISP's and companies will change your IP address from time 
>> to time. Even my office network will change my IP address on my laptop 
>> even though it will renew my existing address if it's available.
> 
> They should not, because a client that is up should renew the lease long 
> before it expires.  Even if the machine is offline, leases should be set 
>   long enough to cover most normal offline time.

I move around in the office and our network is divided into different IP 
address zones. I get a new address when I move to a different zone. When 
I get back to my own office there is know way that my laptop will 
remember what it was previously using. Don't expect the DHCP server to 
do so.

Danny