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.
