Date: Sun, 7 May 2000 12:04:06 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: brian@Awfulhak.org (Brian Somers) Cc: brian@FreeBSD.org (Brian Somers), cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/ppp mbuf.c Message-ID: <200005071904.MAA22237@gndrsh.dnsmgr.net> In-Reply-To: <200005071352.OAA48459@hak.lan.Awfulhak.org> from Brian Somers at "May 7, 2000 02:52:15 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > brian 2000/05/07 03:09:26 PDT > > > > > > Modified files: (Branch: RELENG_4) > > > usr.sbin/ppp mbuf.c > > > Log: > > > MFC: Correct a bad bug in m_prepend() > > > > Can you describe the ``bug''? > > Errum, it was m_append() :-/ The bug was in the user-land mbuf code > (nothing to do with anything but ppp(8)) and meant that if the mbuf > had more than one segment, the last segment in the chain was returned > as the new head segment. > > I'm not entirely sure that multi-segment mbufs were ever actually > passed to m_append(), but I suspect they were. > > The result of this bug was that the packet would be pushed into the > tun device and promptly dropped as garbage. I believe that people > with ipfw configured in the kernel would see a message something like: > > ipfw: -1 Refuse UDP 194.242.139.171 213.1.151.12 in via tun1 Fragment = 185 > > but I'm not 100% sure about that either ! > > I figured it was pretty important to get the fix in asap rather than > waiting 'till I had time to prove the consequences. Thank you for the clarification!! (I am keeping a keen eye on anything ppp related right now as we are having a very strange, ever few days where it seems that data rates go to hell in a hand basket on a 4B channel ISDN mppp setup, you can ping, you can get some data through, but other connections go to a snails pace. Unfortanetly it is a production link so I have to put it back up asap and can't do much debugging on it, and trying to duplicate it in the lab has turned up zilch :-(. Killing off and restarting ppp clears it right up. We started out with 3.4 and are now at 4.0-stable and still seeing it. I am starting to suspect the equipment on the other end (Max TNT TOS 7.2.3). -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005071904.MAA22237>