Matt Davis's profile - activity

I pulled the Wireshark code several years ago (v1.8.6) to use its TCP reassembly logic to build a custom TCP reassembler for a project I work on. I'm needing that same logic today, and I'd like to use the latest version of the code (v2.6.1) as a go-by, but I cannot find the reassemble_tcp function in follow.c.

Can anyone point me to where/how the TCP reassembly is accomplished in the Wireshark code base today?

My understanding is that a minimum layer 2 Ethernet II frame has to be 64 bytes in length, which includes the 4-byte FCS. Since the FCS is not normally available to Wireshark, only 60 bytes are shown. Thus, in a TCP packet that has an empty payload, there are 6 padding bytes at the end of the frame that are highlighted along with the Ethernet II header. So,

• 14-byte Ethernet II header
• 20-byte IPv4 header
• 20-byte TCP header
• 6-byte padding

gives the total of 60 bytes.

In my testing, I'm running across a 54-byte packet that shows no padding bytes. It has the 14-byte Ethernet II header, the 20-byte IPv4 header, and the 20-byte TCP header for a total of 54 bytes. It is the ACK packet that follows the SYN and SYN,ACK handshake.

Is there an explanation as to why this packet is 54 bytes long and not padded out to 60 bytes? Is this a network setting of some kind?

That thought actually occurred to me on the drive home. lol.

TCP ACK shows only 54 bytes in Wireshark My understanding is that a minimum layer 2 Ethernet II frame has to be 64 bytes

TCP ACK shows only 54 bytes in Wireshark My understanding is that a minimum layer 2 Ethernet II frame has to be 64 bytes

As far as I can tell, WinPcap 4.1.3 is the final released version. Is that correct? Is it still being supported at all? By all appearances, it seems to still work on Windows 10, but I worry about the future if it isn't being actively maintained.

Am I correct in my understanding that npcap is a viable alternative and is still being developed?

Is WinPcap still being developed? As far as I can tell, WinPcap 4.1.3 is the final released version. Is that correct?

I ran a packet capture overnight to test. There is a single pcapng file with a size of 2.9GB, and it has over 2.7 milli

What does ring buffer do "create new" options aren't specified? In the 2.6.2 version of Wireshark (and I think recent ve

What does ring buffer do "create new" options aren't specified? In the 2.6.2 version of Wireshark (and I think recent ve

Guy, thank you. I was hoping you'd chime in on this. That definitely helps.

What happened to reassemble_tcp? I pulled the Wireshark code several years ago (v1.8.6) to use its TCP reassembly logic

Thanks, @Guy Harris.

I'm trying to solidify some things in my head.

Wikipedia indicates that a SNAP extension is in use if the DSAP and SSAP values in the IEEE 802.3 header are 0xAA or 0xAB. The Network Sorcery page indicates that only 0xAA indicates a SNAP extension, and this seems to be confirmed by Wireshark 2.4.2. If either of the DSAP/SSAP values are 0xAB, Wireshark does not process the upper layer as the specified protocol (e.g., CDP, PAgP, etc.), but instead treats it as a data block.

Assuming that the DSAP and SSAP values are both 0xAA (indicating the SNAP extension is in use), if the Control field in the IEEE 802.3 LLC header is anything other than 0x03, Wireshark breaks out the LLC/SNAP header correctly, but it treats the upper layer as a data block, not the specified protocol.

1. For LLC/SNAP, is it required for the SAPs to be 0xAA or can either/both be 0xAB? Perhaps this was once the case and is no longer used in practice?
2. Is it required for the Control field to be 0x03, or can it be a 1- or 2-byte variety? Perhaps this was once the case and is no long used in practice?

What is a valid LLC SNAP indicator? I'm trying to solidify some things in my head. Wikipedia indicates that a SNAP exte

What is a valid LLC SNAP indicator? I'm trying to solidify some things in my head. Wikipedia indicates that a SNAP exte