From owner-freebsd-hackers Fri Jan 12 07:41:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA16481 for hackers-outgoing; Fri, 12 Jan 1996 07:41:17 -0800 (PST) Received: from etinc.com (et-gw.etinc.com [165.254.13.209]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA16470 for ; Fri, 12 Jan 1996 07:41:07 -0800 (PST) Received: from ppp-082.etinc.com (ppp-082.etinc.com [204.141.95.142]) by etinc.com (8.6.12/8.6.9) with SMTP id KAA01397; Fri, 12 Jan 1996 10:39:28 -0500 Date: Fri, 12 Jan 1996 10:39:28 -0500 Message-Id: <199601121539.KAA01397@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: John Capo From: dennis@etinc.com (dennis) Subject: Re: pppd vs ijppp (Bug Fixes) Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >Two features iijppp has over kernel ppp that I like are predictor1 >compression and demand dialing. Here are a few bug fixes. > >I expanded the priority queueing scheme and discovered it was broken >due to the assignment at ip.c line 300. All packets were being >queued at the same priority. > >Fixing priority queueing broke predictor1 compression. Packets >were compressed before being queued and predictor1 worked as long >as the packets were popped off the queue in the same order they >were pushed onto the queue. > >There were a few byte order problems in IP header tests also. > >There is a recursion problem in SendLqrReport(). LcpClose() is >called when "Too many echo packets are lost" which winds up in >SendLqrReport() again. I believe the original intention was to >just stop the LQR timer with the call to StopLqr() but the side >effects hurt. > >#0 0xa2da in SendLqrReport () at lqr.c:121 >#1 0xa5e5 in StopLqr (method=1) at lqr.c:227 >#2 0x97d1 in LcpLayerDown (fp=0x17088) at lcp.c:375 >#3 0x6046 in FsmClose (fp=0x17088) at fsm.c:185 >#4 0x985d in LcpClose () at lcp.c:405 >#5 0xa2da in SendLqrReport () at lqr.c:121 >#6 0xa5e5 in StopLqr (method=1) at lqr.c:227 >#7 0x97d1 in LcpLayerDown (fp=0x17088) at lcp.c:375 >#8 0x6046 in FsmClose (fp=0x17088) at fsm.c:185 >#9 0x985d in LcpClose () at lcp.c:405 >#10 0xa2da in SendLqrReport () at lqr.c:121 >#11 0xa5e5 in StopLqr (method=1) at lqr.c:227 >#12 0x97d1 in LcpLayerDown (fp=0x17088) at lcp.c:375 >#13 0x5fb6 in FsmDown (fp=0x17088) at fsm.c:164 >#14 0x9829 in LcpDown () at lcp.c:391 >#15 0xcfe3 in DownConnection () at modem.c:212 > >There is a send-pr black hole report on the recursion bug. > >I suspect another recursion problem somewhere that does not >spit out a message. Symptoms are illegal instructions and >a completely trashed core dump, 90% 0's. > This is what you're calling "easier to debug"? :) db ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25