Bug 17030

 Steve,
 
 I'm having stability problems with this patch.  When an arp lookup is
 attempted, I get a hang.  The kernel is still live, and apparently in
 kernel/interrupt context.  I don't have much debugging turned onin the
 kernel, and don't have a proper debugging setup here, but here's ddb's
 stack trace (from breaking to the debugger)
 
 Debugger(c032a989) at Debugger+0x35
 scgetc(c0398de0,2,c06ae100,c03913a0,ffffffff) at scgetc+0x37e
 sckbdevent(c03913a0,0,c0398de0,c06ae100,1a0f080a) at sckbdevent+0x1b9
 atkbd_intr(c03913a0,0,c0339dac,c02c14d2,c03913a0) at atkbd_intr+0x22
 atkbd_isa_intr(c03913a0,40020000,40020010,10,c06a0010) at
 atkbd_isa_intr+0x18
 Xresume1() at Xresume1+0x2b
 --- interrupt, eip = 0xc01d2531, esp = 0xc0339d9c, ebp = 0xc0339dac ---
 arpintr(c02c1d7b,0, c0210010,40000010,ffff0010) at arpintr+0xd9
 swi_net_next() at swi_net_next
 
 My guess is you're recusively locking or something from interrupt context,
 or the like.  As the console is still live, it's not as dead as it could
 be, for example :-)
 
 Interestingly, this is (I believe) the second ARP lookup, not the first
 one, if that helps any. Prior to the hang, arp -an reported one entry, it
 was attempting to contact a second IP that caused the trouble.
 
 
 On Thu, 24 Feb 2000 csg@waterspout.com wrote:
 
 > 
 > >Submitter-Id:   current-users
 > >Originator:     C. Stephen Gunn
 > >Organization:   WaterSpout Communications, Inc.
 > >Confidential:   no
 > >Synopsis:       arpintr() incorrectly checks mbuf chain size
 > >Severity:       serious
 > >Priority:       high
 > >Category:       kern
 > >Release:        FreeBSD 3.4-STABLE i386
 > >Class:          sw-bug
 > >Environment: 
 > 
 > FreeBSD-3.4-STABLE or FreeBSD-4.0 current.
 > 
 > >Description: 
 > 
 > The NETISR_ARP handler arpintr() incorrectly checks m->m_len to
 > determine if we have a complete ARP packet.  It is possible to
 > have a packet spread across several mbufs in the chain.
 > 
 > While this case apparently doesn't happen with normal ethernet
 > interfaces, additional mbuf operations before ARP processing (for
 > 802.1Q Tagged VLANS, Bridged Ethernet over Frame Relay, or perhaps
 > LANE) can cause NETISR_ARP to be presented with a fragmented packet.
 > 
 > >How-To-Repeat: 
 > 
 > Run my yet-to-see-the-light-of-day VLAN improvements, it blows chunks
 > on ever inbound ARP packet.
 > 
 > >Fix: 
 > 
 > I've not only fixed the length comparisson, I've added several
 > diagnostic error messages to the handler for other out-of-the-norm
 > ARP packets.  This makes the error conditions easier to detect
 > and fix, and makes the code much more readable.
 > 
 > I've put patches for -STABLE and -CURRENT (which are actually
 > identical) online:
 > 
 >    http://www.waterspout.com/FreeBSD/arpintr-patch.current
 > 
 >    http://www.waterspout.com/FreeBSD/arpintr-patch.stable
 > 
 > If someone could perform a sanity check, and get these committed
 > before 4.0-R heads out the door, that would be ideal.
 > 
 >  - Steve
 > 
 > 
 
 
   Robert N M Watson 
 
 robert@fledge.watson.org              http://www.watson.org/~robert/
 PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
 TIS Labs at Network Associates, Safeport Network Services