Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Packet Index, Packet Data] Pair do not match what is seen in Wireshark form Exported PCap file. #158

Open
3 tasks done
stellarpower opened this issue Aug 16, 2023 · 0 comments

Comments

@stellarpower
Copy link

Prerequisites

Please verify these before submitting an issue.

  • I am running the latest versions of Termshark and Wireshark.
    • Wireshark 4.0.3 (latest available in Lunar repos)
    • Termshark 2.4.0 (tarball from releases page)
  • I checked the README and User Guide and found no answer
  • I searched issues and this has not yet been filed

Problem

It looks to me that I am experiencing is an issue with the packet contents, compared with the packet index, as shown in the UI - the two are not tallying up in the same way as they do in Wireshark.

Apologies, but as the data here is sensitive, I can't upload, so this is going to be a bit non-descript. I could prepare an MRE but without knowing what is the likely cause not sure how to go about this.

I am capturing packets from the USB bus. I have noticed some data that looks odd, and began exporting the PCAP files using the wormhole command available in the menu, and analysing in the Wireshark GUI offline on my local machine.

At this point I noticed that Termshark was displaying data that made no sense. It seems from this screenshot, that there is an off-by-one sort of error with the packet payload, vs. the packet's info in the list.

For example here, you can see the response for a string descriptor response (packet 277) is being displayed in the packet window for packet 279 (an interrupt response - so the fields for a string descriptor would make no sense for an interrupt transfer).

image

I originally thought this was a memory error in our embedded device, and that we were running over and sending back portions of a previous string descriptor somehow - until I realised that the whole payload for 179 was identical to what I see for 277 in Wireshark. It is as if Termshark is displaying the data for packet 279 instead of packet 277, when I have 277 selected in the list of packets.

Current Behavior

Haven't refined the specifics, but the packets all appear present in the UI scrolling through, however, there appears to be a delta of two between the shown and correct payloads. Packet 1 is shown; I am not sure if correctly, so I would probably have to go all the way through and find the point where the two come out of lockstep. As the difference is two, this could perhaps be an off-by-one problem twice - one for the request packets plus one for the response packets.

Expected Behavior

Packet data should match what I see in Wireshark GUI - packet indices and payloads should be identical.

Context

Please provide the complete output of these commands:

The machine capturing:

TShark (Wireshark) 3.2.3 (Git v3.2.3 packaged as 3.2.3-1)

Copyright 1998-2020 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later <https://www.gnu.org/licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3,
with GLib 2.64.2, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with Lua
5.2.4, with GnuTLS 3.6.13 and PKCS #11 support, with Gcrypt 1.8.5, with MIT
Kerberos, with MaxMind DB resolver, with nghttp2 1.40.0, with brotli, with LZ4,
with Zstandard, with Snappy, with libxml2 2.9.10.

Running on Linux 5.4.0-72-generic, with Intel(R) Core(TM) i7-7700HQ CPU @
2.80GHz (with SSE4.2), with 15872 MB of physical memory, with locale
en_US.UTF-8, with libpcap version 1.9.1 (with TPACKET_V3), with GnuTLS 3.6.13,
with Gcrypt 1.8.5, with brotli 1.0.7, with zlib 1.2.11, binary plugins supported
(0 loaded).

Built using gcc 9.3.0.

Bodhi linux 6.0 (based on Ubuntu 20.04), AMD64

My local host running the wireshark GUI

Ubuntu 23.04 AMD64

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant