On Apr 12, 2016, at 6:27 PM, Yang Luo <hsluoyb@xxxxxxxxx> wrote:
> The even I don't switch on Monitor Mode,
Monitor mode is off, but you're getting 802.11 headers?
So which of these modes are you operating in? Extensible Access Point (ExtAP) Operation Mode, Extensible Station (ExtSTA) Operation Mode, or Network Monitor (NetMon) Operation Mode?
https://msdn.microsoft.com/en-us/library/ff560671(v=vs.85).aspx
> all 802.11 data packets captured by Wireshark are all WRONG (shown as "Malformed Packet").
> The capture is:
> https://github.com/nmap/npcap/releases/download/v0.06-r15/npcap_data_error_with_fcs.pcapng.gz
>
> So I'm afraid forcing Flags on is not a good solution.
Then force it off if you're not running in Network Monitor Operation Mode and on if you are.
> Then I just don't provide the radiotap Flags by commenting all the above code. Surprisingly, I still see the "Malformed Packet" error.
Why is that a surprise? I didn't say that doing so would fix the problem. All it does is, *IF* there is no guarantee that, in monitor mode, you will always have the FCS - for example, if some drivers supply it and some drivers don't - the 802.11 preference "Assume frames have FCS" will work, so that, *if* the packets in a capture file all have an FCS, the user would turn the preference on for that capture file, and *if* they don't, the user would turn the preference off for that capture file.
If you turn the preference on, then...
> See the following capture file: (like Frame 18)
> https://github.com/nmap/npcap/releases/download/v0.06-r15/npcap_beacon_error_without_flags.pcapng.gz
frame 18 of that file dissects correctly.
> So I think this error is not caused by FCS?
No, it's caused by the presence of an FCS; you somehow need to convince Wireshark of that.
Try forcing the "FCS at end" flag on only if WinPcap has been told to run in monitor mode.
You *are* controlling monitor mode based on whether pcap_set_rfmon_mode() was called before pcap_activate(), right? If not, you should do so.
> But is it possible to change the Radiotap protocol standard?
Yes. The interpretation of *existing* fields can't be changed in an incompatible fashion, but *new* fields can be added (and they have been added, for example the VHT field for 802.11ac).
> I thought it's a industrial de facto standard adopted by many companies and open-source communities? I never doubt Wireshark will follow the latest standard, but other players won't be so happy about this minor change I think.. If there is a way to propose this feature without impacting backward compatibility, it will be good.
Yes, we would add a new "Flags with presence bits" field, with a new presence bit value, and it's 2 bytes long, with a byte containing presence bits and a byte containing flag bits; the flag bits byte would be the same as with the Flags field, and the presence bits indicates which of the bits in the flag byte actually contain a value, so, for example, the presence bits byte and flag byte could be
0 1 0 0 0 0 0 0
0 0 0 0 0 0 0 0
for a frame that didn't fail the FCS check but for which we don't know anything else, and
0 1 0 0 0 0 0 0
0 2 0 0 0 0 0 0
for a frame that did fail the FCS check but for which we don't know anything else.