Wireshark-bugs: [Wireshark-bugs] [Bug 8594] Adding support for IEEE-802.11ad protocol at the cur
Comment # 32
on bug 8594
from Jalil Moraney
(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #29)
> > > To continue :
> > > Tag supported Rates is always set to 0 ? normal and bug ?
> > > there is special value for 802.11ad ?
> >
> > In the 11ad, "supported rates" IE does not used, since there are no "rates"
> > used, only MCS indexes. Standard prohibit inclusion of "supported rates" IE
> > in 11ad frames.
>
> Ok thanks for information.
>
> Any news about update ?
I started working on a update, almost all issues you brought up were resolved.
Only the issue of malformed packets "Action No Ack" is a bit not clear. The
patch lacked dissection of such frames, but it appears that even after the
addition the packets are still malformed.
3 options:
1) Either the packets are really malformed and not according to the standard.
2) Or they include a vendor specific extension, that the dissector don't
recognize. (not a tagged filed?!)
3) There is another bug in there.
For example, packet 31022:
Its last:
0x10 - Category value changed from reserved to DMG category (16). (old code)
0x06 - DMG Action of type DTP Request frame format. (new code)
0x00 - Dialog Token. (new code)
Here the Action field of the Action No Ack frame ends with:
"One or more vendor-specific elements may appear in this frame. This element
follows all other elements"
If we look further into the packet we expect a tagged field with tag number:
0x00 - TAG_SSID (old code)
0x7c - tag length of 124 which is bigger than the maximal 32 allowed.
what is more disturbing is that the tag length is followed by only 13 bytes.
(old code)
>From analyzing it further, I'm getting more and more sure that it is option #1.
I would be more than glad to receive second opinion about this analysis, maybe
there is something I'm overlooking.
You are receiving this mail because:
- You are watching all bug changes.
