[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #16 from Guy Harris  ---
(In reply to zpchi004 from comment #15)
> So wireshark displays a) and b) correctly. c) and d) are wrong.

I.e., it gets it wrong in two cases where the radiotap flag bit is true.

> So wireshark displays a), b) and d) correctly. c) is wrong.

I.e., it gets it right in a case where the radiotap flag bit is false and gets
it wrong where the radiotap flag is true.

So there's *something* wrong that happens with a radiotap flag that's true -
but it doesn't *always* happen; it requires that there be other packets, of
some unknown sort, in the file.

What happens if you write out a file that includes the offending packet and all
the packets before it, but doesn't include any of the packets after it, and
then read that file?  (You should be able to do that by saving a range of
packets starting with 1 and ending with the offending packet.)

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #15 from zpchi...@yahoo.com ---
I tested 2 scenarios:

In both scenario 1 and 2, TXOP_PS_NOT_ALLOWED should be True.

scenario 1: all packets are actually beamformed and in my sniffer capture I
observe that every packet shows:
a) Radiotap header v0 -> VHT info -> TXOP_PS_NOT_ALLOWED: True
b) Radiotap header v0 -> VHT info -> Beamformed: True
c) 802.11 radio info -> TXOP_PS_NOT_ALLOWED: False
d) 802.11 radio info -> Beamformed: False

So wireshark displays a) and b) correctly. c) and d) are wrong.

scenario 2: all packets are actually NOT beamformed and in my sniffer capture I
observe that every packet shows:
a) Radiotap header v0 -> VHT info -> TXOP_PS_NOT_ALLOWED: True
b) Radiotap header v0 -> VHT info -> Beamformed: False
c) 802.11 radio info -> TXOP_PS_NOT_ALLOWED: False
d) 802.11 radio info -> Beamformed: False

So wireshark displays a), b) and d) correctly. c) is wrong.

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #14 from Guy Harris  ---
(In reply to zpchi004 from comment #13)
> seems so. I tested by saving 2 one-packet only files. Both show consistent
> "true" beamformed information.

So are there packets near the offending packet that correctly display the
"beamformed" or TXOP_PS_NOT_ALLOWED values in the "802.11 radio" header, and
that have them both "false"?

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #13 from zpchi...@yahoo.com ---
seems so. I tested by saving 2 one-packet only files. Both show consistent
"true" beamformed information.

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #12 from Guy Harris  ---
I.e., the problem only shows up when the offending packet is surrounded by
other packets.

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #11 from zpchi...@yahoo.com ---
Created attachment 16017
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=16017=edit
Radio header of beamformed packet.

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #10 from zpchi...@yahoo.com ---
After the first 3 steps, and the resulting one-packet file, with the full
contents of the packet, didn't show the problem.


Then I stripped off the payload (using the editcap cmd) to generate the radio
head only file, which does not show the problem, either (which is not a
surprise since the full packet does not show the issue anymore). I'm attaching
file anyways (beamformed_bug_radioheader.pcapng).

Thanks.

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #9 from Guy Harris  ---
(In reply to zpchi004 from comment #8)
> Hi Guy,
> 
> After i conducted the following 3 steps, the "beamformed" becomes both
> "true" in the saved file which contains only the problematic frame. That is,
> both "radiotap header" and "802.11 radio information" show beamformed as
> True.
> 
> 1. open the file containing the frame that exhibits this problem;
> 2. select that frame;
> 3. export it (and no other frames) by doing File -> Export Specified Packets,
>requesting "Specified packets only", filling in a file name, 
>and saving the file;

You didn't mention

4. run the file to which you exported that frame through the "editcap"
command-line tool that comes with Wireshark, as

editcap -s {radiotap header byte count} {file with that one frame} {new
file}

but the file is cut short after the radiotap header.

So do you mean "after I conducted the following *4* steps", with that 4th step
included, or do you mean that you did just the first 3 steps, and the resulting
one-packet file, with the full contents of the packet, didn't show the problem,
and then you stripped off the payload to generate the file to attach?

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #8 from zpchi...@yahoo.com ---
Hi Guy,

After i conducted the following 3 steps, the "beamformed" becomes both "true"
in the saved file which contains only the problematic frame. That is, both
"radiotap header" and "802.11 radio information" show beamformed as True.

1. open the file containing the frame that exhibits this problem;
2. select that frame;
3. export it (and no other frames) by doing File -> Export Specified Packets,
   requesting "Specified packets only", filling in a file name, 
   and saving the file;

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #7 from Guy Harris  ---
Can you:

open the file containing the frame that exhibits this problem;

select that frame;

export it (and no other frames) by doing File -> Export Specified Packets,
requesting "Specified packets only", filling in a file name, and saving the
file;

determine how many bytes there are in the radiotap header by looking in the
"Header length" field under "Radiotap Header";

run the file to which you exported that frame through the "editcap"
command-line tool that comes with Wireshark, as

editcap -s {radiotap header byte count} {file with that one frame} {new
file}

open that new file with Wireshark, and make sure that it contains the Radiotap
header with the frame that has the problem, that it exhibits the difference
between the values in the Radiotap header and the values in the "802.11 radio
information", and that it doesn't have anything *other* than the radiotap
header;

and attach it to this bug?  That would make debugging this problem a *lot*
easier and a *lot* less time consuming for us and for you.

If you can't do that, could you:

open the file containing the frame that exhibits this problem;

select that frame;

export the dissection of that frame (and no other frame) by doing File ->
Export Packet Dissections -> As Plain Text..., requesting "Specified packets
only" and requesting "All expanded" under "Details:", un-checking "Summary
line", filling in a file name, and saving the file;

edit that file in a text editor, and delete everything before "Radiotap Header"
and everything starting with "IEEE 802.11";

attach that text file to this bug?  That's not as good as attaching the
truncated one-packet capture file, as it wouldn't let us test the problem with
our versions of Wireshark or test any fixes to the problem, but it would, at
least, give us more information about the packet, which would also speed up the
process of debugging the problem.

(Without more information, it might be *extremely* difficult to figure out how
this is happening, and may mean we won't be able to figure that out and thus
won't be able to fix 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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #6 from zpchi...@yahoo.com ---
In my original capture log:
Although "beamformed" info are contradictory, i.e., shown as "true" and
"false",
guard interval info are consistent, i.e., "GI: long" and "short GI: false"

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #5 from zpchi...@yahoo.com ---
Created attachment 16008
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=16008=edit
screen shot of the "beamformed.pcap"

Both "Beamformed" are true.

Guard intervals are consistent:
 * Guard interval: short
 * short GI: true

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #4 from Guy Harris  ---
(In reply to Guy Harris from comment #3)
> Try reading the attached capture file with the same version of Wireshark.  I
> stripped out all the actual packet data, so it will get a "Packet size
> limited during capture" notification, but it has all the radiotap
> information, with "beamformed" true.
> 
> Let us know whether it shows it as true or false, in both the radiotap
> section and the "802.11 radio information" section.

And "Short GI" as well - that's also set, and would probably show the same
problem.

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

Guy Harris  changed:

   What|Removed |Added

   Hardware|x86 |x86-64

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

Guy Harris  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |INCOMPLETE

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #3 from Guy Harris  ---
Created attachment 16007
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=16007=edit
Radiotap header with the VHT beam formed flag set

I don't see any obvious way the code paths for analyzing radiotap and passing
information to the "802.11 radio information" dissector, or dissecting the
"802.11 radio information", that would cause this behavior, so I'm wondering
whether there's some issue with the C compiler in Microsoft Visual Studio such
that the generated code always sets the bitfields passed to the "802.11 radio
information" dissector for the VHT flags to 0, regardless of whether the
radiotap flag is set or not; that would explain why both of the set flags are
shown as not set at the "802.11 radio information" layer.

Try reading the attached capture file with the same version of Wireshark.  I
stripped out all the actual packet data, so it will get a "Packet size limited
during capture" notification, but it has all the radiotap information, with
"beamformed" true.

Let us know whether it shows it as true or false, in both the radiotap section
and the "802.11 radio information" section.

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #2 from Guy Harris  ---
It's also misreporting TXOP_PS_NOT_ALLOWED.

-- 
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 14266] In a WiFi capture log, the 11ac “beamformed” bit is shown as both “true” and “false”

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14266

--- Comment #1 from Guy Harris  ---
So Radiotap shows it as true and the common radio layer shows it as false.  The
"Known VHT information" field has the value 0x1ff.

-- 
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