From mph@pobox.com@townhouse.dyn.ml.org  Sun Jun  1 20:00:41 1997
Received: from townhouse.dyn.ml.org (root@ppp01.rsd.jtwn.k12.pa.us [147.160.218.240])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA21537
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 1 Jun 1997 20:00:32 -0700 (PDT)
Received: (from hunt@localhost)
	by townhouse.dyn.ml.org (8.8.5/8.8.5) id WAA00910;
	Sun, 1 Jun 1997 22:53:46 -0400 (EDT)
Message-Id: <199706020253.WAA00910@townhouse.dyn.ml.org>
Date: Sun, 1 Jun 1997 22:53:46 -0400 (EDT)
From: Matthew Hunt <mph@pobox.com>
To: FreeBSD-gnats-submit@freebsd.org
Subject: Kernel panic with kernel-PPP and natd-1.4
X-Send-Pr-Version: 3.2

>Number:         3749
>Category:       kern
>Synopsis:       Kernel panic with kernel-PPP and natd-1.4
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    brian
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jun  1 20:10:01 PDT 1997
>Closed-Date:    Sat Jun 21 19:18:33 PDT 1997
>Last-Modified:  Sat Jun 21 19:23:30 PDT 1997
>Originator:     Matthew Hunt
>Release:        FreeBSD 2.2-STABLE i386
>Organization:
none
>Environment:

FreeBSD townhouse.dyn.ml.org 2.2-STABLE FreeBSD 2.2-STABLE #1: Sun Jun  1 21:22:34 EDT 1997     hunt@townhouse.dyn.ml.org:/usr/src/sys/compile/WOPR  i386

natd-1.4 built from ports collection

>Description:

I have ed0 unused and ed1 (10.0.0.1) connected to a private network
that was, at the time, otherwise empty.  I dial in using kernel PPP.

townhouse:/var/crash$ netstat -inM vmcore.1 
Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll
ed0*  1500  <Link>      00.00.e8.c3.2c.32        0     0        0     0     0
ed1   1500  <Link>      00.40.95.a6.1a.92        0     0        1     0     0
ed1   1500  10            10.0.0.1               0     0        1     0     0
lp0*  1500  <Link>                               0     0        0     0     0
tun0* 1500  <Link>                               0     0        0     0     0
tun1* 1500  <Link>                               0     0        0     0     0
ppp0  1500  <Link>                             226     0      277     0     0
ppp0  1500  147.160       147.160.218.240      226     0      277     0     0
ppp1* 1500  <Link>                               0     0        0     0     0
lo0   16384 <Link>                              66     0       66     0     0
lo0   16384 127           127.0.0.1             66     0       66     0     0

townhouse:/var/crash$ netstat -rnM vmcore.1
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use     Netif Expire
default            147.160.218.15     UGSc       13        0      ppp0
10                 link#2             UC          0        0 
127.0.0.1          127.0.0.1          UH          1       66       lo0
147.160.218.15     147.160.218.240    UH         15       34      ppp0


I used these ipfw rules:

01000 allow ip from 127.0.0.1 to 127.0.0.1
02000 divert 32000 all from 10.0.0.0/8 to any via ed1
02100 divert 32000 all from any to any via ppp0
65000 allow ip from any to any
65535 deny ip from any to any

My /etc/ppp/options:

/dev/cuaa2 19200
crtscts
modem
noipdefault
passive
defaultroute
bsdcomp 9,9
connect "/usr/bin/chat -v -t 90 -f /etc/ppp/login.ramsesjr.chat"


My natd configuration was as follows, with the comments deleted for
brevity:

log		yes
deny_incoming	no
use_sockets	no
same_ports	yes
verbose		no
port		32000
interface	ppp0
unregistered_only	no


>How-To-Repeat:

When connected, I would attempt a "make fetch" in
/usr/ports/graphics/povray.  The connection attempt to the first
MASTER_SITE would fail to log in.  During the connection attempt to
the second MASTER_SITE (hensa) the kernel would panic.  The panic does
not occur if I do not use natd.  My system has never suffered any
unexplained panic or crashes before, and this panic is 100%
reproducible on the machine.

A kgdb session follows:

Script started on Sun Jun  1 22:22:27 1997
townhouse:/usr/src/sys/compile/WOPR# gdb -k
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc.
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.1
(kgdb) core-file /var/crash/vmcore.1
IdlePTD 203000
current pcb at 1e3f58
panic: page fault
#0  boot (howto=256) at ../../kern/kern_shutdown.c:243
243					dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0  boot (howto=256) at ../../kern/kern_shutdown.c:243
#1  0xf01175f2 in panic (fmt=0xf01b5daf "page fault")
    at ../../kern/kern_shutdown.c:367
#2  0xf01b6916 in trap_fatal (frame=0xefbffda8) at ../../i386/i386/trap.c:742
#3  0xf01b6404 in trap_pfault (frame=0xefbffda8, usermode=0)
    at ../../i386/i386/trap.c:653
#4  0xf01b60df in trap (frame={tf_es = 16, tf_ds = -266403824, 
      tf_edi = -263917312, tf_esi = -1073544550, tf_ebp = -272630296, 
      tf_isp = -272630320, tf_ebx = -263901184, tf_edx = 1073532433, 
      tf_ecx = -16061, tf_eax = 1073479886, tf_trapno = 12, tf_err = 0, 
      tf_eip = -267073250, tf_cs = -1073545208, tf_eflags = 66066, 
      tf_esp = -263917312, tf_ss = -272630224}) at ../../i386/i386/trap.c:311
#5  0xf014c91e in pppfcs (fcs=62816, cp=0xf044f149 "\026&t", len=-5)
    at ../../net/ppp_tty.c:577
#6  0xf014caaf in pppstart (tp=0xf01edee8) at ../../net/ppp_tty.c:674
#7  0xf014c961 in pppasyncstart (sc=0xf01f31d0) at ../../net/ppp_tty.c:593
#8  0xf014a06d in ppp_outpkt (sc=0xf01f31d0) at ../../net/if_ppp.c:996
#9  0xf0149d6b in pppintr () at ../../net/if_ppp.c:851
#10 0xf01aff39 in swi_net_next ()
#11 0xf012df81 in sendit (p=0xf064c800, s=3, mp=0xefbfff38, flags=0, 
    retsize=0xefbfff84) at ../../kern/uipc_syscalls.c:487
#12 0xf012e060 in sendto (p=0xf064c800, uap=0xefbfff94, retval=0xefbfff84)
    at ../../kern/uipc_syscalls.c:538
#13 0xf01b6baf in syscall (frame={tf_es = 39, tf_ds = -272760793, tf_edi = 3, 
      tf_esi = 84, tf_ebp = -272638816, tf_isp = -272629788, 
      tf_ebx = -272704352, tf_edx = 1, tf_ecx = -272704352, tf_eax = 133, 
      tf_trapno = 7, tf_err = 7, tf_eip = 134624257, tf_cs = 31, 
      tf_eflags = 582, tf_esp = -272704492, tf_ss = 39})
    at ../../i386/i386/trap.c:890
#14 0x8063401 in ?? ()
#15 0x1cc0 in ?? ()
#16 0x1096 in ?? ()
(kgdb) frame 5
#5  0xf014c91e in pppfcs (fcs=62816, cp=0xf044f149 "\026&t", len=-5)
    at ../../net/ppp_tty.c:577
577		fcs = PPP_FCS(fcs, *cp++);
(kgdb) info frame
Stack level 5, frame at 0xefbffde8:
 eip = 0xf014c91e in pppfcs (../../net/ppp_tty.c:577); saved eip 0xf014caaf
 called by frame at 0xefbffe30, caller of frame at 0xefbffda0
 source language c.
 Arglist at 0xefbffde8, args: fcs=62816, cp=0xf044f149 "\026&t", len=-5
 Locals at 0xefbffde8, Previous frame's sp is 0x0
 Saved registers:
  ebx at 0xefbffde4, ebp at 0xefbffde8, eip at 0xefbffdec
(kgdb) list
572	    register u_short fcs;
573	    register u_char *cp;
574	    register int len;
575	{
576	    while (len--)
577		fcs = PPP_FCS(fcs, *cp++);
578	    return (fcs);
579	}
580	
581	/*
(kgdb) p fcs
$1 = 0
(kgdb) p cp
$2 = (unsigned char *) 0xf0453000 <Address 0xf0453000 out of bounds>
(kgdb) quit

Script done on Sun Jun  1 22:24:24 1997


>Fix:
	
Sorry, unknown.  If I can provide any more information that would be
helpful, just ask.  I'm keeping the kernel and core images around.

>Release-Note:
>Audit-Trail:

From: j@uriah.heep.sax.de (J Wunsch)
To: mph@pobox.com (Matthew Hunt)
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/3749: Kernel panic with kernel-PPP and natd-1.4
Date: Mon, 2 Jun 1997 08:46:58 +0200

 As Matthew Hunt wrote:
 
 > #5  0xf014c91e in pppfcs (fcs=62816, cp=0xf044f149 "\026&t", len=-5)
                                                                ^^^^^^
 That's the culprit.  pppfcs counts the address down until the length
 is 0.  With a negative length, this will always crash.
 
 >     at ../../net/ppp_tty.c:577
 > #6  0xf014caaf in pppstart (tp=0xf01edee8) at ../../net/ppp_tty.c:674
 
 pppstart() obtains this length directly from an mbuf.  I've got too
 few clues about the upper layers to investigate why this packet made
 it there.
 
 As a stop-gap measure, you could modify the counter in pppfcs() to
 
 	while (len-- > 0)
 
 Perhaps this lets you find more about the misbehaviour (since it will
 only yield an invalid packet then, but hopefully not crash).
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)

----
The above method is now implemented in 2.2 & -current, but "jam"s the
interface.  The packet sits there trying to go out, but never goes :(

I'm looking into it.
State-Changed-From-To: open->closed 
State-Changed-By: brian 
State-Changed-When: Sat Jun 21 19:18:33 PDT 1997 
State-Changed-Why:  
The fix has been committed to 2.2 & -current.  Turns 
out to be a problem with vj header compression. 


Responsible-Changed-From-To: freebsd-bugs->brian 
Responsible-Changed-By: brian 
Responsible-Changed-When: Sat Jun 21 19:18:33 PDT 1997 
Responsible-Changed-Why:  
I found the culprit. 
>Unformatted:
