USRP2 802.11 BBN code on the TX side

Hi all,

Yes, a couple USRP2 802.11 BBN code threads :wink: Trying to separate the
discussions a bit.

Did anyone get the TX code to properly interoperate with an 802.11 card?
I
have the usrp2_version branch running, with my modification to fix the
transmission filter, and I am using a probe responses payload as the
packet
payload sent to the USRP. I have barker spreading enabled, and am using
the
long preamble. So the code should append the long preamble, and
modulate
the probe response data, then pump it out.

I don’t see anything trying to decode with an 802.11 card in monitor
mode.
Unfortunately I don’t know of a way to get the card to report detecting
preambles or PLCP’s, so it’s kind of hard to debug the PLCP here. But,
using the loopback with the 802.11 probe response data, the code is able
to
decode it properly. So… it seems like something is borked on the TX
side.

If anyone has gotten interoperability, let me know. If anyone knows of
any
outstanding issues, let me know :slight_smile: I will continue debugging in the
mean
time.

  • George

Thanks Doug, there is hope! I’m going to hook it up to a spectrum
analyzer today and make sure everything is okay out of the USRP2. If
you think of anything or get back to your office just let me know,
thanks!

  • George

Hi Doug,

Thanks for the response. Correct, through USRP2 to an Atheros card
running
tcpdump that is definitely in promiscuous mode. I have not been able to
decode a packet yet. What I’ve done is replaced the payload with an
802.11
Probe Response packet to have something noticeable. If I set the card
to
report packets that have PHY or CRC errors, I occasionally see a packet
reported:

03:44:07.572350 10855977948us tsft 1.0 Mb/s 2417 MHz (0x0480) -8dB
signal
-71dB noise antenna 1 63dB signal Probe Response[|802.11]
The SNR notably not an issue… also what I’ve done is tried using a
matched
filter against the preamble. I extracted the corresponding samples to
the
modulated preamble from an 802.11 packet captured with the USRP2, and
correlated it with a captured trace that has 11 802.11 packets. There
is
CLEARLY a correlation (as expected):
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/trace_signature.png

Note that the packet I extracted the signature from the USRP2 capture is
decodable by the BBN decoder. Now, if I use the same signature and try
to
correlate it with a packet that the BBN code generates, it does NOT
correlate:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/captured_sig_with_our_packet.png

If I use the BBN code to generate a signature of the preamble, it
correlates
great with itself (as expected) and NOT with an 802.11 packet captured
with
the USRP2:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/gr_sig_with_our_packet.png
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/gr_sig_with_trace.png

Interestingly enough, if I disable the barker option in the BBN code to
generate a signature, it correlates better (but not that well) with the
USRP2 trace of captured 802.11 packets:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/gr_nobarker.png

So… something is wrong somewhere. To try and verify things, Dan
Halperin and I hacked up an 802.11b modulator in matlab, and our code
correlates pretty directly with the BBN code (it can demodulate our
packets
and our signatures correlate), but again our does not generate
correlateable
signatures with captured 802.11 packets. :\

So I suspect something is different about how the 802.11 card is
modulating
packets at 1Mbps with a long preamble. I suspect that once I get the
802.11
card to successfully decode a packet generated by the BBN code, it might
be
able to generate a proper signature.

  • George

On Sun, Dec 6, 2009 at 5:12 PM, Doug G. [email protected]
wrote:

George,
Those are some interesting results (although perhaps interesting isn’t
truly desirable here - you want something that just works).

Something is up :slight_smile: I am additionally working to see what the Simulink
802.11 model spits out. It seems like everything disagrees with an
802.11
card :stuck_out_tongue:

Just to make sure I’m understanding what you’re doing: this is a
cross-correlation between a known preamble (i.e. scrambled ones
modulated by DBPSK spread using the 11-chip barker code, and then passed
through an RRC filter) and received samples from a commercial 802.11
card transmitting?

Correct! I am trying to generate the known preamble with the BBN code,
some
matlab code, anything really. But as my result showed, what the BBN
code
and the matlab code generates does not correlate to a real 802.11
packet’s
preamble.

DBPSK modulated, spread by the 11-chip barker code, filtered, etc… This
is where I’d start the investigation. Actually - see below about the
other possibility (the commercial card is doing something different?)

Right, actually what I’ve been focusing on is the matlab code Dan and I
wrote because it’s very easy to follow (not broken up in to a bunch of
blocks and queues, etc…) and then once I figured out what the high
level
issue is I can apply it to the BBN code, because the signal generated by
the
matlab code DOES correlate with the BBN code… so it seems as though
they
have a similar issue.

You may need to check that the BBN code is doing the correct thing at
each step: the preamble should consist of scrambled ones, they should be
DBPSK modulated, they should then be up-sampled and spread by the
11-chip code, and then passed through the RRC pulse-shaping filter.

Okay this is where we should start :slight_smile: Even without the RRC
pulse-shaping
filter, shouldn’t the generated signal correlate? What I do now is the
following:
scrambled ones
DBPSK modulated
Phase shift
Barker

I’m not upsampling my signature generation because I bring the trace
down to
11Msps. I’ve uploaded the code (yes, matlab code… we can take the
discussion of it off list):
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/matlab_80211b.tar.gz

There is a README.txt in it with instructions. Again, the hope is that
whatever I determine is wrong with the matlab model, will apply to the
BBN
model. It’s just much easier to modify the matlab code and rerun it
rather
than building blocks, reinstalling, outputting, plotting, etc.

descramble to see what it consists of?

Just remember, the matlab model is a model that Dan and I built… so
it’s
not necessarily matlab’s model :wink: But to our knowledge, we carefully
followed the 802.11 spec. BTW, I’m only focusing on long preamble for
now
to eliminate the variable of short preamble. I pushed the whole
modulated
packet I generated (whose preamble is my signature) through the BBN code
and
it decodes it successfully, with no errors. Additionally, Dan wrote a
small
demodulator which demodulates the first 802.11 packet from the USRP2
trace
and correlates its scrambled preamble with our scrambled preamble (in
the
digital domain), and we get a nice correlation:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/digital.png

Later this week I’ll be able to do some more tests with my setup, and
maybe I can find something useful. Remind me again - what were you
changing in the tx filter code? Was it just adding the ability to do the
short preamble?

That’d be great. Don’t change anything with the TX filter for now :slight_smile:
Ignore short preamble also, just focusing with long for now.

  • George

I’m making some progress…

I demodulated one of the captured 802.11 packets to determine the
sequence
of its preamble (scrambled 1s) … and both the BBN code and my matlab
code
have several bits wrong in the sequence. The result is this:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/scrambled_preamble.png

Properties of the Barker sequence! If I DBPSK modulate and re-barker
the
demodulated bits, I successfully correlate:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/demod_bits_remod.png

This suggests that the BBN scrambler (and the hacked up matlab
scrambler)
are both wrong, but verifies the modulators. I suspect this is why the
802.11 card cannot demodulate the packets.

Back to the grind…

  • George

I double checked the scrambler code and I really do not see anything
wrong
with it, it seems to meet the 802.11 spec for DSSS. Then I found
something
in the spec that says that the transmitter need not start with the seed,
since the receiver’s descrambler is self-synchronizing. So then I
figured,
maybe the transmitter just started with a different seed… so I
generated
128 different signatures, for all 128 different possible scrambler
seeds,
and NONE correlate.

Maybe it’s using a different scrambling algorithm? I’m running out of
ideas.

  • George

On Mon, Dec 7, 2009 at 12:44 PM, George N. [email protected]
wrote:

I double checked the scrambler code and I really do not see anything wrong
with it, it seems to meet the 802.11 spec for DSSS. Then I found something
in the spec that says that the transmitter need not start with the seed,
since the receiver’s descrambler is self-synchronizing. So then I figured,
maybe the transmitter just started with a different seed… so I generated
128 different signatures, for all 128 different possible scrambler seeds,
and NONE correlate.

Maybe it’s using a different scrambling algorithm? I’m running out of
ideas.

It might transmit the opposite of what it is expecting to flush the
receiver scrambler and get it synchronized. So if you need a long
length of 1’s, maybe it starts sending a couple symbols worth of 0’s
first - gets synchronized, then starts the sending of 1’s. Same with
the 0’s for the preamble.

Maybe despread your symbols and run through the derandomizer, then
check to look at the pattern. You should see your long string of 1’s
or 0’s (whatever you’re looking for). Then check to see what they
send beforehand?

Brian

Here’s the other interesting thing…

Follow closely to the numbers here. If I do NOT barker the preamble
(1Msps), and then upconvert it to 11Msps… BUT ONLY use the first 144
samples for the signature, I get a small correlation near the start of
all
the transmissoin in the USRP trace:

http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/matlab_nobarker.png

So the first 144 samples AFTER it was upconverted, means that roughly
the
first symbol 13 symbols correlate without barker spreading.

George N. wrote:

Hey Brian,

Running through a descrambler and then trying to correlate with 128
ones, I get the following for the 11 packet trace:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/descrambled.png
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/descrambled.png

George,
Just to give you an update - I did run a couple more tests on
transmitting today. I am able to receive proper 802.11 frames, but
they’re mostly filled with garbage. When I fill in some fake (but known)
values in the MPDU header (i.e. frame control, duration, mac addresses,
etc.) and the payload consists of Hello World, and the text from
getty.txt, I’m not getting correct values when I look at in in Wireshark

  • but a few words from getty.txt do show up somewhere in the middle. So
    the PHY stuff is sort of working, I do wonder if the scrambler isn’t the
    bug here, but that’d require more checking.
    The main (functional) modification I’ve made to the script (besides
    muddling with the payload), is to lock the USRP2’s clock to my external
    reference clock (a GPSDO I have to provide a 10Mhz reference). Running
    the straight usrp2_version script does not work - suggesting the clock
    offset may be too large for the commercial card to lock onto with the
    USRP2 in free-running mode. Hmmm, my copy of the 802.11 spec says the
    transmit center frequency tolerance should be +/- 25ppm, and I recall
    the USRP2’s clock in free-running mode was ~+/- 20ppm, so I find it odd
    that the clock being locked would make or break the (sort-of working)
    transmit script. In the meantime, from the behavior I’m seeing on the
    captures from the commercial 802.11 card, I suspect it is the scrambler
    that isn’t working (i.e. lots of garbage, some correct bytes, followed
    by garbage).
    Certainly needs more investigation,
    Doug


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

On Thu, Dec 10, 2009 at 3:33 PM, Doug G.
[email protected]wrote:

Just to give you an update - I did run a couple more tests on transmitting
straight usrp2_version script does not work - suggesting the clock offset

Hi Doug,

Thanks for the update! I have to run now, but a quick note…

To save you some work I can send you some code that I wrote that has the
BBN
code send Probe Response packets, so that you can see if these are
decodable
or not successfully. That will save you from writing code to fill in
proper
802.11 header and fields. Will send it out soon.

  • George

Hey Brian,

Running through a descrambler and then trying to correlate with 128
ones, I
get the following for the 11 packet trace:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/descrambled.png

There are clearly 11 spikes, but the closest we get in a window of 128
bits,
is roughly 82 ones. Here are the descrambled bits when closest to a
correlation of 128 ones:
0 1 1 1 0 1 1 0 0 1 1
1 0 1 1 0
1 1 1 1 1 1 1 1 1 0 1
1 1 0 1 1
0 1 1 1 1 1 1 1 1 1 1
0 1 1 1 0
1 1 0 1 1 1 1 1 1 1 1
1 0 1 1 1
0 1 1 0 1 1 1 1 1 1 1
1 1 1 0 1
1 1 0 1 1 0 1 1 1 1 1
1 1 1 1 1
0 1 1 1 0 1 1 0 1 1 1
1 1 1 1 1
1 0 1 1 1 0 1 1 0 1 1
1 1 1 1 1

Timing/frequency error? If I use these bits as my preamble (instead of
128
ones) and pass it through our full modulator (scramble → DBPSK →
barker),
we correlate very nicely with all 11 transmissions:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/remodulated.png

  • George

http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/bbn_with_probes.tar.gz

Sorry, make clean it before building… trying to get this out ASAP
since I
will be AFK for the next 6 hours or so.

Just run bbn_80211b_transmit.py … default parameters should work. I
commented out some code which loops sending the packet several times to
help
test.

The decodable packet should look like this:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/probe_response.pcap

  • George

On Thu, Dec 10, 2009 at 3:33 PM, Doug G.
[email protected]wrote:

Just to give you an update - I did run a couple more tests on transmitting
straight usrp2_version script does not work - suggesting the clock offset
may be too large for the commercial card to lock onto with the USRP2 in
free-running mode. Hmmm, my copy of the 802.11 spec says the transmit center
frequency tolerance should be +/- 25ppm, and I recall the USRP2’s clock in
free-running mode was ~+/- 20ppm, so I find it odd that the clock being
locked would make or break the (sort-of working) transmit script. In the
meantime, from the behavior I’m seeing on the captures from the commercial
802.11 card, I suspect it is the scrambler that isn’t working (i.e. lots of
garbage, some correct bytes, followed by garbage).
Certainly needs more investigation,

Hi Doug,

I can guarantee you that the scrambler is not working :wink: The 802.11
spec
states that at the beginning of every transmission, the scrambler needs
to
reset its seed, however the BBN code does not do this.

That’s interesting on the clocks. What daughterboard are you using?

  • George

George N. wrote:

Hi Doug,

I can guarantee you that the scrambler is not working :wink: The 802.11
spec states that at the beginning of every transmission, the scrambler
needs to reset its seed, however the BBN code does not do this.

That’s interesting on the clocks. What daughterboard are you using?

  • George
    I’m using the RFX2400. Looking at the spectrum in a spectrum analyzer
    suggests we aren’t making the correct spectrum on transmit - not sure if
    that’s simply because we aren’t doing any filtering (i.e. RRC or other
    pulse shaping), or if it’s something more fundamental.
    I think as long as the scrambler isn’t set to all ones at the start of
    a transmitted frame, we’re all good. It’s self-synchronizing, so it
    doesn’t need to be at any known state at the start of a frame.


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

Hi George,

I was looking for BBN & USRP2 information at the list when I saw your
message. I’m interested on get interoperability with 802.11 cards in
monitor mode, but I still haven’t had success. Could I make you some
short questions?

  • Which modification did you do to the transmission filter?
  • How can you use probe responses payload as a packet payload sent to
    the USRP2?
  • Did you get seccess with this issue?

Thank you for your help.

George N. wrote:

The decodable packet should look like this:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/probe_response.pcap
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/probe_response.pcap

  • George
    Interesting - I’m able to capture this with my airpcap (just a 30dB
    attenuator and some coax in-between my USRP2 and the airpcap). Lots of
    errors (either due to a screwy scrambler function, or something causing
    a high bit-error rate. For this one test, everything after the Source
    Address (i.e. starting with the BSSID) is wrong.
    Doug


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