> > While time is important, it's not so important as to stop a network > connection. > Having said that, what might prevent it from being called is lack of > network. > No reasong to use the Network Time Protocol without a net. > > Maybe I'm mis-interpreting your statement, but this explanation seems completely at odds with the NTDP actions and log entries:
pr 14 09:38:36 caddis ntpd[1671]: Listen normally on 5 wlan0 10.5.70.151 UDP 123 Apr 14 09:38:36 caddis ntpd[1671]: Listen normally on 6 wlan0 fe80::223:14ff:fe68:98e0 UDP 123 Apr 14 09:38:36 caddis ntpd[1671]: Deleting interface #3 eth0, 192.168.55.2#123, interface stats: received=0, sent=0, dropped=0, active_time=2101 secs Apr 14 09:38:36 caddis ntpd[1671]: peers refreshed Wlan0 is up and has an ip address. Based on the behavior we witnessed on the Dell, NTPD should be invoked and start listening start on wlan0 for NTP packets so that clock sync can be re-established via the wlan0 interface. Which is exactly what we see on the Dell. Mind you, I was quite surprised that NTPD was responsible for deleting eth0 and hence also the default route associated with it from the route table. Although, NTPD has permission to do this via WICD, I would've thought the network manager would perform this action. The really troubling part here is that these two boxes are running identical OS versions with default configurations. The only explanation I can come up with is a permissions problem But again, identical OS versions w. default configs. _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
