[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #27 from Guy Harris --- By the way, is there some form of specification for the peekremote protocol? -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #26 from Guy Harris --- (In reply to Alexis La Goutte from comment #25) > (In reply to Nicolas Darchis from comment #23) > > is it a go for inclusion in the main code ? > > it is available on master branch, it will be available on next major release > (3.4) So if it's already *in* the master branch, that means it was deemed OK for inclusion, I guess -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 Alexis La Goutte changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #25 from Alexis La Goutte --- (In reply to Nicolas Darchis from comment #23) > is it a go for inclusion in the main code ? it is available on master branch, it will be available on next major release (3.4) -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #24 from Guy Harris --- (In reply to Nicolas Darchis from comment #23) > is it a go for inclusion in the main code ? What's the URL of the change to be included? -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #23 from Nicolas Darchis --- is it a go for inclusion in the main code ? -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #22 from Gerrit Code Review --- Change 36686 merged by Anders Broman: Peekremote : modified the peekremote dissector to support 11ax https://code.wireshark.org/review/36686 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #21 from Gerrit Code Review --- Change 35238 merged by Guy Harris: wtap: Add support for 802.11ah and 802.11ax PHYs. https://code.wireshark.org/review/35238 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #20 from Gerrit Code Review --- Change 35238 had a related patch set uploaded by Guy Harris: wtap: Add support for 802.11ah and 802.11ax PHYs. https://code.wireshark.org/review/35238 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #18 from Gerrit Code Review --- Change 35237 had a related patch set uploaded by Guy Harris: wtap: Add support for 802.11ah and 802.11ax PHYs. https://code.wireshark.org/review/35237 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #19 from Gerrit Code Review --- Change 35237 merged by Guy Harris: wtap: Add support for 802.11ah and 802.11ax PHYs. https://code.wireshark.org/review/35237 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 Guy Harris changed: What|Removed |Added Status|INCOMPLETE |CONFIRMED --- Comment #17 from Guy Harris --- (In reply to Nicolas Darchis from comment #0) > The PEEKREMOTE dissector does not support 802.11ax currently. > In Cisco WLC 8.9 software, APs in sniffer mode can sniffer 802.11ax and send > it on the wire as peekremote-encapsulated. > > I have coded the changes in packet-peekremote.c to support the new flags in > peekremote header for 802.11ax support. > However, we can see this variable set for 802.11ac frames "phdr.phy = > PHDR_802_11_PHY_11AC". > This points to packet-ieee80211-radiotap where these are used as well. > It doesn't seem that the 11AX PHY is supported at a radiotap header in the > latest wireshark code, but i've seen existing bugs about that, so not sure > what's currently in the works or not ? Support in the *radiotap* header is not necessary for support with other metadata headers; the 802.11 pseudo header is not obliged to strictly track the radiotap header. We now have PHDR_802_11_PHY_11AX, which is reported as "802.11ax (HE)" in the tip of the master branch. Please submit any additional changes needed; if the pseudo-header is changed, but doesn't provide enough data for radiotap as a result, we'll just further change the pseudo-header - this stuff isn't targeted for 3.2 at this point, so it'll be in 3.4, and we have plenty of time to change it. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #16 from Guy Harris --- (In reply to Richard Sharpe from comment #14) > Here is a comment from Johannes Berg about this: > > - > Reading that discussion, I think there are just different > interpretations of the term "PHY" in use. > > I would have interpreted it like you, thinking the "PHY" is a piece of > hardware that cannot actually change. > > However, Guy et al are interpreting it like a spec term, which you can > see e.g. in comment 11: > > "Even an 11AX AP will still send the beacons using [the] 802.11a PHY at > 6mbps." > > If you read this "802.11a PHY" as meaning "as defined in the 802.11a > amendment", you can sort of see where they're coming from. > > Ultimately, PHDR_802_11_PHY_11AX does make sense, and should be set by > the radiotap code if the HE field is present. That's it. The *hardware* on my machine, a Broadcom BCM43602, is capable of handling: * the high rate direct sequence spread spectrum (HR/DSSS) PHY specification; * the orthogonal frequency division multiplexing (OFDM) PHY specification; * the extended rate PHY (ERP) specification; * the high-throughput (HT) PHY specification; * the very high throughput (VHT) PHY specification and probably even * the DSSS PHY specification for the 2.4 GHz band designated for ISM applications. Right now, it's using the extended rate PHY specification for most traffic, because that's the most the access point does. The driver's radiotap implementation reports the extended rate PHY even for 1Mb/sec beacons received from the AP, which are probably sent using the DSSS PHY specification - an AP advertising its presence has to use the oldest tiredest PHY specification that some old tired potential client might be using, so it goes back before even 802.11b. So - just as is the case for Ethernet, where an Ethernet PHY chip can handle multiple different physical layers - a given 802.11 chip can handle multiple different physical layers. Thus, "the phy for a particular interface" does not and cannot always refer to a particular physical layer for that interface, as most Ethernet and 802.11 interfaces these days can handle *multiple* physical layers; it would have to be an indication of the hardware on the chip, e.g. an option containing a string such as "Broadcom BCM43602". There could be an indication of the *set* of physical layers that the device supports, but that wouldn't be *a* physical layer. And giving only the *fastest*, or the *shiniest and newest* physical layer, that the hardware supports wouldn't tell you which physical layer or layers were actually used during the capture - my adapter can go up to 802.11ac, but it's only using 11g because that's all our AP does. > I guess the question is: > > Do we need to know the highest PHY type (SPEC version) detected on a > particular STA? Not as far as I can tell, because there is no guarantee that the highest PHY type is at all being *used*. > As Johannes says, we will only see HE elements in the radiotap header if the > packets are HE packets. Exactly. What matters for a *packet* is "which PHY was used for that packet", not "what's the fastest PHY that the interface could handle, regardless of whether it's using it right now or not?" > At the moment there is no code that uses does things differently if the STA > is an 802.11ax STA If by "802.11ax STA" you mean "a STA whose hardware/firmware/software supports the current draft of the high efficiency PHY", there is no particular reason to do anything differently if, for example, that STA were to be carried into our house and it were to associate with our network, as it'll still just be using its extended rate PHY capabilities. What might need to be done differently would be handling of *individual packets* using the high efficiency PHY; presumably, when the radio metadata is in a radiotap header, those would be packets containing the HE field: http://www.radiotap.org/fields/HE I'll check in a fix to set the phy field of the radio information pseudo-header to PHDR_802_11_PHY_11AX in the radiotap dissector if an HE field is seen, and to report PHDR_802_11_PHY_11AX as "802.11ax" in the radio metadata dissector. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 Guy Harris changed: What|Removed |Added Attachment #17092|0 |1 is obsolete|| --- Comment #15 from Guy Harris --- Created attachment 17489 --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17489&action=edit gzipped peekremote capture with 8 spatial streams on 11ax -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #14 from Richard Sharpe --- Here is a comment from Johannes Berg about this: - Reading that discussion, I think there are just different interpretations of the term "PHY" in use. I would have interpreted it like you, thinking the "PHY" is a piece of hardware that cannot actually change. However, Guy et al are interpreting it like a spec term, which you can see e.g. in comment 11: "Even an 11AX AP will still send the beacons using [the] 802.11a PHY at 6mbps." If you read this "802.11a PHY" as meaning "as defined in the 802.11a amendment", you can sort of see where they're coming from. Ultimately, PHDR_802_11_PHY_11AX does make sense, and should be set by the radiotap code if the HE field is present. -- I guess the question is: Do we need to know the highest PHY type (SPEC version) detected on a particular STA? If so, I can imagine, and have added such code elsewhere, to track things like the highest PHY type seen for a particular STA. As Johannes says, we will only see HE elements in the radiotap header if the packets are HE packets. At the moment there is no code that uses does things differently if the STA is an 802.11ax STA, however there is such a need with S1G (802.11ah). -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #13 from Gerrit Code Review --- Change 33280 merged by Alexis La Goutte: wtap: Add support for 802.11ah and 802.11ax PHYs. https://code.wireshark.org/review/33280 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #12 from Gerrit Code Review --- Change 33280 had a related patch set uploaded by Richard Sharpe: wtap: Add support for 802.11ah and 802.11ax PHYs. https://code.wireshark.org/review/33280 -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #11 from Nicolas Darchis --- (In reply to Richard Sharpe from comment #9) > Hmmm, another thought is that the PHY is not really a per-packet thing. > > Presumably the PHY cannot change. > > Maybe there should be a separate pcapng header that describes the phy for a > particular interface or a field in the interface header? Richard, the PHY is definitely per-packet. Even an 11AX AP will still send the beacons using 802.11a PHY at 6mbps. So a client station will also send its data using HE PHY and then send ACKS and other control frames using another PHY. I think PHDR_802_11_PHY_11AX has to be defined. But it seemed to me that it's more than just a definition required, as the PHDR_802_11_PHY_11AC has some handling code as well, it's not just a PHY defined. This is where I stopped because I'm unsure of the interactions with other things. Right now my modification shows that there is a 802.11ax flag in peekremote header and it shows the correct MCS rate for HE but the radio header inside is decoded like 802.11ac due to this PHDR_802_11_PHY_11AX not defined yet. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #10 from Guy Harris --- (In reply to Richard Sharpe from comment #9) > Hmmm, another thought is that the PHY is not really a per-packet thing. > > Presumably the PHY cannot change. Why not? What if, for example, you move out of the range of an AP that supports the HT PHY (11n) and into the range of an AP that only supports the OFDM (11a) or ERP (11g) PHY? -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #9 from Richard Sharpe --- Hmmm, another thought is that the PHY is not really a per-packet thing. Presumably the PHY cannot change. Maybe there should be a separate pcapng header that describes the phy for a particular interface or a field in the interface header? -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #8 from Richard Sharpe --- (In reply to Guy Harris from comment #7) > (In reply to Richard Sharpe from comment #5) > > Most likely the problem here is that the current radiotap 11AX code is > > simply not handling the phy correctly and setting it in the phdr. > > Given that there is no PHDR_802_11_PHY_11AX (or PHDR_802_11_PHY_11AY) > defined in wiretap/wtap.h, it is literally *impossible* for that code to > handle the PHY correctly and set it in the phdr. Yeah. I think we definitely need a PHDR_802_11_PHY_11AX definition and maybe also a PHDR_802_11_11AH as well (for S1G). -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #7 from Guy Harris --- (In reply to Richard Sharpe from comment #5) > Most likely the problem here is that the current radiotap 11AX code is > simply not handling the phy correctly and setting it in the phdr. Given that there is no PHDR_802_11_PHY_11AX (or PHDR_802_11_PHY_11AY) defined in wiretap/wtap.h, it is literally *impossible* for that code to handle the PHY correctly and set it in the phdr. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #6 from Richard Sharpe --- After discussing this with Johannes, it seems that what we can do is use the presence of the HE header to indicate that the PHY is an 802.11ax phy. However, if frames are captured at HT or VHT rates, and there is no HE header that might miss the fact that the PHY is an HE PHY. There will also be an S1G header in the very near future to worry about. Finally, perhaps we need a new PHY header for RADIOTAP where the capturing software can unambiguously indicate the PHY that capturing was done on. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #5 from Richard Sharpe --- (In reply to Alexis La Goutte from comment #3) > Bonjour Nicolas, > > Do you plan to push your change ? > > About radiotap header, we following spec... (if remenber the radiotap header > for 802.11ax is not yet finished) Richard can you confirm ? Well, the radiotap header definition for 11AX is mostly done. Most likely the problem here is that the current radiotap 11AX code is simply not handling the phy correctly and setting it in the phdr. I notice this field in the HE header: data Bandwidth/RU allocation (0=20, 1=40, 2=80, 3=160/80+80, 4=26-tone RU, 5=52-tone RU, 6=106-tone RU, 7=242-tone RU, 8=484-tone RU, 9=996-tone RU, 10=2x996-tone RU). -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #4 from Guy Harris --- (In reply to Nicolas Darchis from comment #0) > It doesn't seem that the 11AX PHY is supported at a radiotap header in the > latest wireshark code, but i've seen existing bugs about that, so not sure > what's currently in the works or not ? Radiotap 11ax support isn't necessary to support 11ax in other 802.11 radio metadata headers; struct ieee_802_11_phdr can have 11ax support added without radiotap support, although if radiotap support is under development, it should add that support in a fashion that could be used by the current proposed radiotap support. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 Guy Harris changed: What|Removed |Added Hardware|x86 |All -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 Alexis La Goutte changed: What|Removed |Added CC||alexis.lagou...@gmail.com, ||realrichardsha...@gmail.com Version|3.0.1 |Git Severity|Major |Enhancement OS|Mac OS X 10.4 |All Ever confirmed|0 |1 Status|UNCONFIRMED |INCOMPLETE --- Comment #3 from Alexis La Goutte --- Bonjour Nicolas, Do you plan to push your change ? About radiotap header, we following spec... (if remenber the radiotap header for 802.11ax is not yet finished) Richard can you confirm ? -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #2 from Nicolas Darchis --- Created attachment 17093 --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17093&action=edit screenshot screenshot showing the modifications : 160mhz flag added, 11ax flag added, MCS coding rates extended to 11. -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
[Wireshark-bugs] [Bug 15740] Support for 11ax in PEEKREMOTE
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15740 --- Comment #1 from Nicolas Darchis --- Created attachment 17092 --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17092&action=edit peekremote capture with 8 spatial streams on 11ax This is a sniffer trace containing packets sent at MCS 11 802.11ax -- You are receiving this mail because: You are watching all bug changes.___ Sent via:Wireshark-bugs mailing list Archives:https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
