On Jun 19, 2011, at 5:13 PM, Andrej van der Zee wrote:
> That sounds promising, I will go for pcap-format with raw IP
> encapsulation. To start with, how do I discard nettl/Ethernet headers?
> Should I use tshark and text2pcap, manually removing the headers in
> ASCII, or is there a better way?
If you're willing to modify editcap, you could try making a special modified version of it that maps WTAP_ENCAP_NETTL_RAW_IP and WTAP_ENCAP_NETTL_ETHERNET to WTAP_ENCAP_RAW_IP, and, for WTAP_ENCAP_NETTL_ETHERNET packets, discards non-IP packets (don't write them out) and strips off the first 14 bytes of packet data.
> Finally, where is this for: "discarding packets with a length field
> rather than a linktype"?
In the original DEC/Intel/Xerox Ethernet specification, the Ethernet header had a 6-octet destination address, a 6-octet source address, and a 2-octet type field. The IEEE 802.3 standard replaced the type field with a length field, giving the actual packet length (not including any padding); the largest possible packet length was less than the smallest possible type value, so a receiver could determine whether the field was a type or length field by looking at the value. Eventually, the 802.3 standard admitted that the Ethertype field wasn't going to go away, and allowed both. To quote IEEE Std 802.3-2000:
3.2.6 Length/Type field
This two-octet field takes one of two meanings, depending on its numeric value. For numerical evaluation, the first octet is the most significant octet of this field.
a) If the value of this field is less than or equal to the value of maxValidFrame (as specified in 4.2.7.1), then the Length/Type field indicates the number of MAC client data octets contained in the subsequent data field of the frame (Length interpretation).
b) If the value of this field is greater than or equal to 1536 decimal (equal to 0600 hexadecimal), then 14
the Length/Type field indicates the nature of the MAC client protocol (Type interpretation). The Length and Type interpretations of this field are mutually exclusive.
When used as a Type field, it is the responsibility of the MAC client to ensure that the MAC client operates properly when the MAC sublayer pads the supplied data, as discussed in 3.2.7.
Regardless of the interpretation of the Length/Type field, if the length of the data field is less than the mini- mum required for proper operation of the protocol, a PAD field (a sequence of octets) will be added at the end of the data field but prior to the FCS field, specified below. The procedure that determines the size of the PAD field is specified in 4.2.8. The Length/Type field is transmitted and received with the high order octet first.
maxValidFrame is 1500. (And, yes, this means that values of the length/type field between 1501 and 1535 are, apparently, illegal.)
In theory, IP could be encapsulated in a frame with a length field, either using the DSAP and SSAP value for IP in the 802.2 header that follows the 802.3 header or using SNAP. In practice, that doesn't happen (unless something blindly bridges IP-over-SNAP frames from some other link-layer type on to Ethernet, but I don't know whether anything does that).