discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] BBN 802.11 bbn_80211b_rx.py commandline?


From: Greg Troxel
Subject: Re: [Discuss-gnuradio] BBN 802.11 bbn_80211b_rx.py commandline?
Date: Tue, 07 Nov 2006 20:02:36 -0500
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (berkeley-unix)

I am indeed reading the list :-)

  desired freq =  2437000000.0
  baseband frequency 2432000000.0

This looks ok - I think it's trying to grab from above and below

Not sure when you updated, but we have changed the checked in code to
default to 2437, and run it like this (as a NetBSD rc.d start script):

   #!/bin/sh
   #
   # $Id: etc:rc.d:gnuradio_80211,v 1.4 2006/09/12 15:40:00 gdt Exp $
   #

   # PROVIDE: gnuradio_80211
   # BEFORE:  measure
   # REQUIRE: DAEMON
   # KEYWORD: shutdown

   $_rc_subr_loaded . /etc/rc.subr

   name="gnuradio_80211"
   rcvar=$name
   #command_interpreter="python2.4"
   command="/usr/adroit/lib/python2.4/site-packages/bbn_80211b_tap.py"
   start_cmd="gnuradio_80211_start"
   stop_cmd="gnuradio_80211_stop"

   export PYTHONPATH=$PYTHONPATH:/usr/adroit/lib/python2.4/site-packages
   export PATH=/usr/pkg/bin:/usr/adroit/bin:$PATH

   gnuradio_80211_start()
   {
       $command > /tmp/gnuradio.log 2>&1 &
       # Should have to bring tap0 up, but it's up already.
       # XXX wait for tap0 to come ready
       sleep 10
   }

   gnuradio_80211_stop()
   {
       # SIGTERM doesn't work
       pkill -9 -f bbn_80211b_tap.py
   }

   load_rc_config $name
   run_rc_command "$1"


We had this working on Linux as well, but it's possible that the Linux
tap code is not quite right, or sensitive to your linux kernel
version.  Last time I ran this (9/23), it printed out beacons from an
AP just fine (NetBSD, with our tap(4) changes for 802.11).  I'll be
trying again soon, I expect.

It is on my todo list to merge this code into the main repository.
But, that raises a lot of issues, such as teasing apart 802.11 receive
and tap processing, which really should be completely separate.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]