From nobody@FreeBSD.org  Tue Dec  7 21:06:56 2004
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 5174B16A4CE
	for <freebsd-gnats-submit@FreeBSD.org>; Tue,  7 Dec 2004 21:06:56 +0000 (GMT)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 09D7343D2D
	for <freebsd-gnats-submit@FreeBSD.org>; Tue,  7 Dec 2004 21:06:56 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id iB7L6tIB039843
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 7 Dec 2004 21:06:55 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id iB7L6tZr039841;
	Tue, 7 Dec 2004 21:06:55 GMT
	(envelope-from nobody)
Message-Id: <200412072106.iB7L6tZr039841@www.freebsd.org>
Date: Tue, 7 Dec 2004 21:06:55 GMT
From: Mike Tancsa <mike@sentex.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: PPPoE with LQR is broken for users connecting to a Juniper ERX
X-Send-Pr-Version: www-2.3

>Number:         74821
>Category:       bin
>Synopsis:       PPPoE with LQR is broken for users connecting to a Juniper ERX
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    brian
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Dec 07 21:10:23 GMT 2004
>Closed-Date:    Thu Feb 03 10:54:15 GMT 2005
>Last-Modified:  Thu Feb 03 10:54:15 GMT 2005
>Originator:     Mike Tancsa
>Release:        RELENG_5
>Organization:
Sentex Communications
>Environment:
FreeBSD releng5-865.sentex.ca 5.3-STABLE FreeBSD 5.3-STABLE #0: Tue Dec  7 11:29:41 EST 2004 
>Description:
When enabling LQR on FreeBSD with PPPoE, and when the otherside is a Juniper ERX, LQM_LQR does not seem to work properly... However, LQM_ECHO does seem to work. 

Here is a sample broken session

Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: Phase: deflink: his = PAP, mine = none
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: Phase: Pap Output: testusername@sentex.ca ********
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: Phase: Pap Input: SUCCESS ()
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: Using trigger address 0.0.0.0
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: CCP: FSM: Using "deflink" as a transport
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: CCP: deflink: State change Initial --> Closed
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: CCP: deflink: LayerStart.
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: CCP: MPPE: Not usable without CHAP81
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: CCP: deflink: SendConfigReq(1) state = Closed
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: CCP:  DEFLATE[4] win 15
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: CCP:  PRED1[2] 
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: CCP: deflink: State change Closed --> Req-Sent
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: Phase: deflink: lcp -> open
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: Phase: bundle: Network
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: FSM: Using "deflink" as a transport
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: deflink: State change Initial --> Closed
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: deflink: LayerStart.
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: deflink: SendConfigReq(9) state = Closed
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  IPADDR[6] 0.0.0.0
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  PRIDNS[6] 205.211.164.51
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  SECDNS[6] 64.7.128.99
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: deflink: State change Closed --> Req-Sent
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: deflink: RecvConfigReq(1) state = Req-Sent
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  IPADDR[6] 67.43.128.6
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: deflink: SendConfigAck(1) state = Req-Sent
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  IPADDR[6] 67.43.128.6
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: deflink: State change Req-Sent --> Ack-Sent
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: LCP: deflink: RecvProtocolRej(3) state = Opened
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: LCP: deflink: -- Protocol 0x80fd (Compression Control Protocol) was rejected!
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: CCP: deflink: State change Req-Sent --> Stopped
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: deflink: RecvConfigNak(9) state = Ack-Sent
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  IPADDR[6] 67.43.133.120
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  IPADDR[6] changing address: 0.0.0.0  --> 67.43.133.120
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: deflink: SendConfigReq(10) state = Ack-Sent
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  IPADDR[6] 67.43.133.120
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  PRIDNS[6] 205.211.164.51
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  SECDNS[6] 64.7.128.99
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: deflink: RecvConfigAck(10) state = Ack-Sent
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  IPADDR[6] 67.43.133.120
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  PRIDNS[6] 205.211.164.51
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP:  SECDNS[6] 64.7.128.99
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: deflink: State change Ack-Sent --> Opened
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: deflink: LayerUp.
Dec  7 15:58:39 releng5-865 ppp[4420]: tun0: IPCP: myaddr 67.43.133.120 hisaddr = 67.43.128.6
Dec  7 15:58:40 releng5-865 ppp[4420]: tun0: LCP: deflink: RecvEchoRequest(1) state = Opened
Dec  7 15:58:40 releng5-865 ppp[4420]: tun0: LCP: deflink: SendEchoReply(1) state = Opened
Dec  7 15:58:49 releng5-865 ppp[4420]: tun0: LQM: deflink: Output:
Dec  7 15:58:49 releng5-865 ppp[4420]: tun0: LQM:   Magic:          24f33001   LastOutLQRs:    00000000
Dec  7 15:58:49 releng5-865 ppp[4420]: tun0: LQM:   LastOutPackets: 00000000   LastOutOctets:  00000000
Dec  7 15:58:49 releng5-865 ppp[4420]: tun0: LQM:   PeerInLQRs:     00000000   PeerInPackets:  00000000
Dec  7 15:58:49 releng5-865 ppp[4420]: tun0: LQM:   PeerInDiscards: 00000000   PeerInErrors:   00000000
Dec  7 15:58:49 releng5-865 ppp[4420]: tun0: LQM:   PeerInOctets:   00000000   PeerOutLQRs:    00000002
Dec  7 15:58:49 releng5-865 ppp[4420]: tun0: LQM:   PeerOutPackets: 0000001a   PeerOutOctets:  000002ce
Dec  7 15:58:50 releng5-865 ppp[4420]: tun0: LCP: deflink: RecvEchoRequest(2) state = Opened
Dec  7 15:58:50 releng5-865 ppp[4420]: tun0: LCP: deflink: SendEchoReply(2) state = Opened
Dec  7 15:58:59 releng5-865 ppp[4420]: tun0: LQM: deflink: Output:
Dec  7 15:58:59 releng5-865 ppp[4420]: tun0: LQM:   Magic:          24f33001   LastOutLQRs:    00000000
Dec  7 15:58:59 releng5-865 ppp[4420]: tun0: LQM:   LastOutPackets: 00000000   LastOutOctets:  00000000
Dec  7 15:58:59 releng5-865 ppp[4420]: tun0: LQM:   PeerInLQRs:     00000000   PeerInPackets:  00000000
Dec  7 15:58:59 releng5-865 ppp[4420]: tun0: LQM:   PeerInDiscards: 00000000   PeerInErrors:   00000000
Dec  7 15:58:59 releng5-865 ppp[4420]: tun0: LQM:   PeerInOctets:   00000000   PeerOutLQRs:    00000003
Dec  7 15:58:59 releng5-865 ppp[4420]: tun0: LQM:   PeerOutPackets: 0000001c   PeerOutOctets:  00000310
Dec  7 15:59:00 releng5-865 ppp[4420]: tun0: LCP: deflink: RecvEchoRequest(3) state = Opened
Dec  7 15:59:00 releng5-865 ppp[4420]: tun0: LCP: deflink: SendEchoReply(3) state = Opened
Dec  7 15:59:09 releng5-865 ppp[4420]: tun0: LQM: deflink: Output:
Dec  7 15:59:09 releng5-865 ppp[4420]: tun0: LQM:   Magic:          24f33001   LastOutLQRs:    00000000
Dec  7 15:59:09 releng5-865 ppp[4420]: tun0: LQM:   LastOutPackets: 00000000   LastOutOctets:  00000000
Dec  7 15:59:09 releng5-865 ppp[4420]: tun0: LQM:   PeerInLQRs:     00000000   PeerInPackets:  00000000
Dec  7 15:59:09 releng5-865 ppp[4420]: tun0: LQM:   PeerInDiscards: 00000000   PeerInErrors:   00000000
Dec  7 15:59:09 releng5-865 ppp[4420]: tun0: LQM:   PeerInOctets:   00000000   PeerOutLQRs:    00000004
Dec  7 15:59:09 releng5-865 ppp[4420]: tun0: LQM:   PeerOutPackets: 0000001e   PeerOutOctets:  00000352
Dec  7 15:59:10 releng5-865 ppp[4420]: tun0: LCP: deflink: RecvEchoRequest(4) state = Opened
Dec  7 15:59:10 releng5-865 ppp[4420]: tun0: LCP: deflink: SendEchoReply(4) state = Opened
Dec  7 15:59:19 releng5-865 ppp[4420]: tun0: LQM: deflink: Output:
Dec  7 15:59:19 releng5-865 ppp[4420]: tun0: LQM:   Magic:          24f33001   LastOutLQRs:    00000000
Dec  7 15:59:19 releng5-865 ppp[4420]: tun0: LQM:   LastOutPackets: 00000000   LastOutOctets:  00000000
Dec  7 15:59:19 releng5-865 ppp[4420]: tun0: LQM:   PeerInLQRs:     00000000   PeerInPackets:  00000000
Dec  7 15:59:19 releng5-865 ppp[4420]: tun0: LQM:   PeerInDiscards: 00000000   PeerInErrors:   00000000
Dec  7 15:59:19 releng5-865 ppp[4420]: tun0: LQM:   PeerInOctets:   00000000   PeerOutLQRs:    00000005
Dec  7 15:59:19 releng5-865 ppp[4420]: tun0: LQM:   PeerOutPackets: 00000020   PeerOutOctets:  00000394
Dec  7 15:59:21 releng5-865 ppp[4420]: tun0: LCP: deflink: RecvEchoRequest(5) state = Opened
Dec  7 15:59:21 releng5-865 ppp[4420]: tun0: LCP: deflink: SendEchoReply(5) state = Opened
Dec  7 15:59:30 releng5-865 ppp[4420]: tun0: LQM: deflink: Output:
Dec  7 15:59:30 releng5-865 ppp[4420]: tun0: LQM:   Magic:          24f33001   LastOutLQRs:    00000000
Dec  7 15:59:30 releng5-865 ppp[4420]: tun0: LQM:   LastOutPackets: 00000000   LastOutOctets:  00000000
Dec  7 15:59:30 releng5-865 ppp[4420]: tun0: LQM:   PeerInLQRs:     00000000   PeerInPackets:  00000000
Dec  7 15:59:30 releng5-865 ppp[4420]: tun0: LQM:   PeerInDiscards: 00000000   PeerInErrors:   00000000
Dec  7 15:59:30 releng5-865 ppp[4420]: tun0: LQM:   PeerInOctets:   00000000   PeerOutLQRs:    00000006
Dec  7 15:59:30 releng5-865 ppp[4420]: tun0: LQM:   PeerOutPackets: 00000022   PeerOutOctets:  000003d6
Dec  7 15:59:31 releng5-865 ppp[4420]: tun0: LCP: deflink: RecvEchoRequest(6) state = Opened
Dec  7 15:59:31 releng5-865 ppp[4420]: tun0: LCP: deflink: SendEchoReply(6) state = Opened
Dec  7 15:59:40 releng5-865 ppp[4420]: tun0: Phase: deflink: ** Too many LQR packets lost **
Dec  7 15:59:40 releng5-865 ppp[4420]: tun0: LQM: deflink: Too many LQR packets lost
Dec  7 15:59:40 releng5-865 ppp[4420]: tun0: CCP: deflink: State change Stopped --> Closed
Dec  7 15:59:40 releng5-865 ppp[4420]: tun0: CCP: deflink: State change Closed --> Initial
Dec  7 15:59:40 releng5-865 ppp[4420]: tun0: LCP: deflink: LayerDown
Dec  7 15:59:40 releng5-865 ppp[4420]: tun0: LCP: deflink: State change Opened --> Starting
Dec  7 15:59:40 releng5-865 ppp[4420]: tun0: Phase: deflink: open -> lcp


Then, forcing LQM_ECHO, it works


>How-To-Repeat:
In Canada, the incumbant telco (Bell Canada) has mostly ERXes deployed.  Enable LQR on the link and you will see it fail.

>Fix:
I came up with this simple hack that lets the user LQM_ECHO in the ppp.conf

releng5-865# diff -u command.c.prev command.c
--- command.c.prev      Tue Dec  7 15:43:28 2004
+++ command.c   Tue Dec  7 15:43:36 2004
@@ -166,6 +166,7 @@
 #define NEG_VJCOMP     53
 #define NEG_MPPE       54
 #define NEG_CHAP81     55
+#define NEG_LCPECHO            56
 
 const char Version[] = "3.2";
 
@@ -2856,6 +2857,10 @@
       cx->physical->link.lcp.cfg.lqr &= keep;
       cx->physical->link.lcp.cfg.lqr |= add;
       break;
+    case NEG_LCPECHO:
+      cx->physical->link.lcp.cfg.forcelcpecho &= keep;
+      cx->physical->link.lcp.cfg.forcelcpecho |= add;
+      break;
     case NEG_PAP:
       cx->physical->link.lcp.cfg.pap &= keep;
       cx->physical->link.lcp.cfg.pap |= add;
@@ -2977,6 +2982,9 @@
   {"lqr", NULL, NegotiateSet, LOCAL_AUTH | LOCAL_CX,
   "Link Quality Reports", "accept|deny|disable|enable",
   (const void *)NEG_LQR},
+  {"forcelcpecho", NULL, NegotiateSet, LOCAL_AUTH | LOCAL_CX,
+  "Link Quality Reports", "accept|deny|disable|enable",
+  (const void *)NEG_LCPECHO},
   {"pap", NULL, NegotiateSet, LOCAL_AUTH | LOCAL_CX,
   "Password Authentication protocol", "accept|deny|disable|enable",
   (const void *)NEG_PAP},
releng5-865# 
releng5-865# diff -u lcp.h.prev lcp.h
--- lcp.h.prev  Tue Dec  7 15:44:04 2004
+++ lcp.h       Tue Dec  7 15:51:21 2004
@@ -98,6 +98,7 @@
     unsigned chap81 : 2;       /* Microsoft CHAP v2 */
 #endif
     unsigned lqr : 2;          /* Link Quality Report */
+    unsigned forcelcpecho : 2;         /* Some PPPoE concentrators are broken for LQR. Allow users to force LCP ECHOS */
     unsigned pap : 2;          /* Password Authentication protocol */
     unsigned protocomp : 2;    /* Protocol field compression */
     char ident[DEF_MRU - 7];   /* SendIdentification() data */
releng5-865# 

releng5-865# diff -u lqr.c.prev lqr.c
--- lqr.c.prev  Tue Dec  7 15:43:34 2004
+++ lqr.c       Tue Dec  7 15:43:36 2004
@@ -276,8 +276,13 @@
          sizeof physical->hdlc.lqm.lqr.peer);
 
   physical->hdlc.lqm.method = LQM_ECHO;
-  if (IsEnabled(lcp->cfg.lqr) && !REJECTED(lcp, TY_QUALPROTO))
+  log_Printf(LogPHASE, "Enabling LQM_ECHO %s",physical->link.name);
+  if (IsEnabled(lcp->cfg.lqr) && !REJECTED(lcp, TY_QUALPROTO) && !IsEnabled(lcp->cfg.forcelcpecho) )
+ {
     physical->hdlc.lqm.method |= LQM_LQR;
+    log_Printf(LogPHASE, "Enabling LQM_LQR, not LQM_ECHO %s",physical->link.name);
+    
+ }
   timer_Stop(&physical->hdlc.lqm.timer);
 
   physical->hdlc.lqm.lqr.peer_timeout = lcp->his_lqrperiod;
releng5-865# 


In /etc/ppp/ppp.conf

the user just needs to add

 enable forcelcpecho

>Release-Note:
>Audit-Trail:

From: Mike Tancsa <mike@sentex.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: bin/74821: PPPoE with LQR is broken for users connecting
  to a Juniper ERX
Date: Wed, 08 Dec 2004 09:49:51 -0500

 And a quick blurb for the man page
 
 --- ppp.8.m4.prev       Wed Dec  8 09:37:30 2004
 +++ ppp.8.m4    Wed Dec  8 09:47:36 2004
 @@ -2777,6 +2777,14 @@
   We reject the peers discriminator if
   .Ar enddisc
   is denied.
 +.It forcelcpecho
 +Default: Disabled
 +This is used in conjunction with LQR enabled.   Some remote devices (e.g.
 +certain Juniper ERXes for PPPoE) will negotiate LQR LQM incorrectly
 +causing LQR to always fail resulting in ppp to constantly reconnect.
 +Enabling this option (enable forcelcpecho) causes FreeBSD to use
 +just LCPECHOS to monitor the link status.  Much of Canada has ERXes
 +for ADSL where this problem is particularly acute
   .It LANMan|chap80lm
   Default: Disabled and Accepted.
   The use of this authentication protocol
 
 
 
 --------------------------------------------------------------------
 Mike Tancsa,                                      tel +1 519 651 3400
 Sentex Communications,                            mike@sentex.net
 Providing Internet since 1994                    www.sentex.net
 Cambridge, Ontario Canada                         www.sentex.net/mike
 
Responsible-Changed-From-To: freebsd-bugs->brian 
Responsible-Changed-By: glebius 
Responsible-Changed-When: Sun Dec 12 14:51:06 GMT 2004 
Responsible-Changed-Why:  
Assign to ppp(8) maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=74821 
State-Changed-From-To: open->patched 
State-Changed-By: brian 
State-Changed-When: Mon Dec 13 12:49:55 GMT 2004 
State-Changed-Why:  
This has now been fixed in -current, but using a different fix. 

See the ``enable/disable echo'' command and src/UPDATING 

http://www.freebsd.org/cgi/query-pr.cgi?pr=74821 

From: Mike Tancsa <mike@sentex.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: bin/74821: PPPoE with LQR is broken for users connecting
  to a Juniper ERX
Date: Mon, 13 Dec 2004 10:53:54 -0500

 Thanks! This does indeed work now.  With just "enable echo", ppp is now 
 able to detect the loss of connectivity properly using PPPoE against the ERX.
 
 Is there any chance this could be MFC'd to RELENG_5 and perhaps even in 
 time for 4.11 ?  (Such a long xmas wish list! ;-) )
 
          ---Mike
 
 --------------------------------------------------------------------
 Mike Tancsa,                                      tel +1 519 651 3400
 Sentex Communications,                            mike@sentex.net
 Providing Internet since 1994                    www.sentex.net
 Cambridge, Ontario Canada                         www.sentex.net/mike
 

From: Brian Somers <brian@Awfulhak.org>
To: Mike Tancsa <mike@sentex.net>
Cc: freebsd-gnats-submit@FreeBSD.org, re@FreeBSD.org
Subject: Re: bin/74821: PPPoE with LQR is broken for users connecting  to a
 Juniper ERX
Date: Mon, 13 Dec 2004 17:56:48 +0000

 On Mon, 13 Dec 2004 10:53:54 -0500, Mike Tancsa <mike@sentex.net> wrote:
 > Thanks! This does indeed work now.  With just "enable echo", ppp is now 
 > able to detect the loss of connectivity properly using PPPoE against the ERX.
 > 
 > Is there any chance this could be MFC'd to RELENG_5 and perhaps even in 
 > time for 4.11 ?  (Such a long xmas wish list! ;-) )
 > 
 >          ---Mike
 
 Hmm, I'm not sure.  I've cc'd re@ for their opinion.
 
 This ``feature'' changes behaviour slightly.  Anyone expecting  that ppp
 will revert to sending LCP ECHOs when LQR negotiation fails will now be
 disappointed unless they add ``enable echo'' to their configuration.
 
 What do you think re@, should it be MFC'd ?
 
 -- 
 Brian <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
       <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
 Don't _EVER_ lose your sense of humour !

From: Ken Smith <kensmith@cse.Buffalo.EDU>
To: Brian Somers <brian@Awfulhak.org>
Cc: Mike Tancsa <mike@sentex.net>, freebsd-gnats-submit@FreeBSD.org,
	re@FreeBSD.org
Subject: Re: bin/74821: PPPoE with LQR is broken for users connecting  to a Juniper ERX
Date: Mon, 13 Dec 2004 13:00:07 -0500

 On Mon, Dec 13, 2004 at 05:56:48PM +0000, Brian Somers wrote:
 > On Mon, 13 Dec 2004 10:53:54 -0500, Mike Tancsa <mike@sentex.net> wrote:
 > > Thanks! This does indeed work now.  With just "enable echo", ppp is now 
 > > able to detect the loss of connectivity properly using PPPoE against the ERX.
 > > 
 > > Is there any chance this could be MFC'd to RELENG_5 and perhaps even in 
 > > time for 4.11 ?  (Such a long xmas wish list! ;-) )
 > > 
 > >          ---Mike
 > 
 > Hmm, I'm not sure.  I've cc'd re@ for their opinion.
 > 
 > This ``feature'' changes behaviour slightly.  Anyone expecting  that ppp
 > will revert to sending LCP ECHOs when LQR negotiation fails will now be
 > disappointed unless they add ``enable echo'' to their configuration.
 > 
 > What do you think re@, should it be MFC'd ?
 > 
 
 Sorry but given the behavior change (primarily, though lack of time
 for field-testing as well) I would prefer not.
 
 Thanks for the work - I'm sure it'll be useful in 5.X.  It's just a
 bit too late for it to make the 4.11 cut.
 
 -- 
 						Ken Smith
 - From there to here, from here to      |       kensmith@cse.buffalo.edu
   there, funny things are everywhere.   |
                       - Theodore Geisel |

From: Stephen McKay <smckay@internode.on.net>
To: Ken Smith <kensmith@cse.Buffalo.EDU>
Cc: Brian Somers <brian@Awfulhak.org>, Mike Tancsa <mike@sentex.net>,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/74821: PPPoE with LQR is broken for users connecting  to a Juniper ERX
Date: Wed, 15 Dec 2004 13:58:46 +1000

 Here is the code I have been using on FreeBSD 4.8 since July this year to
 deal with craziness imposed by our monopoly carrier (Telstra).  The patch
 applied cleanly to 4.10-stable, so I've done the diff there.
 
 The effect is that if LQR is negotiated but fails to happen, then LCP ECHOs
 will be used.  If that then fails, the link goes down, as this (anonymised)
 log file snippet shows:
 
 Dec 11 21:36:21 fw ppp[51]: tun0: IPCP: deflink: LayerUp. 
 Dec 11 21:36:21 fw ppp[51]: tun0: IPCP: myaddr XXX.XXX.XXX.XXX hisaddr = YYY.YYY.YYY.YYY
 .180.16 
 Dec 11 21:39:21 fw ppp[51]: tun0: Phase: deflink: ** Too many LQR packets lost *
 * 
 Dec 11 21:39:21 fw ppp[51]: tun0: Phase: deflink: ** Switching to LQR ECHO ** 
 Dec 12 03:05:02 fw ppp[51]: tun0: Phase: deflink: ** Too many ECHO LQR packets l
 ost ** 
 Dec 12 03:05:02 fw ppp[51]: tun0: CCP: deflink: State change Stopped --> Closed 
 Dec 12 03:05:02 fw ppp[51]: tun0: CCP: deflink: State change Closed --> Initial
 
 The link came back up at 03:26:24 after a few retries.  Presumably the ISP
 had been working on the line.
 
 (Amusing aside: Now that I've checked my logs, I've found 5 such occurrences
 since I applied this patch.  I was unaware of all of them. :-) )
 
 The down side of this patch is that if LQR actually works for you then if
 the line goes down there will be a fruitless switch to LCP ECHO before the
 dropout is detected.  I can live with that.  Maybe others can't.  Maybe it
 can be made optional behaviour depending on a config file flag.
 
 Anyway, it's food for thought, and scratches my itch.  It may help someone
 trolling the bug database, or inspire Brian in some way. :-)
 
 Stephen.
 
 PS Just noticed the tabs make the indenting look bad.  It's correct once
 it's applied.
 
 Index: lqr.c
 ===================================================================
 RCS file: /cvs/src/usr.sbin/ppp/lqr.c,v
 retrieving revision 1.40.2.5
 diff -u -c -r1.40.2.5 lqr.c
 *** lqr.c	4 Aug 2004 14:36:40 -0000	1.40.2.5
 --- lqr.c	7 Dec 2004 00:46:10 -0000
 ***************
 *** 173,180 ****
                   lcp->fsm.link->name);
         log_Printf(LogLQM, "%s: Too many LQR packets lost\n",
                   lcp->fsm.link->name);
 !       p->hdlc.lqm.method = 0;
 !       datalink_Down(p->dl, CLOSE_NORMAL);
       } else {
         SendLqrData(lcp);
         p->hdlc.lqm.lqr.resent++;
 --- 173,188 ----
                   lcp->fsm.link->name);
         log_Printf(LogLQM, "%s: Too many LQR packets lost\n",
                   lcp->fsm.link->name);
 !       p->hdlc.lqm.method &= ~LQM_LQR;
 !       if (p->hdlc.lqm.method == 0)
 ! 	datalink_Down(p->dl, CLOSE_NORMAL);
 !       else {
 ! 	log_Printf(LogPHASE, "%s: ** Switching to LQR ECHO **\n",
 ! 		  lcp->fsm.link->name);
 ! 	log_Printf(LogLQM, "%s: Switching to LQR ECHO\n",
 ! 		  lcp->fsm.link->name);
 ! 	SendEchoReq(lcp);
 !       }
       } else {
         SendLqrData(lcp);
         p->hdlc.lqm.lqr.resent++;

From: Brian Somers <brian@Awfulhak.org>
To: Stephen McKay <smckay@internode.on.net>
Cc: Ken Smith <kensmith@cse.Buffalo.EDU>,
	Mike Tancsa <mike@sentex.net>, freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/74821: PPPoE with LQR is broken for users connecting  to a
 Juniper ERX
Date: Wed, 15 Dec 2004 10:33:58 +0000

 This behaviour is a bit weird...  if the peer fails to reply to LQRs (after
 agreeing to at connection time), but the connection still works for over
 5 more hours, I can't help wondering what the peer thinks it's doing.
 
 The ppp spec says that the peer doesn't really have to respond to LQR
 packets (after agreeing to at connection time) unless the LQR packet has
 a duplicate id, in which case the peer MUST respond.  I believe this is
 to handle high traffic scenarios where the link is under heavy use and
 sending LQR traffic is better delayed.  Perhaps your ISP is (wrongly)
 disabling LQR under the high-traffic scenario.
 
 I wonder is it possible to get Telstra to look at their logs in this
 scenario and comment on why their implementation is behaving like this?
 
 From the sounds of it, using ``enable echo; disable lqr'' might be right
 for connections with Telstra...
 
 On Wed, 15 Dec 2004 13:58:46 +1000, Stephen McKay <smckay@internode.on.net> wrote:
 > Here is the code I have been using on FreeBSD 4.8 since July this year to
 > deal with craziness imposed by our monopoly carrier (Telstra).  The patch
 > applied cleanly to 4.10-stable, so I've done the diff there.
 > 
 > The effect is that if LQR is negotiated but fails to happen, then LCP ECHOs
 > will be used.  If that then fails, the link goes down, as this (anonymised)
 > log file snippet shows:
 > 
 > Dec 11 21:36:21 fw ppp[51]: tun0: IPCP: deflink: LayerUp. 
 > Dec 11 21:36:21 fw ppp[51]: tun0: IPCP: myaddr XXX.XXX.XXX.XXX hisaddr = YYY.YYY.YYY.YYY
 > .180.16 
 > Dec 11 21:39:21 fw ppp[51]: tun0: Phase: deflink: ** Too many LQR packets lost *
 > * 
 > Dec 11 21:39:21 fw ppp[51]: tun0: Phase: deflink: ** Switching to LQR ECHO ** 
 > Dec 12 03:05:02 fw ppp[51]: tun0: Phase: deflink: ** Too many ECHO LQR packets l
 > ost ** 
 > Dec 12 03:05:02 fw ppp[51]: tun0: CCP: deflink: State change Stopped --> Closed 
 > Dec 12 03:05:02 fw ppp[51]: tun0: CCP: deflink: State change Closed --> Initial
 > 
 > The link came back up at 03:26:24 after a few retries.  Presumably the ISP
 > had been working on the line.
 > 
 > (Amusing aside: Now that I've checked my logs, I've found 5 such occurrences
 > since I applied this patch.  I was unaware of all of them. :-) )
 > 
 > The down side of this patch is that if LQR actually works for you then if
 > the line goes down there will be a fruitless switch to LCP ECHO before the
 > dropout is detected.  I can live with that.  Maybe others can't.  Maybe it
 > can be made optional behaviour depending on a config file flag.
 > 
 > Anyway, it's food for thought, and scratches my itch.  It may help someone
 > trolling the bug database, or inspire Brian in some way. :-)
 > 
 > Stephen.
 > 
 > PS Just noticed the tabs make the indenting look bad.  It's correct once
 > it's applied.
 > 
 > Index: lqr.c
 > ===================================================================
 > RCS file: /cvs/src/usr.sbin/ppp/lqr.c,v
 > retrieving revision 1.40.2.5
 > diff -u -c -r1.40.2.5 lqr.c
 > *** lqr.c	4 Aug 2004 14:36:40 -0000	1.40.2.5
 > --- lqr.c	7 Dec 2004 00:46:10 -0000
 > ***************
 > *** 173,180 ****
 >                   lcp->fsm.link->name);
 >         log_Printf(LogLQM, "%s: Too many LQR packets lost\n",
 >                   lcp->fsm.link->name);
 > !       p->hdlc.lqm.method = 0;
 > !       datalink_Down(p->dl, CLOSE_NORMAL);
 >       } else {
 >         SendLqrData(lcp);
 >         p->hdlc.lqm.lqr.resent++;
 > --- 173,188 ----
 >                   lcp->fsm.link->name);
 >         log_Printf(LogLQM, "%s: Too many LQR packets lost\n",
 >                   lcp->fsm.link->name);
 > !       p->hdlc.lqm.method &= ~LQM_LQR;
 > !       if (p->hdlc.lqm.method == 0)
 > ! 	datalink_Down(p->dl, CLOSE_NORMAL);
 > !       else {
 > ! 	log_Printf(LogPHASE, "%s: ** Switching to LQR ECHO **\n",
 > ! 		  lcp->fsm.link->name);
 > ! 	log_Printf(LogLQM, "%s: Switching to LQR ECHO\n",
 > ! 		  lcp->fsm.link->name);
 > ! 	SendEchoReq(lcp);
 > !       }
 >       } else {
 >         SendLqrData(lcp);
 >         p->hdlc.lqm.lqr.resent++;
 > 
 
 
 -- 
 Brian <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
       <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
 Don't _EVER_ lose your sense of humour !

From: Rudolph Pereira <memetical@yahoo.com.au>
To: freebsd-gnats-submit@FreeBSD.org, brian@freebsd.org
Cc:  
Subject: Re: bin/74821: PPPoE with LQR is broken for users connecting to a Juniper ERX
Date: Wed, 12 Jan 2005 05:54:26 +1100

 Any chance the official fix in -CURRENT will be backported to RELENG_5?
 If so, any idea when?
 
 thanks
State-Changed-From-To: patched->closed 
State-Changed-By: brian 
State-Changed-When: Thu Feb 3 10:53:52 GMT 2005 
State-Changed-Why:  
The ``enable/disable echo'' changes have been MFCd 

http://www.freebsd.org/cgi/query-pr.cgi?pr=74821 
>Unformatted:
