Lars Eggert wrote:
S. Aeschbacher wrote:
This is possible, but I did not verify it (what kind of mucking
could cause such kind of behaviour?). most of them are better
residental pipes.
Having a packet filter drop your traffic after you haven't done ARP/DHCP
in a while. But I agree
S. Aeschbacher wrote:
Hal Snyder wrote:
[snip]
Sounds as if the MAC of the upstream provider occasionally changes.
Don't know enough about cable to understand it better, and problem is
gone now so can't check for sure.
As far as my cases are concerned, the MAC address does not change.
Hi
[snip]
Actually, it sounds like your provider actively mucks with the link
after a certain time - are these residential pipes? If so, they may do
This is possible, but I did not verify it (what kind of mucking could
cause such kind of behaviour?).
most of them are better residental pipes.
what kind of mucking could cause such kind of
behaviour?.
this kind of problem did occur to me several times
with NTL (http://ntl.com/) in UK...
there were installing a Universal Shared Bandwith
Router in their CO (Central Office), after they
installed this piece of sh*t, the bandwith was
S. Aeschbacher wrote:
This is possible, but I did not verify it (what kind of mucking
could cause such kind of behaviour?). most of them are better
residental pipes.
Having a packet filter drop your traffic after you haven't done ARP/DHCP
in a while. But I agree that's pretty far-fetched.
Andrew Heybey [EMAIL PROTECTED] writes:
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.
I had not tried arp deletion but noticed severe slowdown or apparent
disconnect (except able to
Hal Snyder wrote:
[snip]
Sounds as if the MAC of the upstream provider occasionally changes.
Don't know enough about cable to understand it better, and problem is
gone now so can't check for sure.
As far as my cases are concerned, the MAC address does not change. When
the arp entry is
Hi
crontab -e as root and then, insert the following line:
*/10 * * * * /usr/sbin/arp -d IP.OF.DEF.GW
or the brutal version which deletes the entire arp-cache
*/10 * * * * /usr/sbin/arp -da
Stefan
Mike D wrote:
Stefan,
could you (if it's not too much hassle) mail me the details of
On Fri, Dec 07, 2001 at 12:09:05AM +, Mike D wrote:
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)
I doubt it,
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
I have a set up where my FreeBSD 4.4 box is acting as a firewall and gateway
between a cable modem on xl1 and my home net on xl0.
I have a pretty tight rules list and don't have that many procs running
(ipfw, natd, mysql, tomcat - that's it!)
It seems that after approx 10 hours the connection
Hi
I experienced similar problems here in Switzerland. It happend with
FreeBSD as well
as with OpenBSD routers. A solution I found is deleting the arp table
entry of the
default router of the cable modem provider (as a cron job).
I did not investigate the source of the problem. Anyone got any
S. Aeschbacher writes:
Hi
I experienced similar problems here in Switzerland. It happend with
FreeBSD as well
as with OpenBSD routers. A solution I found is deleting the arp table
entry of the
default router of the cable modem provider (as a cron job).
I did not investigate the source of
Stefan,
could you (if it's not too much hassle) mail me the details of setting that
cron job up - as an interim solution. Hopefully we'll get a better one of
this list soon!
Thanks in advance,
Mike
On Thursday 06 December 2001 1:57 pm, S. Aeschbacher wrote:
Hi
I experienced similar
S. Aeschbacher wrote:
A solution I found is deleting the arp table entry of the default
router of the cable modem provider (as a cron job). I did not
investigate the source of the problem. Anyone got any clues?
This sounds a lot like your cable modem provider throtteling the link if
it
This sounds a lot like your cable modem provider throtteling the link if
it doesn't see some sort of negotiation (DHCP, ARP, etc.) after a fixed
amount of time. I could imagine that some companies do this for
residential connections.
Does your cable modem provide IP service, or do you need
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
17 matches
Mail list logo
