Bug 14183

Upon receiving broadcast IP packets, such as DHCP or ping 10.1.2.255
packets, the bridge frequently forwards the packets with the ip_len,
ip_id, and ip_off fields in host order.

The problem is because the received packet is store in an mbuf
cluster, and bdg_forward() (in net/bridge.c) calls m_copypacket() to
duplicate the mbuf cluster.  The copy of the mbuf goes out to an
outgoing interface, and the original mbuf up to the local IP stack.
Since m_copypacket() does not copy the external storage of the mbuf,
it is possible that the local IP stack modifies the external storage
while a copy of the mbuf is still pending in the interface output
queue.

The problem affects broadcast and multicast IP packets.  I noticed the
problem when DHCP address request operation works only intermittenly.
It would also affects the operations of RIP, etc.

Fix: 

Provide a function similar to m_copypacket() that allocates a new
external storage, rather than just referencing the external storage of
the source mbuf cluster.
How-To-Repeat: 
Configure a FreeBSD system with options BRIDGE.  Let it bridge between
two LAN segments.  On one side, have a system ping to the broadcast
address.  On the other side, run tcpdump.  Frequently tcpdump will
report a "truncated-ip" packet.  This is because the ip_len field is
not in network order.