Subject: pppd connections not responsive...
To: None <netbsd-help@netbsd.org>
From: Brian Stark <bstark@uswest.net>
List: netbsd-help
Date: 11/14/1999 22:03:18
Hello,

Has anyone else had problems with ppp network connections becoming not
responsive? I am running NetBSD 1.4.1/i386 and every now and then
my ppp connection to my ISP becomes totally useless. This happened
just a short time ago, and I captured some information:

callisto:bstark$ netstat -n -f inet
Proto Recv-Q Send-Q  Local Address          Foreign Address        State
tcp        0   2507  209.180.31.90.65533    205.177.168.3.25       ESTABLISHED
udp        0      0  209.180.31.90.520      *.*
udp        0      0  127.0.0.1.520          *.*
callisto:bstark$ netstat -rn -f inet
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use    Mtu
Interface
default            207.225.140.148    UGS         2       48      -  ppp0
127.0.0.1          127.0.0.1          UH          1       24      -  lo0
207.225.140.148    209.180.31.90      UH          1        0      -  ppp0
209.180.31.90      127.0.0.1          UH          0        0      -  lo0

callisto:bstark$ ifconfig ppp0
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        inet 209.180.31.90 --> 207.225.140.148 netmask 0xffffff00

And here is a section from the output from my routed trace file:

-- 21:37:45 --
Add interface ppp0 209.180.31.90  -->207.225.140.148/32 <PT-TO-PT>
<NO_RIP|NO_RDISC>
Add    207.225.140.148/32-->209.180.31.90  metric=0  ppp0 <IF>
Add    209.180.31.90/32-->127.0.0.1        metric=0  ppp0 <IF|LOCAL>
note RTM_IFINFO with flags 0xffff8051 for ppp0
-- 21:37:45 --
RTM_ADD from pid 504: 0.0.0.0 --> 207.225.140.148
-- 21:38:17 --
RTM_LOSING: 205.177.168.3/0 --> 207.225.140.148
-- 21:39:33 --
RTM_LOSING: 205.177.168.3/0 --> 207.225.140.148
-- 21:40:37 --
RTM_LOSING: 205.177.168.3/0 --> 207.225.140.148
-- 21:41:41 --


The above information shows that the Send-Q has data in it, and 
executing "netstat -n -f inet" multiple times shows that the 
number is not going down. 

I have observed this problem quite a bit, and it doesn't seem to
be associated with tcp connections to any specific IP address, or
use of a specific service (such as smtp, telnet, etc...).

Ideas anyone? 

Brian Stark
bstark@uswest.net