CODEWITHSUNDEEP
cnetwork-programmingwiresharkdpdk
kocica
kocica

Reputation: 6465

Wrong size of IPv4 packets in DPDK

I have these packets saved in pcap file (shown in wireshark)

enter image description here

Iam parsing these packets using DPDK and for some reason i cannot use mbufs. To parse them iam using struct ipv4_hdr and struct ether_hdr as following:

eth_hdr = (struct ether_hdr *) pckt;
ip_hdr = (struct ipv4_hdr *)((unsigned char *) pckt + sizeof(struct ether_hdr));

The total_length in ipv4_hdr is size of ipv4 header + size of data. With size of etherhet header it should be the total length of packet, right?

size = rte_bswap16(ip_hdr->total_length) + sizeof(struct ether_hdr);

which gives me for these 6 packets output:

54, 54, 54, 54, 54, 54

For first, third and fifth packets its correct, but for the others its 6 bytes less than it should be.

Iam asking what these 6 bytes in packets are and how to find out the correct sizes using ipv4 and ether headers:

54, 60, 54, 60, 54, 60

In wireshark all of these packets has total_length 40 bytes and sizeof(ether_hdr) is 14 bytes -> it should be 54.

Upvotes: 1

Views: 1138

Answers (1)

Andriy Berestovskyy
Andriy Berestovskyy

Reputation: 8544

I guess the root cause is the minimum Ethernet frame length. As Wikipedia says, the minimum frame length is 64 bytes.

At the end of each Ethernet frame we add Frame Check Sequence (FCS, 4 octets), so it makes minimum 60 octets for Ethernet header and payload.

Now answering your questions:

I am asking what these 6 bytes in packets

Those are zero paddings to make ethernet frame (with FCS) at least 64 octets.

For outgoing packets, there are no paddings yet, they will be added later by the driver or NIC itself. So Wireshark shows unpadded frames, i.e. 40 bytes of IP + 14 bytes of Ethernet header (without FCS) makes 54 bytes.

For incoming packets, there are already paddings added by the sending part. So Wireshark shows frames with padding, i.e. 64 octets - 4 octets FCS = 60 octets.

how to find out the correct sizes using ipv4 and ether headers

Your method is completely correct. Those zeros at the end of the frame are just padding and should be ignored. If we really need a correct length, we should take into account the minimum frame length as described above.

Upvotes: 4

Related Questions