Date: Sun, 07 May 2000 14:52:15 +0100 From: Brian Somers <brian@Awfulhak.org> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> 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: <200005071352.OAA48459@hak.lan.Awfulhak.org> In-Reply-To: Message from "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> of "Sun, 07 May 2000 05:29:32 PDT." <200005071229.FAA21396@gndrsh.dnsmgr.net>
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.
> --
> Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net
--
Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
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?200005071352.OAA48459>