Date: Fri, 12 Jan 1996 10:39:28 -0500 From: dennis@etinc.com (dennis) To: John Capo <jc@irbs.com> Cc: hackers@freebsd.org Subject: Re: pppd vs ijppp (Bug Fixes) Message-ID: <199601121539.KAA01397@etinc.com>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601121539.KAA01397>