When using the em driver, any packets sent that use TCP segmentation
offload (TSO) and that are captured through the Berkeley Packet Filter
(BPF) will have a packet length of zero.  This affects many applications,
e.g. iftop shows zero upload bandwidth, tcpdump reports "IP bad-len 0".
The same problem may affect network drivers other than em, but this has
not been tested.

Fix: 

A trivial workaround is,
ifconfig emX -tso
but this clearly removes the benefits provided by TSO.

There seems to be many possible solutions:

1) em should massage the data supplied to bpf to pretend one large
   packet was sent
2) em should massage the data supplied to bpf to supply data as it is
   assumed the hardware will segment it
3) BPF should detect TSO packets, and massage the data to supply a
   valid length
4) BPF clients should detect TSO packets and behave accordingly
5) BPF and TSO are mutually incompatible, and BPF should disable/
   re-enable TSO when starting/stopping a capture
6) BPF and TSO are mutually incompatible, and BPF clients should emit
   a warning where appropriate
7) BPS and TSO are mutually incompatible, users should know this, and
   nothing need be done

Which of these is most appropriate seems to depend on where BPF sits,
conceptually, within the stack: whether it's supposed to report what
the upper layers supply to the interface driver, what actually comes
out of the physical interface, or something in between; and how much
effort it appropriate to make to supply the 'correct' data for this
location to BPF clients.