This is our old Q&A Site. Please post any new questions and answers at


I'm looking at a problem with communication to a new Kafka server in our environment and have a capture of the comms between the two hosts. The sending host sends a request:

sudo /tmp/kafka_2.10- --broker-list kafka-012:9092 --topic test

Which results in a failure response that I don't think it network related but when digging into the capture I noticed something that I am unsure about.

The TCP handshake is established as normal and the sending server, 01, sends a PSH,ACK that is successfully received by kafka server. The corresponding ACK when sent is 432 bits in size but the frame received by 01 is 480 bits in size. I can't see why this might be from the capture output, can anybody give any clues please?

Many thanks,


asked 13 Jul '15, 03:21

alienbob's gravatar image

accept rate: 0%

What does a Statistics -> Comments Summary show on each side. are the traces using the same encapsulation?

(13 Jul '15, 04:16) mrEEde

Both were Ethernet encapsulation.

(16 Jul '15, 05:30) alienbob

As Jaap indicated, the frame as captured on the machine that sent it is 432 bits = 432/8 bytes = 54 bytes, whereas the same frame, as captured on the machine that received it, is 480 bits = 480/8 bytes = 60 bytes.

A TCP frame with no TCP payload, and no TCP or IP options, sent over IPv4 over Ethernet, has a 14-byte Ethernet header, a 20-byte IPv4 header, and a 20-byte TCP header, for a total of 54 bytes.

If you're capturing on the machine that sends the packet, that 54-byte packet is "wrapped around" inside the OS networking stack and handed to the packet capture mechanism that libpcap/WinPcap (as used by Wireshark) uses to capture packets, so it sees a 54-byte packet.

When it's transmitted on the Ethernet, however, it must be padded to a minimum of 60 bytes, and have a 4-byte CRC appended to it. Therefore, when it's received, a 54-byte frame would be 64 bytes long, including the CRC.

Most drivers and capture mechanisms won't provide the CRC, so the frame, as provided to libpcap/WinPcap by the capture mechanism, will be 60 bytes long on any machine other than the machine that sent it.

permanent link

answered 13 Jul '15, 10:27

Guy%20Harris's gravatar image

Guy Harris ♦♦
accept rate: 19%

Thanks, all for the snappy responses sorry it took a while to respond. yes, that appears to be exactly the reason, as each is a 0 length packet that makes perfect sense and looking through further packets the same applies in both directions!

(16 Jul '15, 05:29) alienbob

Possible explanation:

  • 480 / 8 = 60 bytes
  • 60 bytes + 4 byte CRC = 64 bytes
  • Minimum Ethernet frame size = 64 bytes, of which you see 60 bytes, as the NIC strips the CRC.

So you would see some padding at the end of the frame?

permanent link

answered 13 Jul '15, 04:26

Jaap's gravatar image

Jaap ♦
accept rate: 14%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 13 Jul '15, 03:21

question was seen: 4,408 times

last updated: 16 Jul '15, 05:30

p​o​w​e​r​e​d by O​S​Q​A