BBN 802.11 code: long preamble only?

GNU Radio
1

Hi all,

For those of you who have worked closely with the BBN 802.11 code, does
it
only handle a long preamble? I have not been able to get it to
successfully
decode any of my packets, which are all using a short preamble.

  • George
2

I also think that the decoder is improperly looking for
synchronization…

According to the 802.11 spec, the long preamble uses an SFD that is
0xF3A0,
and the short is 0x05CF (verified by a quick google (
http://www.google.com/search?hl=en&safe=off&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=zoI&q=802.11+0xF3A0+0x05cf&aq=f&oq=&aqi=
)

The definition of SFD and RSFD seem to be backwards:
https://www.cgran.org/browser/projects/bbn_80211/trunk/src/bbn/bbn_plcp80211_bb.h#L41

For those a little unfamiliar with the preamble, RFSD = reverse SFD, as
the
802.11 spec states that the short preamble uses the reverse of the
SFD…
but these defines seem to be backwards.

Still trying to get the decoder to pickup a short preamble though…

  • George
3

One more poke…

https://www.cgran.org/browser/projects/bbn_80211/trunk/src/bbn/bbn_plcp80211_bb.cc#L229

I’m assuming d_shift is supposed to shift the descrambled bytes to try
and
find synchronization, but it seems like this doesn’t happen?

  • George
4

George N. wrote:

For those a little unfamiliar with the preamble, RFSD = reverse SFD,
as the 802.11 spec states that the short preamble uses the reverse of
the SFD… but these defines seem to be backwards.

Still trying to get the decoder to pickup a short preamble though…

  • George
    I believe this is correct - the standard specifies that the SFD is
    0xF3A0, MSB to LSB, but the LSB shall be transmitted first in time. So
    if you reverse the ordering: 0xF3A0 (1111001110100000b) becomes 0x05CF
    (0000010111001111b). So, while the #define’s appear to be reversed
    (since they are), functionally this is correct. Re: your other question,
    on d_shift - it appears correct to me as well: take a look at the same
    loop above on line 191: sfd_search is the descrambled word being
    checked, it is bit-masked and compared to a shifted SFD (or RSFD), if
    the comparison fails, sfd_search gets shifted, and the loop continues
    (up to eight shifts). If the comparison never came back true, the state
    machine reverts to the preamble search state.
    Doug

–
Douglas G.
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
[email protected]

5

Hi Doug,

Thanks for the clarifications. I missed the order that the bits are
transmitted in, so that makes sense now.

I took a 1 second capture of 802.11 traffic, that I know has 1Mbps
beacons
in it and probe responses. The machine was able to decode them with its
Atheros card, and if I look at the magnitude of the raw samples captured
by
the USRP2, I can see several transmissions:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/raw_mag.png

The lower peaks around 5, 7, and 9x10^6 are beacons at 1Mbps with a
short
preamble. I am trying to decode these. I captured the trace at 25Msps
and
did not experience any overruns.

  • George
6

The other thing that is odd, is that the beacon’s in my trace use a
short
preamble (based on flags) but the transmission is at 1Mbps. From
looking at
the 802.11 spec, short preambles can only be followed by 2, 5.5, or
11Mbps
PSDUs. Here is a pcap of a beacon frame:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/beacon.pcap

  • George
7

George N. wrote:

The other thing that is odd, is that the beacon’s in my trace use a
short preamble (based on flags) but the transmission is at 1Mbps.
From looking at the 802.11 spec, short preambles can only be followed
by 2, 5.5, or 11Mbps PSDUs. Here is a pcap of a beacon frame:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/beacon.pcap
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/beacon.pcap

  • George

George,
That is a little bit odd for beacon frames, although my reading of the
spec doesn’t disallow that (at least not in 802.11-2007): 19.3.2.2 Short
preamble PPDU format says only that the short preamble is appropriate
for use with 2, 5.5, and 11Mb/s modes. By the way, the short
preamble/long preamble may be something you can configure on your access
point - although I suppose I wouldn’t be surprised if many recent AP’s
came with it set to short by default (i.e. they assume they’re only
taking to recent hardware). It increases the effective throughput the
channel is capable of, at the (at this point - probably minimal) cost of
not being able to talk to pre-802.11g equipment.
Three suggestions: the first is a repeat of the one to enable the
debugging output from the PLCP block (I think I’ve even added debugging
output when digging down into it: e.g. adding lines to output when it
switches between states (found complete SFD/RSFD, back to searching for
preamble, etc.). Second - disable the CRC check in the PLCP block (when
you instantiate the block you can pass a boolean to perform the checks
or not). You end up with errors in your ouput, but you at least see that
it saw something resembling an 802.11 frame. Finally: there is no
automatic gain control in the receive script(s) - so careful playing
with the gain setting for the USRP2 for any given TX/RX location can
improve the FER. There also is no frequency/phase offset correction in
the receiver code - really, this is a very simplistic receiver that just
gets the job done (and when they wrote it for the USRP1 - only in very
good SNR environments). Lots of room for improvement here.
Doug

–
Douglas G.
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
[email protected]

8

equipment.
offset correction in the receiver code - really, this is a very simplistic
receiver that just gets the job done (and when they wrote it for the USRP1 -
only in very good SNR environments). Lots of room for improvement here.

Thanks for the response, Doug. I will poke at trying to get it to
decode
these packets. By disabling the CRC check and enabling some basic
debugging
in the PLCP code, I am able to detect approximately the right number of
preambles, but the PLCP header is very borked when trying to decode
it…
which, given a short PLCP should be at 2Mbps.

Just to verify some of the decoder, I am trying to implement a short
PLCP
option in bbn_80211b_pkt.py. This would further verify the short PLCP
code. The major change that needs to happen here is that the preamble
needs
to be encoded at 1Mbps, just like the long preamble, but now the PLCP
header
needs to be encoded at 2Mbps.

  • George
9

Thanks Doug. I took a sample dump at 25Msps using the USRP2 and have
been
pumping these samples through the decoder trying to get some output. I
know
for a fact there are 8 packets in the trace, but haven’t been able to
find
any yet. Working on it :slight_smile:

  • George