Comment # 5
on bug 11277
from Hany
(In reply to Guy Harris from comment #4)
> (In reply to Guy Harris from comment #3)
> > I asked, and Johannes Berg, the person who originally proposed the A-MPDU
> > Status field, says that the packet data following the radiotap header should
> > *not ever* have an MPDU delimiter - it should *always* start with an 802.11
> > header.
>
> And, as I realized, and as Johannes noted, the radiotap A-MPDU Status field
> includes the delimiter CRC, and the other data in the delimiter is redundant
> (the reserved field is reserved, the length is the length of the MPDU, and
> the "unique data" is the ASCII code for the letter "N"), so there's no
> reason to include the MPDU delimiter in the capture.
OK, according to what you have confirmed in here, the ns3 is buggy. So whenever
ns3 generates these PCAP files it should not include the A-MPDU Delimiter and
Padding, it should extract the MPDU from the A-MPDU frame and store it in the
capture file, correct?
In addition, whenever an Access Point uses MPDU aggregation, it will transmit
different A-MPDUs Frames belonging to the same A-MPDU as individual frames i.e.
each frame will be modulated and coded separately and transmitted over the air
as a series of individual frames.
Finally, would be possible to ask Johannes to modify the RadioTap and mention
that capture file should not include MPDU Delimiter in case of the
agrgregation?
You are receiving this mail because:
- You are watching all bug changes.