Bug 51485

	I have setup a bridge with an ipfw firewall (see attached archive for
	output of "ipfw list" (ipfw_list.txt), and other pertitnent
	configuration information).  When I do a traceroute from outside to a
	machine on the other side of the bridge (note that this also causes
	near simultaneous tcp traffic, as the output of the traceroute is sent
	across the network from outside via ssh), a trap 12 occurs on the
	bridge machine.  Here is the applicable firewall rule:
	
	02800 unreach port udp from any to 209.204.154.240/30 dst-port 33435-33524 in via sis0
	
	If I remove this rule and reboot, the bridge will run for a little
	while, then if there is some icmp traffic, the brige machine will
	appear frozen (no trap this time).  It is, however, still servicing
	interrupts, as I can switch vt's, turn numlock on/off etc, and even
	the bridge is still functioning (i.e. relaying packets), but all
	non-interrupt driven routines of the os are frozen.  I also see this
	behavior if I set the firewall to be completely open.

	I have narrowed the trap problem down to net/bridge.c::bdg_forward
	line 963.  It looks like ip_fw_chk_ptr (set to ipfw_chk in this case)
	is called just before doing "m0 = args.m;", but args.m is set NULL by
	the call to ipfw_chk.  We then get the trap when "EH_RESTORE(m0);"
	attempts to dereference m0 (see debug.txt in the attached archive for
	a log of the debugging session).  I did not attempt to debug the
	freezing problem, but it seems likely to be related.
	
	As an aside, the call to bdg_forward appears to be missing from the
	backtrace (the bt contains only the caller of bdg_forward,
	ether_input), but if you look at the eip in frame #14 "trap", you see
	that it falls within bdg_forward, which makes sense given the state of
	frame #15 (ether_input).
	
	I suspect this is an easy fix for someone who knows this code?  I
	don't know it though, and don't have the time to understand it well
	enough right now.

	I'd be happy to send the core, or post it somewhere, if someone wants
	it.

How-To-Repeat: 	Do a traceroute from a machine outside of my bridge to a machine
	inside of the bridge, via an ssh session from within the bridge to the
	machine outside of the bridge.  Use the attached firewall ruleset.
	This is 100% reproducable.