Are there known cases where captures from stream-based protocols (such as TCP) have a captured length which is smaller than the original length? asked 04 Jul '14, 04:14  Lekensteyn |
2 Answers:
There are known cases where captures of any sort will have link-layer packets where not all the data is captured:
answered 04 Jul '14, 12:47  Guy Harris ♦♦ |
Yes, if you force the capture process to do that, e.g. to conserve disk space or increase capture performance. Otherwise no, it should be the same size. answered 04 Jul '14, 05:33  Jasper ♦♦ How likely is this going to happen? The upper limit for pcapng is 64 KiB afaik, even if an IP segment is 10 KiB, this will never be reached. I am trying to find out in what ways dissector break when (04 Jul '14, 05:39) Lekensteyn I'm not sure what you are after but I beleve it is quite common to capture with a snap lenght of 96 or something like that to cut off payload data from TCP if you are only looking for TCP performance issues. It also takes care of privacy issues with the payload data and makes it easier to anonymizise the capture data should that be required. (04 Jul '14, 05:56) Anders ♦ Packets can reach (and sometimes even go beyond) 64k, when the capture is done on a local system and segment offloading is active. The capture will record unsegmented payloads, which can exceed 10k easily. It happens a lot, since many people capture locally. (04 Jul '14, 06:05) Jasper ♦♦
The pcap file format has a limit of 4 GiB, due to the length fields being 32-bit; the pcap-ng file format has a block length limit of 4 GiB, due to the block length field being 32-bit, so the upper limit on the amount of packet data is slightly less than 4 GiB. Older versions of libpcap and Wireshark imposed a separate limit of 65535 bytes; the current trunk libpcap and Wireshark impose a limit of 256 KiB. (04 Jul '14, 12:53) Guy Harris ♦♦ Anders, while trying to improve handling of non-zero dissector return values (https://code.wireshark.org/review/2837/), I encountered the problem of captured vs reported length. This made me wonder how it should be handled. When deliberately cutting off packets at such small sizes, it doesn't really make sense to perform higher-layer dissection, does it? (04 Jul '14, 15:07) Lekensteyn No, but how much dissection should be done on the packets? A snapshot length won't necessarily stop at a protocol boundary, and, in addition, at least back in the "tcpdump defaults to a short snapshot length" days, a capture made by a user for the benefit of a vendor trying to debug a problem may have been unintentionally cut off at a snapshot length to the extent that the capture isn't useful, and explicitly saying "oops, sorry, there isn't enough packet data to dissect the {NFS,SMB,AFP,whatever{ traffic" can be useful (I speak from direct experience here). (04 Jul '14, 17:23) Guy Harris ♦♦ showing 5 of 6 show 1 more comments |
Yes, I know this, I was looking for actual limits that are easily hit. How likely is it to encounter such truncated captures in the wild? How likely is it to hit the limit when capturing without changing default settings?
It's less likely than it used to be in the "tcpdump defaults to a short snapshot length" days; it was common enough to be annoying back in those days (speaking as a developer on server and client software for various remote file access protocols).
The default settings for Wireshark have been "full packet" for a long time now; the default settings for tcpdump changed to "full packet" a few years ago; I think most other sniffers default to "full packet", although at least one QA person at a former employer reported a problem and attached a snapshotted capture (I eventually ended up hacking Wireshark to do enough TCP reassembly to show that he was assuming that one TCP segment would contain only one SMB request, and closed the bug).