>> I have a fairly crowded network, and in it there is a Sun 3/60 running
>> NetBSD.  It is my router; it is connected to a modem, and the modem connects
>> to the outside world.

>> I have noticed the following symptoms:

>>  [ ping some host (the other end of the PPP link?) every 10 minutes 10
>>    times, kill pppd if it doesn't work even once. ]

>> 1.  The above script fairly frequently chooses to kill pppd when the link
>> is working perfectly well.

>I have a 486, so there may be port-specific issues I don't have, but:

>On a busy modem, I have seen ping packets lose big time, and wouldn't
>be TOO surprised that not one in ten packets could get returned
>promptly enough for ping (maybe a little surprised).  My own similar
>script runs every two minutes, and insists that the link fail 4
>consecutive checks (with fewer packets).  That keeps short-term
>saturation from causing the link to be taken down.

	I have seen ping packets lost regularly as well, when I'm loading
the link.  My link is maintained by a C program which performs similar
functions to the scripts posted here; however, mine sends one ping every
two minutes, except in a failure where it sends one every ten seconds for
four minutes until it succeeds.  If that still fails, it checks the number
of bytes which have been received (a la SIOCGPPPSTATS ioctl) in the
last minute, and if that is non-zero, assume the link is still active.
By checking the volume, I've worked around that 'loaded-link' problem.
(I check the receive volume, not the transmit, since even if the link is
dead the pings sent show up on the count..)

>> 2.  If I'm doing a fairly large download to either a mac or a windoze PC,
>> which is connected to the 3/60 over ethernet, the network feed (which I'm
>> watching as modem LED's) will abruptly stop transferring data, and hang for
>> several minutes.  However, if I hit return in an rlogin to a machine on the
>> other end of the link, everything recovers for a while, running anywhere
>> from three seconds to a minute, and then hangs again.

>I don't see that.  Sounds like a bug in the serial driver; maybe the receive
>interrupt clears out some broken state in the transmit path allowing it to
>recover?

	I have seen this, but it was I think over a year ago.  I've not
seen anything like this since.  I never knew the cause..

Cheers,
Phil
--
Phillip F Knaack
Systems Administrator, Information Development for Extension Audiences (IDEA)
Iowa State University Extension