From owner-freebsd-hackers  Sun Jun  8 23:19:42 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id XAA06928
          for hackers-outgoing; Sun, 8 Jun 1997 23:19:42 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA06923
          for <freebsd-hackers@FreeBSD.ORG>; Sun, 8 Jun 1997 23:19:38 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id QAA06988; Mon, 9 Jun 1997 16:14:17 +1000
Date: Mon, 9 Jun 1997 16:14:17 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199706090614.QAA06988@godzilla.zeta.org.au>
To: freebsd-hackers@FreeBSD.ORG, lenzi@bsi.com.br
Subject: Re: pppd & natd problem turnaround..
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>I have seen some messages dealing with pppd & natd panicing FreeBSD 2.2
>systems.
>
>The problem arises when a negative m->m_len value is reveived in function
>pppfcs in module sys/net/ppp_tty.c 

ISTR this bug from a few years ago.  The fix may have been to fix splimp()
to prevent a race.  2.2 has a similar bug in splimp().  It only occurs
when neither pppd nor slip is configured in the kernel and the pppd LKM
is used.  Do you have this configuration?

>A turnaround is to replace m_len to ZERO whenever is less then zero.
>
>I know it is not the best, but it works for now.

Better find the real bug.  m->m_len < 0 "can't happen".

Bruce