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.