From nobody@FreeBSD.ORG Fri Apr 23 09:46:06 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 1B1441517D; Fri, 23 Apr 1999 09:46:06 -0700 (PDT)
Message-Id: <19990423164606.1B1441517D@hub.freebsd.org>
Date: Fri, 23 Apr 1999 09:46:06 -0700 (PDT)
From: john@spider.com
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: FreeBSD's PPP implementation of LQM appears to be incorrect.
X-Send-Pr-Version: www-1.0

>Number:         11293
>Category:       kern
>Synopsis:       FreeBSD's PPP implementation of LQM appears to be incorrect.
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    brian
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Apr 23 09:50:02 PDT 1999
>Closed-Date:    Wed Aug 04 14:44:04 GMT 2004
>Last-Modified:  Wed Aug 04 14:44:04 GMT 2004
>Originator:     John Collin
>Release:        2.2.5
>Organization:
>Environment:
FreeBSD tcpint1.spider.com 2.2.5-RELEASE FreeBSD 2.2.5-RELEASE #0: Tue Feb  3 14:32:26 GMT 1998     root@tcpint1.spider.com:/usr/src/sys/compile/SPIDER  i386
>Description:
While doing inter-op testing against FreeBSD, we noted that our LQM
analysis would give invalid figures.

It appears that the LQM protocol is not implemented correctly in FreeBSD.
It is directly updating the SaveInXXX variables on receiving any packet
type, rather than copying them from the mib on reception of a LQR from
a remote peer. This leads to invalid values being TX'ed in a report.
This becomes more obvious when the LQR periods on the two machines are
of a different size.
peer.
>How-To-Repeat:
Run against a working inplementation of LQM, making the report periods
different.
>Fix:
Copy the relevant values to the SavInXXXX fields from the relevant mib
(or InLQRs for SaveInLQRs), as specified in the RFC1989.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: gnats-admin->freebsd-bugs 
Responsible-Changed-By: steve 
Responsible-Changed-When: Mon Apr 26 15:56:23 PDT 1999 
Responsible-Changed-Why:  
Misfiled PR. 
Responsible-Changed-From-To: freebsd-bugs->brian 
Responsible-Changed-By: brian 
Responsible-Changed-When: Mon Apr 26 18:16:22 PDT 1999 
Responsible-Changed-Why:  
Ppp's mine. 
State-Changed-From-To: open->patched 
State-Changed-By: brian 
State-Changed-When: Tue Jun 29 16:55:03 GMT 2004 
State-Changed-Why:  
I've re-implemented the LQM stuff and committed to -current. 

I'd be interested in peoples comments on the analysis that now 
turns up with ``set log +lqm''.  My only real-world testing has 
been with my ADSL provider, and with output such as: 

LQM: ADSL: Input: 
LQM:   Magic:          22264bc4   LastOutLQRs:    00000011 
LQM:   LastOutPackets: 0000267d   LastOutOctets:  00ba1202 
LQM:   PeerInLQRs:     00000010   PeerInPackets:  02f31620 
LQM:   PeerInDiscards: 00000000   PeerInErrors:   00000000 
LQM:   PeerInOctets:   bc00380e   PeerOutLQRs:    00000010 
LQM:   PeerOutPackets: 4348204d   PeerOutOctets:  4441502f 
[.....] 
LQM: ADSL: Input: 
LQM:   Magic:          22264bc4   LastOutLQRs:    00000012 
LQM:   LastOutPackets: 00002a91   LastOutOctets:  00ce7585 
LQM:   PeerInLQRs:     00000011   PeerInPackets:  02f31a34 
LQM:   PeerInDiscards: 00000000   PeerInErrors:   00000000 
LQM:   PeerInOctets:   bc14a3b9   PeerOutLQRs:    00000011 
LQM:   PeerOutPackets: 00000000   PeerOutOctets:  00004545 
LQM: Analysis: 
LQM:   Outbound lossage: 0 LQRs (0 en route), 0 packets, -2088 octets 
LQM:   Inbound lossage: -1128801017 packets, -1145157573 octets 
LQM:                    Likely due to transport congestion 

I can only blame their implementation -- believe me, those 
PeerOutPackets/Octets are not for real!!!  Perhaps they're 
including some L2TP header info or something with their 
PeerInOctets value... 

http://www.freebsd.org/cgi/query-pr.cgi?pr=11293 
State-Changed-From-To: patched->closed 
State-Changed-By: brian 
State-Changed-When: Wed Aug 4 14:42:44 GMT 2004 
State-Changed-Why:  
Close this bug now that the LQM changes have been MFC'd. 
I may still apply the revert-to-echo-lqr changes if the people 
experiencing lqr problems still have them after this change. 

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