Hi *,

during testing of dynamic network interface update code for a future
NTP version I found following behaviour in a maybe somewhat uncommon
network setup:

Interfaces at startup
pppoe0: <DSL IP 1> (default route points to it, pf fw, pf nat)
bge0: 10.0.3.1/28 (local network)
tun0: 10.0.3.1/32-><fixed external ip> (vpn tunnel created via vtund)

Ntpd binds sockets to all interface addresses - this means it will
only bind once to 10.0.3.1.
After startup everything works as expected. Packets leave the
interfaces with the expected interface addresses as source.

Now when the DSL ISP forces the disconnect of pppoe0,
that interface is reconnected and gets a new ip address.
tun0 is, after a while, re-configured via vtund (restarted because
of the dis-connect/re-connect of pppoe0).

The for me the surprising thing is that packets from ntpd to destinations
reachable via tun0 now get the source address of *pppoe0*.
This means that the return path is different and not guaranteed to
to succeed. Ntpd thus loses contact to servers/peers reachable
via tun0.
The sending socket of ntpd is still bound to 10.0.3.1.
route get <destination reachable via tun0> still displays
the correct data including a correct local address of 10.0.3.1.

   What is happening here ?
   Is assigning 10.0.3.1 to more than one interface asking too much?
   Why is the local address assignment being lost but not recovered
   when tun0 comes back after pppoe0 coming back ?
   Is this behaviour normal ?
   What needs to be done to avoid that behaviour?

So many questions - I hope someone is able shed some light on this
so that I can clear up the last topics in the new ntpd dynamic
interface update code.

Frank