I suspect that IP_HDRINCL was added to support traceroute, that
both it and traceroute were written on a big-endian machine, and that
all is 'ok' until now because traceroute indeed supplies
host-byte-order lengths.

Your fix makes lots of sense, but I suspect you have to fix traceroute
as well.

Another thing that should get fixed is that somewhere (raw_ip?
fragment code?) a check should be made for (mbuf_len >= ip->ip_len) 
before the m_copym is called; this should have been dropped packets,
not a panic.

I don't know if this is checked for packets that are to be forwarded;
presumably packets generated by the kernel code can be trusted.
Another source is IP_HDRINCL; I don't know if there are more sources
of 'raw'ish ip packets whose header length cannot be trusted to
reflect the actual packet (mbuf content) length.

        Greg Troxel <gdt@bbn.com>