Hiten Pandya wrote:
>
> >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
> installe
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 y
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 pi
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 del
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 s
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 clue
6 matches
Mail list logo