Wireshark Capture with TSO enabled maxes out at 261478 bytes, dropping data.

TSO
261478

asked 2025-02-24 21:30:03 +0000

Hi.

I'm trying to get a wireshark capture of XML data leaving a Windows VM with TSO enabled; when following the stream i'm ending up with corrupted XML data at the packet boundaries, which after some manipulation seems to highlight that data is being dropped somewhere. Currently using Wireshark 4.4.2.

When I capture the data, the bytes captured shown in the IPV4 header as a number of packets, each of length 261478 bytes, with a note that it's "reported as 0, presumed to be because of "TCP Segmentation offload" (TSO)", followed by a single packet of smaller size. I can confirm that I do deliberately have TSO enabled.

However, I can't find a way to ensure that I can capture the full data stream and keep TSO enabled: I've set the buffer to 100MB (and even 500mb) on the interface capture dialog, and had a good dig around, I can't get Wireshark to capture a packet of more than 261478 bytes, and presumably because the packet.len is 0, it doesn't know that it's dropping data.

I've tried a mixture of "following the stream" and individually reviewing the output of the packet window to see if it might be a "bug" somewhere, but the outputs are, unsuprisingly, identical.

Does this number ring a bell with anyone, and is there a way to remove the limit? I can't see the number referred to in any Wireshark manual anywhere or issue log , so feeling quite stuck !

Thanks in advance.

edit retag flag offensive close merge delete

Comments

This may be a limit in the capture library, libpcap or npcap on Windows. Wireshark cannot display what is not captured.

André ( 2025-02-24 22:13:35 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2025-02-25 09:40:20 +0000

Guy Harris
19905 ●3 ●667 ●207

The maximum snapshot length for D-Bus captures is 128MB, and that might also be the maximum snapshot length for Windows USBPcap captures.

We could make the default maximum snapshot length also be 128MB.

We cannot raise it above 2^32-1 bytes, as neither pcap nor pcapng file can handle packets larger than that (and, for pcapng, there's other overhead that would further limit it) and a snapshot length that large would cause at least some code that reads pcap and pcapng files to attempt to allocate a buffer of that size, which will probably fail on a 32-bit platform and eat up excess address space on a 64-bit platform, so that's probably not going to happen.

A larger snapshot length would require a larger in-kernel buffer for most packet capture mechanisms, so I'm not inclined to go to 128MB; perhaps 512KB would be sufficient.

edit flag offensive delete link

add a comment

answered 2025-02-24 23:27:22 +0000

johnthacker
201 ●43 ●5

updated 2025-02-24 23:33:18 +0000

Look here in the code: https://gitlab.com/wireshark/wireshar...

Also see a bit of discussion in this issue: https://gitlab.com/wireshark/wireshar...

As noted in the code "For most link-layer types, we use 262144, which is currently libpcap's MAXIMUM_SNAPLEN."

It is still the limit in libpcap: https://github.com/the-tcpdump-group/...

If you compile libpcap with a different maximum, then Wireshark's wiretap library could be compiled with a different number as well

You mention IPv4 header, so these are not IPv6 jumbograms. Does IPv4 have a mechanism for packets larger than 65535 octets? I am not sure how the IPv4 header would indicate such a thing

edit flag offensive delete link

add a comment