subject:"\[Wireshark\-bugs\] \[Bug 14266\] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in \"802.11 radio\""

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2018-01-10 Thread bugzilla-daemon

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

Guy Harris  changed:

   What|Removed |Added

 Status|INCOMPLETE  |RESOLVED
 Resolution|--- |FIXED

--- Comment #30 from Guy Harris  ---
(In reply to Guy Harris from comment #29)
> (In reply to zpchi004 from comment #28)
> > Yes. It didn't work with 2.4.2, but does work with 2.4.3.
> 
> There is no change between the 2.4.2 and 2.4.3 code that would obviously
> have fixed this bug.

But there is a change that isn't obviously a fix but that I suspect is, in
practice, a fix, as the code is a bit complicated, and could have been
dissecting random crap rather than the information passed to it from the
radiotap dissector.

I think https://code.wireshark.org/review/23521, in the master branch, fixed
this; it was backported to the 2.4 branch.

-- 
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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2018-01-09 Thread bugzilla-daemon

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

--- Comment #29 from Guy Harris  ---
(In reply to zpchi004 from comment #28)
> Yes. It didn't work with 2.4.2, but does work with 2.4.3.

There is no change between the 2.4.2 and 2.4.3 code that would obviously have
fixed this bug.  The radiotap dissector wasn't even changed between 2.4.2 and
2.4.3; the "802.11 radio information" dissector was changed, but not in any way
that would obviously have affected this.

Perhaps either 1) there's a compiler bug that the 2.4.2 code stumbles across
but the 2.4.3 code doesn't or 2) there's an underlying bug in the code and some
of the changes in 2.4.3 hide 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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2018-01-09 Thread bugzilla-daemon

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

--- Comment #28 from zpchi...@yahoo.com ---
Yes. It didn't work with 2.4.2, but does work with 2.4.3.

No matter, beamformed packet is the first one, or the last one, or the one in
the middle, all "true/false" fields are correct.

-- 
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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2018-01-09 Thread bugzilla-daemon

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

--- Comment #27 from Guy Harris  ---
(In reply to zpchi004 from comment #26)
> Hi Guy,
> 
> It looks like the bug is fixed with the latest release. Could you confirm?

I don't have a capture with which to test, so I can't "confirm" in the sense of
"it doesn't work with an older release but it does work with a newer release".

I can, however, check what's different, if anything, between the release where
it works and the release where it doesn't.  Are you saying it didn't work with
2.4.2, but does work with 2.4.3?

-- 
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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2018-01-09 Thread bugzilla-daemon

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

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

It looks like the bug is fixed with the latest release. Could 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 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2017-12-18 Thread bugzilla-daemon

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

--- Comment #25 from zpchi...@yahoo.com ---
Thanks, Guy, for the detailed explanation!
Plz feel free to let me know what else I can do to help debugging this issue.

-- 
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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2017-12-18 Thread bugzilla-daemon

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

--- Comment #24 from Guy Harris  ---
(In reply to zpchi004 from comment #23)
> After running: tshark -V -r {file starting w/ the beamformed packet}
> 
> a) b) c) d) are all correct:
> 
> 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: True
> d) 802.11 radio info -> Beamformed: True
> 
> After running: tshark -V -2 -r {file starting w/ the beamformed packet}
> 
> a) b) are correct. c) d) are wrong:
> 
> 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

Exactly as I suspected.

> I'd appreciate if you can briefly explain what is the difference between the
> above two cmds. What does "-2" mean? Thanks.

The TShark man page at:

https://www.wireshark.org/docs/man-pages/tshark.html

says:

   −2  Perform a two‐pass analysis. This causes tshark to buffer output
   until the entire first pass is done, but allows it to fill in
   fields that require future knowledge, such as ’response in frame #’
   fields. Also permits reassembly frame dependencies to be calculated
   correctly.

By default, TShark reads each packet from the capture file, in order, dissects
it, and prints the result of the dissection (-V means "print the details rather
than the one-line summary).  The offending packet would be read first, before
reading any of the other packets, so there's no way that the subsequent packets
could affect how it's dissected.

-2 means that it reads all the packets, dissects them - possibly without
generating a protocol tree, so it would dissect only enough to construct any
state needed - without printing anything, and then goes back and reads all the
packets again, dissecting and printing the result of the dissection, using
whatever state was built during the first path.  The second time it dissects
the offending packet, all the other packets will have been dissected, and
*some* result of that could affect the second dissection.

Wireshark reads all the packets before displaying them; that pass is analogous
to the first path of "tshark -2".  If you click on a packet, it re-dissects it
to generate the protocol tree to display.

-- 
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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2017-12-18 Thread bugzilla-daemon

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

--- Comment #23 from zpchi...@yahoo.com ---
After running: tshark -V -r {file starting w/ the beamformed packet}

a) b) c) d) are all correct:

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: True
d) 802.11 radio info -> Beamformed: True



After running: tshark -V -2 -r {file starting w/ the beamformed packet}

a) b) are correct. c) d) are wrong:

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

I'd appreciate if you can briefly explain what is the difference between the
above two cmds. What does "-2" mean? 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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2017-12-17 Thread bugzilla-daemon

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

--- Comment #22 from Guy Harris  ---
(In reply to zpchi004 from comment #21)
> Yes, from the previous few tests.

What happens if, on the file that begins with the offending packet:

you run TShark as "tshark -V -r {file}";

you run TShark as "tshark -V -2 -r {file}"?

See how the first packet is dissected in *both* of those.

-- 
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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2017-12-17 Thread bugzilla-daemon

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

--- Comment #21 from zpchi...@yahoo.com ---
Yes, from the previous few tests.

-- 
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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2017-12-17 Thread bugzilla-daemon

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

--- Comment #20 from Guy Harris  ---
(In reply to zpchi004 from comment #19)
> There is no change by exporting only the offending packet and all the
> packets *after* that. The displayed info stays the same as follows:
> 
> 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

OK, so if the offending packet is the *last* packet, it's dissected correctly,
but if it's the *first* packet, it's dissected incorrectly?

-- 
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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2017-12-17 Thread bugzilla-daemon

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

--- Comment #19 from zpchi...@yahoo.com ---
There is no change by exporting only the offending packet and all the packets
*after* that. The displayed info stays the same as follows:

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

-- 
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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2017-12-16 Thread bugzilla-daemon

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

--- Comment #18 from Guy Harris  ---
(In reply to zpchi004 from comment #17)
> I export 145 packets out, with the 145th packet being beamformed.
> Then values of both TXOP_PS_NOT_ALLOWED and Beamformed are displayed
> correctly.

OK, so what happens if you export only the offending packet and all the packets
*after* that, and read that?

-- 
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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2017-12-16 Thread bugzilla-daemon

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

--- Comment #17 from zpchi...@yahoo.com ---
I export 145 packets out, with the 145th packet being beamformed.
Then values of both TXOP_PS_NOT_ALLOWED and Beamformed are displayed correctly.

The 145th 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: True
d) 802.11 radio info -> Beamformed: 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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

2017-12-16 Thread bugzilla-daemon

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

Guy Harris  changed:

   What|Removed |Added

Summary|In a WiFi capture log, the  |In a WiFi capture log, the
   |11ac “beamformed” and   |11ac “beamformed” and
   |TXOP_PS_NOT_ALLOWED bit are |TXOP_PS_NOT_ALLOWED bits
   |shown as “true” in radiotap |are shown as “true” in
   |and “false” in "802.11  |radiotap and “false” in
   |radio"  |"802.11 radio"

-- 
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” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

[Wireshark-bugs] [Bug 14266] In a WiFi capture log, the 11ac “beamformed” and TXOP_PS_NOT_ALLOWED bits are shown as “true” in radiotap and “false” in "802.11 radio"

15 matches

Site Navigation

Mail list logo

Footer information