"Per Hedeland" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > In article <[EMAIL PROTECTED]> > "Ron C." <[EMAIL PROTECTED]> writes: > >However Covad makes the WAN IP private (non-routable) with the local end > >programmed as 0.0.0.0 and the remote as 127.0.0.2. Apparently Netopia > >uses the WAN IP for NTP and the router knows that it makes no sense to > >try to use NTP with a non-routable IP, so it logs the "cannot send" > >error message. > > I'm not sure I followed all that, but if the router has its WAN > interface "configured" with 0.0.0.0, it's no surprise that it refuses to > originate traffic in that direction. Nothing NTP-specific, nor even > necessarily knowledge about what is "routable", but sending out IP > packets with source address 0.0.0.0 is just Plain Wrong (unless you're > booting and need to speak DHCP/BOOTP before you can get your address). > > But I believe you said that it worked fine to do NTP requests from > inside your network (and I would expect that, as long as the router > doesn't try to NAT them to 0.0.0.0:-). Couldn't you just set up an NTP > server there, and point the router at *that*? This would also have the > advantage that if the router goes berserk and starts spewing requests > continously, only you will suffer.:-) > > --Per Hedeland > [EMAIL PROTECTED]
The problem causing the "cannot SEND" error message seems to be the originating IP rather than the destination IP. The Netopia router uses the WAN IP as the originating source. In order to conserve their IP address space Covad causes this WAN IP to be of the private type (172.19.x.x). [BTW this number is NOT one of the WAN numbers entered into the router during setup which are 0.0.0.0 and 127.0.0.2. It seems to be aquired by the router when the connection with Covad is authenticated.] In any case, Covad tech support said that the router tries to use this "private" IP as a source and that's why it fails. I think the NTP program in the router stops in its tracks when it sees the private IP and produces the "cannot SEND" error message instead of sending the NTP request. It's probably not going berserk, it's just designed to send NTP requests FROM a routable public WAN IP, and stops because it doesn't have one. In my case it's the LAN side that has routable IPs since I'm p aying extra for a block of 16 IP addresses, so that I can have internet servers. (Some of these are part of a DHCP pool programmed in the router for non-servers on my network.) NAT is not used. I believe that if I were using NAT instead, the single routable IP would be on the WAN while the LAN addresses would be private and then the router would be able to send NTP requests to set its own clock. _______________________________________________ questions mailing list questions@lists.ntp.isc.org https://lists.ntp.isc.org/mailman/listinfo/questions
