calculate TCP payload slice sizes for Ethernet II packets less than 64 octets

[joekiller]

Calculate TCP payload slice sizes for Ethernet II packets less than 64 octets and fix #325.

[buger]

Maybe we just should ignore runt packets? Anyway they are caused by collisions and bugs.

[joekiller]

I guess it depends on what the shortest http request can be and the size
payload that would be. If it is always >60 bytes (4 bytes are checksum)
then we can safely ignore runts. Almost all the transmission i see under 64
are handshake and acks.
On Jul 2, 2016 12:05 PM, "Leonid Bugaev" [email protected] wrote:

Should not we just ignore runt packets?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#326 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AA-bxyp18v95E5bWZ0h9j88aOpFhwDm8ks5qRow4gaJpZM4JDZT6
.

[joekiller]

I don't think these are technically runt frames as runts are < 64 bytes and these are properly formed, just padded. So I think my jargon was incorrect.

[joekiller]

I'll update the issues to say dealing with padded frames instead of runts.

[joekiller]

I'm unsure if we can really drop padded frames because they could be a fragmented request right? It's quite an edge case but we could have real data instead of just padding.

Ethernet II frames have a minimum size of 64 octets where 4 octets are CRC Checksum so only 60 octets are valid data. A TCP/IP communication over Ethernet takes 54 bytes (calculator) which leaves 6 bytes for data.

The smallest HTTP request is 20 bytes:

GET / HTTP/1.1 \r\n
\r\n

But we could get a case where the request is fragmented so a request could be part of a padded payload.

[buger]

When dealing with Encoding: chunked, the smallest valid packet is: 0\r\n\r\n which is 5 bytes.

[joekiller]

Right so that could have a size of 59 bytes with one padded zero.

[joekiller]

BTW for those that read this in the future, we are using bytes and octets interchangeably. So for our conversation 1 byte = 8 bits = 1 octet. https://en.wikipedia.org/wiki/Octet_(computing)

[buger]

I'm right that the formula above can be simplified to: int(binary.BigEndian.Uint16(data[2:4])) ?:)

[joekiller]

Yeah I think you are right. I'll trim that down.

[joekiller]

So we are trying to calculate the actual end of the data packet (E) that is in a padded envelope minus the header. IL is IP Envelope length. So
E = IL + pad
IL = E - pad

So data = data[ihl * 4: int(binary.BigEndian.Uint16(data[2:4]))]

[buger]

I still can't find information about padded frames which are valid, only about runt ones, which can be safely ignored.

[joekiller]

How about here https://www.ietf.org/rfc/rfc1042.txt

IEEE 802 packets may have a minimum size restriction. When
necessary, the data field should be padded (with octets of zero)
to meet the IEEE 802 minimum frame size requirements. This
padding is not part of the IP datagram and is not included in the
total length field of the IP header.

[joekiller]

sometimes I think the padding is implied by the minimum length.

[joekiller]

Okay padding is part of IEEE 802.3 standard and here are the relevant citations. Section 3 is Media Access Control (MAC) frame and packet specifications for the standard.

3.1.1 Packet format

Figure 3–1 shows the fields of a packet: the Preamble, Start Frame Delimiter (SFD), the addresses of the MAC frame’s destination and source, a length or type field to indicate the length or protocol type of the following field that contains the MAC client data, a field that contains padding if required, and the Frame Check Sequence (FCS) field containing a cyclic redundancy check value to detect errors in a received MAC frame. An Extension field is added, if required (for 1000 Mb/s half duplex operation only). Of these fields, all are of fixed size except for the MAC Client Data, Pad and Extension fields, which may contain an integer number of octets between the minimum and maximum values that are determined by the specific implementation of the MAC. See 4.4 for particular MAC parameters.

The minimum and maximum MAC frame size limits in 4.4 refer to that portion of the packet from the dEstination Address field through the Frame Check Sequence field, inclusive (i.e., the MAC frame). Relative to Figure 3–1, the octets of a packet are transmitted from top to bottom, and the bits of each octet are transmitted from left to right.

next up 3.2.6:

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 1500 decimal (05DC hexadecimal), then the Length/Type field indicates the number of MAC client data octets contained in the subsequent MAC Client Data field of the basic frame (Length interpretation).

b) If the value of this field is greater than or equal to 1536 decimal (0600 hexadecimal), then the Length/Type field indicates the Ethertype of the MAC client protocol (Type interpretation).22 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 MAC Client data, as discussed in 3.2.7.

Regardless of the interpretation of the Length/Type field, if the length of the MAC Client Data field is less than the minimum required for proper operation of the protocol, a Pad field (a sequence of octets) will be added after the MAC Client 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.

NOTE—Clause 2 of IEEE Std 802 defines a set of Ethertype values and associated mechanisms for use in prototype and
vendor-specific protocol development.

and

3.2.8 Pad field

A minimum MAC frame size is required for correct CSMA/CD protocol operation (see 4.2.3.3 and 4.4). If necessary, a Pad field (in units of octets) is appended after the MAC Client Data field prior to calculating and appending the FCS field. The size of the Pad, if any, is determined by the size of the MAC Client Data field supplied by the MAC client and the minimum MAC frame size and address size MAC parameters (see 4.4).

The length of the Pad field required for MAC Client Data that is clientDatasize/8 octets long is max [0, minFrameSize – (clientDatasize + 2 × addressSize + 48)] bits.

[joekiller]

feel free the squash

[buger]

Thank you for the detailed PR!