what will happen when Total Length field value in IPv4 header is smaller than length of ethernet frame? How will behave a device when receive that kind of frame? Device recognized frame as invalid due to inconsistency and rejected it?
Second situation, max ethernet frame length is 1518 bytes - what will happen when I extend this frame and add additional 2 bytes. Assuming that IPv4 total length match length of extended frame.
Thanks.
The value of the Total Length field in an IPv4 header must be smaller than the frame length; anything else is a sign of corruption. The IPv4 packet is the payload of the frame, so the frame length is the total packet length plus the frame header and trailer.
Related
I'm reading on this topic, and I just found that IP headers, or even TCP headers, can be of variable length.
I thought routers will use a known length, divided into segments of a known format, to do whatever they do. So, how can you know which segements of bits mean what, if the length of the header is variable?
The way I understand it, is that the Options field at the end of the header determines the total length of the header (present if the Length field value > 5). The Length field has a minimum value of 5 (no options present) and a maximum of 15. This indicates a header length from 20 bytes (5 × 32 bits) to 60 bytes (15 × 32 bits). As all other fields apart from the Options field have a fixed length, it is clear where the header ends and where a given field is supposed to be. The Option field in itself also includes a Option length field for determining the length of Option data.
I need to know what is the different between the Data sequence number of the packet and Data sequence number of the data expected in return for the TCP packets.
What is the different between them?
Is it true if i subtract them ,the result will be the packet size ?
BR
Rayan
TCP runs sequence numbers in both directions independently.
Is it true if i subtract them ,the result will be the packet size ?
No.
I have to calculate and verify checksums for IP packets (I am writing a router in C). The struct that represents an IP header has a 16 bit checksum but the total number of bits in the struct is not evenly divisible by 16 -- it is 8 bits short.
My question is this. Do I read the struct 16 bits at a time and pad the last set of bits with zeroes to calculate the checksum?
If you had the wrong number of bits, you would pad zero bits to the end of the data.
However, IP calculates over the header fields and thus always has a multiple of 16 bits on which to calculate the checksum. TCP sometimes needs an extra byte of zero at the end of the data.
http://en.wikipedia.org/wiki/IPv4_header_checksum
I am capturing packets using libpcap. I am calculating the payload size as given here
size_payload = ntohs(ip->ip_len) - (size_ip + size_tcp);
Now, for a packet, size_payload is 1228, ethernet header is 14 bytes, IP header is 20 bytes, TCP header is 32 bytes. While header.caplen and header.len are 1514 bytes. Shouldn't size_payload+size_ip+size_tcp+size_ethernet be equal to header.caplen?
Also, when I dump the same packets using tcpdump, the capture length is shown as 1514. Why do these differ? I expected ntohs(ip->ip_len) to be equal to header.caplen and header.len
EDIT
I expected ntohs(ip->ip_len) to be equal to header.caplen and header.len. But what I find is ntohs(ip->ip_len) = 1280 and header.caplen = header.len = 1514
The caplen says how much of the packet may be captured, not necessarily how much actually was. You need to compare that value with the len field.
If caplen >= len you know that you should have the entire packet contents available. Otherwise, the packet capture has been truncated.
There is possible to use very big frames with some ethernet cards. One case is 9k frames or jumbo frame and other case is super jumbo frame (as i know, up to 64k).
What is format of frame used for such huge packets?
As I know, for normal frames two formats used widely:
Preamble Start_byte dest_mac src_mac Ethertype/length Payload CRC Interframe gap
10101010x7 10101011 6 bytes 6 bytes 2 bytes 46–1500 bytes 4 bytes 12 bytes
In one case, the ethertype is used for length, and in second - for packet type. If this field is < 0x0600 (decimal 1536 bytes), this is a length; if >= 0x0600 - it is a type.
So, it looks impossible to store 9000 in this field as length. How length of jumbo and super jumbo frames is stored?
The format used for jumbos is the same. Despite this description, the Ethertype field is not normally used to store a length. Normally in the Ethertype field, you will not see a length; you will see a type. Types are specified by IANA here:
https://www.iana.org/assignments/ieee-802-numbers
Usually you'll see one of the following types from the table:
Ethertype Exp. Ethernet Description References
---------------- -------------- -------------------- ----------
2054 0806 - - ARP [IANA]
2048 0800 513 1001 Internet IP (IPv4) [IANA]
86DD IPv6 [IANA]
There are two reasons this works:
The hardware sending the packet doesn't depend on the Layer 2 length field to know the Layer 1 length.
Some Layer 3 packets such as ARP have a known size (at least, for a known combination of hardware/protocol address length, such as Ethernet/IP where it is normally used). IPv4/IPv6 packets have a length field in their own header.