Panic in 5.3, related to network traffic

[Sebastian Schulze Struchtrup]

>Hmm.  Odd.  The stack trace in your screen shot shows the same mbuf being
>passed to icmp_error() was was passed to ip_forward().  This suggests,
>given the other arguments, that it's actually the call to icmp_error() on
>line 1650, not 1879.  I wonder if addr2line is getting confused.
>
It seems that this is the usual enemy of debugging: compiler optimisation.
There's actually only one call. The call in line 1650 jumps to the one 
generated by line 1879.

(line numbers don't match, because I am runnig 6-Current on this machine)

/usr/src/sys/netinet/ip_input.c:1711  (1650)
    103a:       6a 00                   push   $0x0
    103c:       6a 00                   push   $0x0
    103e:       6a 01                   push   $0x1
    1040:       6a 03                   push   $0x3
    1042:       56                      push   %esi
    1043:       e9 fa fd ff ff          jmp    e42 <ip_forward+0x1a6>

/usr/src/sys/netinet/ip_input.c:1711   (1650)
     e41:       56                      push   %esi
/usr/src/sys/netinet/ip_input.c:1940   (1879)
     e42:       e8 fc ff ff ff          call   e43 <ip_forward+0x1a7>
     e47:       eb e8                   jmp    e31 <ip_forward+0x195>


>  If you use kgdb on the kernel.debug and do:
>
>    l *icmp_error+0x191
>    l *ip_forward+0x3d1
>
>Do you get different answers?
>  
>

Maybe it would help to compile the kernel with INVARIANTS.
Then we should get a false assertion somewhere earlier and closer to the 
problem.

I assume that their is an invalid/null mbuf somewhere. It seems that 
this comes more or less directly from the inferface driver.

Just my two cents...