Within a dissector, is it possible to know if the asked 16 Feb '12, 06:42  wintermut3 edited 16 Feb '12, 07:09  multipleinte... |
One Answer:
From the dissector point of view there is no difference, so no, it does not know. answered 16 Feb '12, 06:51  Jaap ♦ That is what I thought, so if I needed to know that, I would have to set a flag somewhere outside of the dissector? is that reliable? or even possible? (16 Feb '12, 06:57) wintermut3 1 I kinda doubt you can do it at all, since Wireshark does not capture frames. Instead, it runs an additional executable called "dumpcap" that writes the incoming frames to file, which is then loaded and decoded "on the fly" by Wireshark. So basically Wireshark always reads from pcap, never from the NIC. (16 Feb '12, 09:42) Jasper ♦♦ Ah, that makes sense, so those "on the fly" frames very well may not be sent to the dissector in any standard order?... which is the behavior I have seen from directly reading a pcap file as well--understandable behavior by Wireshark as a dissector is not meant anything other than decoding--now if I can I can just get "Them" to understand that... (16 Feb '12, 20:01) wintermut3 The order in which packets appear in a file captured by any program using libpcap/WinPcap, whether it's dumpcap (whether run by the user or by Wireshark or TShark) or tcpdump or..., is the order in which they're delivered to libpcap/WinPcap by the OS. This is not guaranteed to be the order in which they arrive on the machine; the OS might deliver them out of order. Precision Time Protocol packets are sent over UDP, which makes no guarantee of delivery at all, much less any guarantee of in-order delivery. (17 Feb '12, 02:13) Guy Harris ♦♦ |
Why do you need to know? The protocol understood by your dissector shouldn't care how the bits get to it --whether it be from a pcap file, a live capture, the fuzz-tester, or somebody's fancy random number generator usb dongle that they've hooked up to Wireshark. The source of data (within Wireshark) should have no impact on how it is decoded.
When the data reaches your dissector, it is totally frozen, and could have come from anywhere.
a requirement--I am having to detect and flag PTP V2 sequence ids that or out of order of packets (based on capture time that are of the same message_id. since the order the dissector receives the packets seems to vary (especially in the case of a pcap file) I know this is outside of the scope and intent of a dissector, but I need to either find a way to do it, or explain to them why this can't be done. I need to know the origin so I can decide to track and sort the order--something I don't think I need to do, or want to do in the case of a stream--the stream should be in the right order, yes?