On Tue, Apr 03, 2007 at 04:34:26PM -0700, [EMAIL PROTECTED] wrote: > thanks for the replies -- I actually got a real time caller who helped > me check various items until we narrowed the problem down further. Got > the connection back manually. > > 1. 3.5 vs 4.0 > ------------------------------------------------------------------ > I've just ordered the 4.0 CD's and as soon as they arrive I'll build a > machine with 4.0 on it and hope everything gets back to normal. But in > the meantime I still want to identify and fix the current problem. > > > > 2. 192.168.1.1 > ---------------------------------------------------------------- > this is the address of the Covad modem's DHCP server -- not of the > external NIC (ne3) > > > > 3. the problem seems to be that the Covad DHCP server is not providing a > gateway IP address. Or possibly the dhclient is not accepting one. At > least, by using the netstat -rn command we found no default route. This > means that nothing gets out the door. > > > > 4. Manually adding the default route makes the firewall work again: > > add net default: gateway 66.166.238.1 > > > so the question is why is no gateway getting passed from the DHCP server > to the external NIC? I am examining the dhclient.conf file to see what I > can do with that. I have no /etc/mygate file in place which seems to be > consistent with the documentation for mygate:
tcpdump your dhcp conversation; worst case you can -Xs1500 and look to see what the gateway coming down the pipe is; i don't remember offhand if any number of '-v' action makes tcpdump(8) deciper dhcp conversations. actually, yeah, it looks like it does do a protocol decode at least with '-vv' i'm of the opinion that if they weren't handing out a gateway address in a network topology where the subscribers required one (eg, not ppp), their world would be on fire. check for 'G:blahblah' in the tcpdump of the reply you get back to your dhcp request/discover. back to the mygate stuff, it's logical to have no /etc/mygate if you get your default route via dhcp. the 30 second lease time has me a bit weirded out. initially it's real easy to think that the DST thing is at fault there, but lease times are handed out in integers of seconds (LT:BLAHBLAH), so even if your clock and their clock are worlds apart, shouldn't trip each other out. if you still have an old dhclient.leases file, or if your dhclient.leases file has old lease stanzas, was it always 30s? if the 30s is new, what if you do dhclient, get your lease, kill dhclient and then at 15s do a renew? like: $ sudo /sbin/dhclient ne3 && sudo pkill dhclient && sleep 15 && sudo /sbin/dhclient ne3 do you get a longer duration the second time around? makes me wonder if they're trying to do some sort of "detect clients that waste our IP space by pulling IPs needlessly" policy that perhaps their tech support doesn't know about yet. -- jared
