2019-12-20 07:12:47 +0000 | commented answer | radiotap.mcs.format erroneously = greenfield (1) Recap sent to Apple: Idiosyncrasy to report about capturing WLAN frames with WireShark 3.0.6, 3.0.7 & now 3.2.0 on t |
2019-12-19 19:59:07 +0000 | commented answer | radiotap.mcs.format erroneously = greenfield (1) Ok. Thanks a million for that! |
2019-12-19 19:58:18 +0000 | marked best answer | radiotap.mcs.format erroneously = greenfield (1) Idiosyncrasy capturing WLAN frame Tx's between all of my AP's and all of my non-AP STA's with WireShark 3.0.6, 3.0.7 & now 3.2.0 with oldish MacBook Airport Extreme Broadcom 802.11b/a/g/n WLAN interface. None of the AP's & non-AP STA's (except possibly the MacBook itself) support Rx HT_GF preamble PPDU's. All frames within all blocks of 2 or more unicast HT, QoS Data, A-MPDU frames, except the last frame of each block, have radiotap.mcs.format = greenfield (1) which is erroneous. The last frame of each block has it right: mixed (0). Thus wlan_radio.11n.greenfield = True (erroneous) in all frames, including the last, of each block, & wlan_radio.preamble (which only appears in the 1st frame of each block) is 8 µs less than it would be for HT_MF preamble. This does not happen with blocks of 1 frame (if that makes sense) i.e. wherein a single MPDU is nevertheless processed as an A-MPDU. Just curious if anybody knows if this misconstruance could be coming from the MacBook's Airport Extreme/Broadcom 802.11a/b/g/n WLAN interface? |
2019-12-19 19:58:18 +0000 | received badge | ● Scholar (source) |
2019-12-19 17:29:10 +0000 | asked a question | radiotap.mcs.format erroneously = greenfield (1) radiotap.mcs.format erroneously = greenfield (1) Idiosyncrasy capturing WLAN frame Tx's between all of my AP's and all o |