FTW IEEE802.11a/g/p OFDM Frame Encoder

GNU Radio
1

Dear All,
We tried using this encoder to transmit frames with USRP2
XCVR
2450 daughter-card on Ubuntu 9.10. We confirmed transmission with a
WiSpy
dongle. But we cannot receive the frames on a receiver. The receiver we
are
using is an Atheros 802.11 a/b/g NIC in monitor mode with Mad WiFi
driver.
We have tried almost all the channels in 802.11a and 802.11g, but could
not
receive a single packet on receiver. In the project description we came
to
know that 802.11a frames were successfully received with a Ralinc NIC.
Has
anyone tried out this project? If so, please tell us the procedure to
receive these frames with an NIC? Or at least some way to confirm that
the
frame was actually received by the NIC? (We even tried Kismet configured
to
report frames even if CRC check fails). Any help would be appreciated.

Thank you.
Sankalp Nimbhorkar
CSC Graduate Student
North Carolina State University

2

Regarding to BBN, you may try to the high interpolation and decimation
rate,
as well as proper gain. I was able to decode it on RX (Ubuntu
9.10+gnuradio
3.2.2)

For FTW OFDM code, I was able to decode the 802.11g packet as well at
Wireshark using an Atheros 802.11a/b/g NIC in monitor mode, where I have
saved the TCPdump file. But recently I tried to re-conduct the
experiment, I
can not get it anymore. :frowning:
I am still trying to figure out what problem there is.

Guanbo

On Sun, Feb 20, 2011 at 3:13 PM, Sankalp Nimbhorkar <

3

Hi Guanbo,

Thanks for your reply.

I’ve some good news regarding the FTW OFDM encoder - we were able to
decode
802.11 a/g packets using kismet/wireshark later in the day. It seems
that
we’ll have to set the OFDM coderegime option as 6 or 7 or 8 (I’m not
sure
about 8 but 6 definitely worked). The version information of our test
system
is same as that as what is used here -
https://www.cgran.org/wiki/ftw80211ofdmtx but our USRP2 HW revision
number
is different and we used the latest firmware.

Regarding BBN USRP2Version - I’ll try that and get back to you in case I
face any difficulties.

Thanks,

Ashu

4

I have tried this and I was able to receive frames using an Atheros NIC
in
monitor mode.Specifically the card was a AR5413 Atheros card.

Did you check that the receiver NIC is on the same channel as the
transmitter? The script given on the FTW page is using channel 1.

Thanks,
Manav

5

Yup. Even regime 8 works fine. Haven’t checked the loss rate, though. It
seems, the Atheros NIC will not receive any packets below 18Mbps. We
tried
it for channel 44 and channel 6. It works fine.
Thanks
Sankalp

6

Hi Guanbo,

You’re running the script fine. If you look into the ftw_packet_utils.py
script, you’ll find that the encoder just prepends a static MAC header

  • Source
    Mac is 00:20:d6:01:3c:f1 (a quick web search will show that MAC
    Addresses
    which begin with 00:20:d6 belong to BREEZECOM). Similarly you’ can find
    the destination* *MAC and BSSID. The packet will be decoded as a
    mac-layer
    service data unit (MSDU).

I’m not sure if you’ve done this already but make sure you set up your
wireshark correctly by selecting “802.11” as the “Link-layer header
type” in
the “Capture Options” to receive 802.11 packets (
WLAN)

Let me know how it goes.

Thanks,
Ashu

7

The frequency band is correct. Just now, I re-install the repository
from
the CGRAN, and tried again using:
sudo python ftw_ofdm_tx.py -f 2.462G -i 5 --regime=8 --payload=“Here are
some test messages from WiSeR” -r 10000
So the only question is, I have NOT updated my firmware. I will try that
as
well.

By the way, what does the USRP2 generated packet look like in Wireshark
at
another laptop?

Thanks,
Guanbo

On Sun, Feb 20, 2011 at 11:32 PM, Ashutosh Grewal

8

Guanbo ZHENG wrote on 22.02.11 00:36:

The frequency band is correct. Just now, I re-install the repository from
the CGRAN, and tried again using:
sudo python ftw_ofdm_tx.py -f 2.462G -i 5 --regime=8 --payload=“Here are
some test messages from WiSeR” -r 10000
So the only question is, I have NOT updated my firmware. I will try that as
well.

We used the XCVR2450 only so far. In our experience, the most common
reasons
why it fails are:

  1. channel on the RX side is not set to the one you use at TX
  2. TX gain is too high or too low (depending on what kind of antennas
    and
    “channel environment” you are using)
  3. old USRP2 firmware bug (try also with -s option and see if it changes
    the
    behavior) see documentation https://www.cgran.org/wiki/ftw80211ofdmtx
  4. try also with -r 1 and -r 0 (the repetition method we used in the
    code is
    very dirty)

By the way, what does the USRP2 generated packet look like in Wireshark at
another laptop?

Ideally, you would tick the “capture using promiscuous mode” and
“capture
using monitor mode” in the Wireshark GUI. Then you should see every
PHY-valid frame whatsoever the card is able to decode on the channel
that
it is currently listening on. Make sure it does work like that. E.g. do
you
see beacons of the access-points nearby?

The link-layer header-type should be “802.11 plus radiotap header” and
you
should see the radiotap headers appended to every frame.

If you have it available you can also use cmd-line tool called athstats
to
debug. You can get access to some atheros-specific counters with it,
like
how many frame-detected events per seconds are registered by the NIC.

If all of this doesnt help there is this method to find out if the
problem
is in HW/GNUradio subsystem or on the encoder/decoder side:

Try to generate frames using the Atheros NIC and record the signal (a
block
of baseband to disk) using the USRP2 with rx_cfile.py. Then put the
Atheros
in monitor mode again and transmit this very baseband block using
transmit.py we included in the ftwofdm release (in src/matlab).

You have to use the same USRP2 for recording/transmission, and you
should
not wait too long between RX/TX because of potential frequency offsets.

If this “record-playback” does not work there is still something wrong
in
your current XCVR2450/USRP2/GNUradio subsystem. If it does work our
encoder
is the source of the problem :frowning:

cheers
paul

–
Dipl.-Ing. Paul Fuxjaeger
FTW - Telecommunications Research Center Vienna
http://www.ftw.at callto://:paul.fuxjaeger.at.work
PSTN:+43-1-505283057 | 3GPP:+43-676-4787088

9

Hi, Paul

Thanks for your description. I finally figure out the problem that the
Gigabyte Ethernet Card in my computer does not support Gigabyte.
Either it is because of driver problem or itself. After using another
good
Ethernet card, it works smoothly. :slight_smile:

I have another question for FTW OFDM, in which I wanna implement the
transmit-wait-transmit scenario.
Specifically, I tried to transmit some data stream first, sleep for a
few
second and then transmit another one.
$ sudo python ftw_ofdm_tx.py -e eth1 -f 2.462G -i 5 --regime=3 -g 30 -r
1

However, from the spectrum I have observe, it seems USRP2 keeps
generating
the same signal, without any sleeping or waiting time.
By looking into the codes, I found msgq() seems to be fine. Also, when
there
is no payload, EOF set to true, telling the msgq() no more messenge.
Then, what is the possible reason for my problem?

Any suggestions are appreciated!

Thanks,
Guanbo