From owner-cvs-all  Sun May  7 12: 4:34 2000
Delivered-To: cvs-all@freebsd.org
Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4])
	by hub.freebsd.org (Postfix) with ESMTP
	id 168D437BB27; Sun,  7 May 2000 12:04:28 -0700 (PDT)
	(envelope-from freebsd@gndrsh.dnsmgr.net)
Received: (from freebsd@localhost)
	by gndrsh.dnsmgr.net (8.9.3/8.9.3) id MAA22237;
	Sun, 7 May 2000 12:04:07 -0700 (PDT)
	(envelope-from freebsd)
From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
Message-Id: <200005071904.MAA22237@gndrsh.dnsmgr.net>
Subject: Re: cvs commit: src/usr.sbin/ppp mbuf.c
In-Reply-To: <200005071352.OAA48459@hak.lan.Awfulhak.org> from Brian Somers at "May 7, 2000 02:52:15 pm"
To: brian@Awfulhak.org (Brian Somers)
Date: Sun, 7 May 2000 12:04:06 -0700 (PDT)
Cc: brian@FreeBSD.org (Brian Somers), cvs-committers@FreeBSD.org,
	cvs-all@FreeBSD.org
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > > 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