I'm going to answer these questions to provide another datapoint (even though they are not addressed to me) because I have seen exactly the same behavior with my cable modem:
> Mike D wrote: > > going out. I haven't checked for either packet drops / RTT increase > > (how?) but when I say slow, I mean for eaxmple to get www.google.com > > up takes 5-10 minutes. Also other machines on the LAN can not really > > get out at all. > > > > If you ping/traceroute, do you see losses (and where)? If you look at > "netstat -s" output, do you see retransmissions? In my case, "ping -i 1" dropped very close to 50% of the packets. "ping -i 2": they all got through. "ping -i 0.5" dropped about 75% of the packets. It was almost as if something somewhere was allowing only strictly less than one packet per second. Traceroute lost on the last hop (if I remember correctly) before my box. > > Somebody mentioned on this list that deleting the arp table entry of > > the default router of the cable modem provider (as a cron job) > > solved the problem. > > Does this work for you, too? Yup. > > Could this have something to do with leases being renewed (by the > > isp dhcp server and consequently the cable modem) and FreeBSD not > > updating routing tables? (I'm guessing big time here - not an expert > > by any means) > > > If your cable modem provides IP, it's probably not involved in the > DHCP negotiations. Does your IP address change before you start to see > this slowdown? No new address. I wondered if there is not some parameter that windows supplies in the DHCP request that dhclient does not? This started happening to me when my cable company (with @home) took over the cable modem isp business from my old ISP. andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
