On Oct 21, 2013, at 10:56 AM, Ran Shenhar <ran.shenhar@xxxxxxxxx> wrote:
> I also posted a similar question on Microsoft's Analyzer forum and got the following response:
> "Was it on a wireless interface?
> Wireshark is missing dissectors for the wireless frame we use when the built-in NDIS driver captures the data.
If they mean "Wireshark doesn't handle the 802.11 radio header for Native Wi-Fi", they're mistaken. That's what epan/dissectors/packet-ieee80211-netmon.c does. I'll mention that to Paul.
> There might also be some other kinds of ETL traffic wireshark can't parse,
Wireshark doesn't handle ETL at all. Is ETL format documented somewhere?
> but the TZSP protocol is something I've seen with wireless data."
> (on http://social.technet.microsoft.com/Forums/en-US/messageanalyzer/thread/25dcf65d-0d18-4d11-b25a-a5d3aa4a81e9/)
TZSP packets show up for one of two reasons:
1) you have a pcap or pcap-ng file (*not* a .cap file in native Network Monitor format!) and the link-layer header type for the file (pcap) or interface (pcap-ng) is 128;
2) you have UDP packets going to or coming from port 37008 (0x9090).
In the latter case, the packets might not actually be TZSP packets, they might just be non-TZSP UDP packets that happen to be going to or coming from port 37008.
> With all that being said, is there a plan to fix this?
As with many things in Wireshark, there aren't plans, just "somebody decides to fix it at some point" - or nobody does.
