ppp(8) v. 3.1 : PPPoE lqr problem.

[Mike Tancsa]

Hi,
         I know this post is a year old, but I figure I might as well post 
what I think is the answer for future archive searches.

According to the man page for ppp
When LQR is enabled, ppp sends
              the QUALPROTO option (see ``set lqrperiod'' below) as part of the
              LCP request.  If the peer agrees, both sides will exchange LQR
              packets at the agreed frequency, allowing detailed link quality
              monitoring by enabling LQM logging.  If the peer doesn't agree,
              ppp will send ECHO LQR requests instead.  These packets pass no
              information of interest, but they MUST be replied to by the peer.

The problem is that LQR is agreed to with the ERX (the PPPoE terminating 
device on the other end), but it never works. If you force the FreeBSD side 
to use plain old ECHO LQR requests, everything works as expected.  I dont 
know if this is an ERX bug or a FreeBSD bug but one needs to work around it 
some how.

I know this is a really ugly way to do it, but I did this patch to force 
"plan B"
--- lcp.c       Sat Aug 31 22:12:28 2002
+++ lcp.c.patch Fri Nov 21 19:50:07 2003
@@ -575,6 +575,11 @@
    log_Printf(LogLCP, "%s: LayerUp\n", fp->link->name);
    physical_SetAsyncParams(p, lcp->want_accmap, lcp->his_accmap);
    lqr_Start(lcp);
+
+
+  p->hdlc.lqm.method = LQM_ECHO;
+
+
    hdlc_StartTimer(&p->hdlc);
    fp->more.reqs = fp->more.naks = fp->more.rejs = lcp->cfg.fsm.maxreq * 3;


It now works and FreeBSD can correctly detect if the link went away and 
therefore try to re-connect.  With out this change, your box will never 
re-connect if the modem loses sync.  I emailed brian at awfulhak.org, but 
didnt hear anything back. Perhaps he is not active with FreeBSD any more.

Anyone have any suggestions as to how to better work around it ?  Perhaps 
an addition of something like
         UseLCPEcho 1
to ppp.conf ?

         ---Mike


         ---Mike


At 06:54 PM 30/09/2002, Artur Pydo wrote:
>Hello,
>
>Since the end of August i had problems running my ADSL connection.
>I had a lof of messages from IPFilter about blocked ACK packets
>on legitimate TCP connection. IPFilter was OK. :)
>I discovered that ppp changed its behaviour regarding lqr after
>the upgrade from version 2.3.3 to 3.1.
>This is a part of the log from ppp 2.3.3 once the connection
>established :
>...
>01:11:08 fw ppp[1419]: LCP: deflink: LayerUp
>01:11:08 fw ppp[1419]: LCP: deflink: SendEchoRequest(0) state = Opened
>01:11:08 fw ppp[1419]: LCP: Sending ident magic c3ed2b1d text user-ppp 
>2.3.3 (built Sep 30 2002)
>01:11:08 fw ppp[1419]: LCP: deflink: SendIdent(3) state = Opened
>01:11:08 fw ppp[1419]: LCP: deflink: RecvEchoReply(0) state = Opened
>01:11:09 fw ppp[1419]: LCP: deflink: RecvProtocolRej(174) state = Opened
>01:11:09 fw ppp[1419]: LCP: deflink: -- Protocol 0x80fd (Compression 
>Control Protocol) was rejected!
>01:11:12 fw ppp[1419]: LCP: deflink: RecvEchoRequest(1) state = Opened
>01:11:12 fw ppp[1419]: LCP: deflink: SendEchoReply(1) state = Opened
>01:11:13 fw ppp[1419]: LCP: deflink: SendEchoRequest(1) state = Opened
>01:11:13 fw ppp[1419]: LCP: deflink: RecvEchoReply(1) state = Opened
>01:11:18 fw ppp[1419]: LCP: deflink: SendEchoRequest(2) state = Opened
>01:11:18 fw ppp[1419]: LCP: deflink: RecvEchoReply(2) state = Opened
>01:11:23 fw ppp[1419]: LCP: deflink: RecvEchoRequest(2) state = Opened
>01:11:23 fw ppp[1419]: LCP: deflink: SendEchoReply(2) state = Opened
>
>One can see that ppp(8) sends EchoRequest packets to verify the link
>and answers received EchoRequest.
>The same connection log with ppp 3.1 :
>...
>01:12:20 fw ppp[1429]: LCP: deflink: LayerUp
>01:12:20 fw ppp[1429]: LCP: deflink: SendIdent(3) state = Opened
>01:12:20 fw ppp[1429]: LCP:  MAGICNUM 7fdbdff7
>01:12:20 fw ppp[1429]: LCP:  TEXT user-ppp 3.1 (built Sep 28 2002)
>01:12:20 fw ppp[1429]: LCP: deflink: RecvProtocolRej(161) state = Opened
>01:12:20 fw ppp[1429]: LCP: deflink: -- Protocol 0x80fd (Compression 
>Control Protocol) was rejected!
>01:12:29 fw ppp[1429]: LCP: deflink: RecvEchoRequest(1) state = Opened
>01:12:29 fw ppp[1429]: LCP: deflink: SendEchoReply(1) state = Opened
>01:12:40 fw ppp[1429]: LCP: deflink: RecvEchoRequest(2) state = Opened
>01:12:40 fw ppp[1429]: LCP: deflink: SendEchoReply(2) state = Opened
>01:12:50 fw ppp[1429]: LCP: deflink: RecvEchoRequest(3) state = Opened
>01:12:50 fw ppp[1429]: LCP: deflink: SendEchoReply(3) state = Opened
>01:13:00 fw ppp[1429]: LCP: deflink: RecvEchoRequest(4) state = Opened
>01:13:00 fw ppp[1429]: LCP: deflink: SendEchoReply(4) state = Opened
>01:13:10 fw ppp[1429]: LCP: deflink: RecvEchoRequest(5) state = Opened
>01:13:10 fw ppp[1429]: LCP: deflink: SendEchoReply(5) state = Opened
>01:13:20 fw ppp[1429]: LCP: deflink: LayerDown
>
>ppp(8) answers received EchoRequest but does not send any EchoRequest
>to the peer. Moreover, the connection is closed as if the EchoRequest
>packets has been sent and there was no answer.
>
>The complete log is quite long but i can send it. I followed the recent
>thread about some troubles with PPPoE and tried to modify vjcomp setup
>with no result (but my ADSL installation is located in France).
>
>ppp(8) is launched from rc.conf with the following command line :
>ppp -ddial adsl
>
>My ppp.conf:
>
>default:
>  ident user-ppp VERSION (built COMPILATIONDATE)
>
>adsl:
>
>  set log LCP
>  set device PPPoE:rl1
>  set ctsrts off
>  set authname xxxx
>  set authkey abcd
>  set dial
>  set login
>  add default HISADDR
>  set mtu 1492
>  set mru 1492
>  set lqrperiod 5
>  enable lqr
>  set speed sync
>  set redial 0 0
>  set ifaddr 62.212.97.116/0 10.0.0.2/0
>  disable vjcomp
>
>Thanks a lot for your help.
>
>Best regards,
>
>Artur.
>
>
>To Unsubscribe: send mail to majordomo at FreeBSD.org
>with "unsubscribe freebsd-stable" in the body of the message