Re: why I'm capturing packets larger than MTU size

[Guy Harris <guy () alum mit edu>]

On Feb 23, 2012, at 9:23 AM, Andriy Tylychko wrote:

> Yeah, seems you're right. After upgrading to libpcap 1.2.1 I see failed
> sends only on packets with size of 1518 bytes, before that (with default
> libpcap 0.8 from Debian repository) I saw packets of >2000 bytes.
>
> Why I cannot send such packets (of 1518 bytes) by pcap_sendpacket()?

Are the last 4 bytes of the frame the Ethernet FCS?  A top-of-trunk build of Wireshark should indicate that (a while 
ago, somebody broke the FCS-detection heuristics in Wireshark, so I'm not sure whether the current 1.4 or 1.6 versions 
will indicate that).  In addition, if you never see any packet shorter than 64 bytes - no 60-byte packets, for example, 
other than packets *transmitted* by the host - that's an other indication that the packets you're seeing include the 
FCS.

If so, then you probably want to, for *ALL* packets other than those sent by the host doing the capturing, reduce the 
packet length by 4, because the output path on Linux probably does not expect to be handed packets that include an FCS 
(and probably cannot be configured to do so), and are rejecting maximum-length Ethernet packets because their length, 
which would be 1518 bytes with the FCS (14 bytes of header, 1500 bytes of payload, 4 bytes of FCS), is greater than the 
maximum packet-size-without-FCS (1514).  Shorter packets are probably just being sent with an extra 4 bytes of junk, 
corresponding to the captured FCS value, at the end - the adapter will append a real FCS field to that.  Most protocols 
running over Ethernet-with-a-type-field contain a length field, and all packets running over 
Ethernet-with-a-length-field contain a length field, so the 4 bytes of junk will be interpreted as padding, but some 
protocols might get confused by that.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.