Wireshark-users: Re: [Wireshark-users] Question regarding cap export from netsh etl using message
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 21 Oct 2013 11:32:22 -0700
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.