From ycs@netvision.net.il  Thu Aug 27 06:26:11 1998
Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA11205
          for <FreeBSD-gnats-submit@freebsd.org>; Thu, 27 Aug 1998 06:26:07 -0700 (PDT)
          (envelope-from ycs@netvision.net.il)
Received: from netvision.net.il (RAS3-p21.hfa.netvision.net.il [62.0.146.21])
	by alpha.netvision.net.il (8.8.6/8.8.6) with ESMTP id QAA06967
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 27 Aug 1998 16:21:07 +0300 (IDT)
Message-Id: <35E55E53.42979C0E@netvision.net.il>
Date: Thu, 27 Aug 1998 16:25:39 +0300
From: Yoav Cohen-Sivan <ycs@netvision.net.il>
Sender: ycs@alpha.netvision.net.il
To: FreeBSD-gnats-submit@freebsd.org
Subject: 2.2.7 user PPP lockups

>Number:         7755
>Category:       bin
>Synopsis:       2.2.7 user PPP lockups
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    brian
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Aug 27 06:30:01 PDT 1998
>Closed-Date:    Tue Dec 15 16:02:29 PST 1998
>Last-Modified:  Tue Dec 15 16:04:00 PST 1998
>Originator:     Yoav Cohen-Sivan
>Release:        FreeBSD 2.2.7-RELEASE i386
>Organization:
>Environment:
 Pentium/133, 48MB RAM, USRobotics Sportster 33.6 internal PnP modem

>Description:
 Using user PPP. After a random amount of time (5-20 minutes) the
session will
 lock up. Packets are sent, but never received. ping shows lines like
the following (after being stopped with ctrl-c):
	200 packets sent, 0 received, 100% loss

 No networking program works. Netscape freezes up.

 show modem in user PPP shows the "sent" bytes growing but the
"received"
 stay the same.

 Typing "close" to the user PPP program hangs-up. Typing "dial" redials
and everything again works, for another 5-20 minutes.

 I contacted freebsd-stable about this: many people responded claiming
 they had the same problem. For some it mysteriously went away, others
 are still experiencing it. The consensus is that it is relatively new.

 I have tried this with both the GENERIC kernel, and various kernel
compiles
 I did, all with different options.

 Have tried both PnP kernels, and non-PnP, after seeing a pattern on the
 mailing list: many of the responders claimed they were using USR PnP
modems.

 I haven't yet been able to reproduce it with the kernel pppd.

 A bug with the tun0 driver?

>How-To-Repeat:


>Fix:
        


--PAA00565.904222277/myname.my.domain--


&
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->brian 
Responsible-Changed-By: brian 
Responsible-Changed-When: Thu Aug 27 15:18:59 PDT 1998 
Responsible-Changed-Why:  
Ppp's mine 

From: Brian Somers <brian@Awfulhak.org>
To: Yoav Cohen-Sivan <ycs@netvision.net.il>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/7755: 2.2.7 user PPP lockups 
Date: Thu, 27 Aug 1998 23:17:19 +0100

 > 
 > >Number:         7755
 > >Category:       bin
 > >Synopsis:       2.2.7 user PPP lockups
 [.....]
 >  Typing "close" to the user PPP program hangs-up. Typing "dial" redials
 > and everything again works, for another 5-20 minutes.
 [.....]
 
 So the remote peer is not responding.
 
 >  A bug with the tun0 driver?
 [.....]
 
 This is very unlikely if ppp is sending stuff received from the tun 
 device and isn't receiving anything else from the serial link.
 
 You'll need to analyse things further (as things work fine for most 
 installations).  I was in fact reading the freebsd-stable stuff, but 
 I'm unable to post there at the moment.... I *did* try - sorry.
 
 First, you mentioned that adding ``pseudo-device bpfilter N'' made 
 the problem go away.  Is this still the case ?  I suspect this was a 
 red-herring.....
 
 Assuming it was, you should try the following:
 
 1.  Enable ``async'' logging.  Is there *any* data coming back from 
     the peer ?
 2.  Disable all compression:
       deny deflate pred1 protocomp acfcomp vj
       disable deflate pred1 protocomp acfcomp vj
 3.  Enable LQR/ECHO LQR:
       enable lqr
     Is there any reply from the peer at this level ?
 4.  Try the latest ppp via http://www.Awfulhak.org/ppp.html.  Read 
     the README.changes file just in case.
 5.  With the latest ppp, try doing things like ``open lcp'' and 
     ``open ipcp'' when the link dies.  Does this revive things ?
 
 Cheers.
 -- 
 Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org>
       <http://www.Awfulhak.org>
 Don't _EVER_ lose your sense of humour....
 
 

From: Matthew <matt@ultimatetv.com>
To: freebsd-gnats-submit@freebsd.org, ycs@netvision.net.il
Cc:  Subject: Re: bin/7755: 2.2.7 user PPP lockups
Date: Sat, 29 Aug 1998 02:04:30 -0400

 I have a similar setup with the exact same problem (and the exact
 same modem)..  I have a system, (P100/72MB US Robotics 33.6
 sportster internal PNP Fax Modem) and it too hangs after a random
 time.  I have a dedicated dialup connection so my system is
 connected 24/7 and over night it seems to be fine.  It just seems
 to hang up when in use.
 
 I added the Log Async line and all I see Async: WriteModem blocks.
 I also added the "enable lqr" line and it seems to have reboted
 by it self now. 
 
 I will be glad to supply my ppp.conf and ppp.linkup files if needed.
 
 However, with my WinNT box as a router with this modem on the
 same port (different IRQ) it never locked up.
 Matt Soffen
 ==============================================
 Boss    - "My boss says we need some eunuch programmers."
 Dilbert - "I think he means UNIX and I already know UNIX."
 Boss    - "Well, if the company nurse comes by, tell her I said 
              never mind."
                                        - Dilbert -
 ==============================================
State-Changed-From-To: open->closed 
State-Changed-By: brian 
State-Changed-When: Tue Dec 15 16:02:29 PST 1998 
State-Changed-Why:  
Ppp is now version 2.0, which wasn't displaying the same failings. 
The last mail exchange reads: 
Brian, 
I'll be contacting them to ask this. It'll take some time, though, since 
I have some other matters to deal with, and my ISP isn't Mr. 
Fast-Response. 

Yoav 




Brian Somers wrote: 
>  
> >From what I can see, the IPCP traffic has caused the peer to reset 
> its port - turning on ECHO (the stuff read is the same as the stuff 
> written). 
>  
> Your ISPs ppp is dying unexpectedly.  Looks like your ISP needs to be 
> involved at this point - they need to tell us what we've done to make 
> their server go belly-up. 
>Unformatted:
