802.11 on USRP+GNURadio

The subject of my previous mail ought to have been 802.11 on USRP.


Looking at the archives, I understand that I can receive 1 Mbps
probe/beacon packets with code developed by BBN. I use their code and
see packets at 1 Mbps from different nodes.
However, I don’t know of a way to have the USRP as a destination for a
flow using standard packet generation tools like Iperf. So I setup a

We wrote code to inject the packets (802.11 frames) into a modified
NetBSD tap device that was an 802.11 interface rather than ethernet, and
then were able to use tcpdump. All of this code is on the
acert.ir.bbn.com server. We didn’t address all the interactions with
the 802.11 state machines in net80211 and the GNU Radio implementation.
So you should be able to port this to Linux, but it’s non-trivial.

UDP flow between a conventional 802.11bg AP and a Laptop. I capture
the packets on air with the USRP and determine how many of the packets
of this flow I am able to receive. But here, out of 1000 packets (1500
bytes each) sent at 1 Mbps, the laptop is able to receive around 900
packets but the USRP captures somewhere between 100 to 550 packets. I

If the laptop is only gettinng 900, that indicates something is wrong.
Are you sending these back to back as fast as you can? I’d back off to
200 pps or something like that, and see what happens, and then gradually
increase the rate, watching CPU load.

am wondering whether this makes sense. I thought that the BBN code
would capture most of the packets provided the rate is 1 Mbps
(disregarding probe packets from other APs). But this does not seem to

We did get most packets given a reasonable load

I use gnuradio-3.1.2 on Ubuntu Dapper with a 2 GHz Intel core duo
processor and 2 GB RAM.

We had 1.6 GHz Pentium M with 2 GB RAM (Thinkpad T43), with NetBSD
current from summer 2006 (pre 4.0).

Sri Ram,

We’ve had similar issues. Please see our 802.11 receiver



We’ve had similar issues. Please see our 802.11 receiver


Indeed - you should definitely try the others. Ours sort of works, and
has a c ool hack to fit within USRP USB bus bandwidth, but I expect
implementations that deal with some things on the USRP side to have
substantially better performance.