From nobody@FreeBSD.ORG Fri Apr 23 09:46:06 1999 Return-Path: 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: