DWL-650 & Kismet [was Re: Orinoco Wireless Card and Monitor Mode w/ Kismet - No Longer Working?]

What I've discovered is the following:

By default, Kismet prints out the error as given:

--SNIP--
Source 0 (prism2source): Enabling monitor mode for radiotap_fbsd_b source interf
ace wi0 channel 1...
Source 0 (prism2source): Opening radiotap_fbsd_b source interface wi0...
WARNING:  pcap reports link type of EN10MB but we'll fake it on BSD.
This may not work the way we want it to.
--SNIP--

since datalink_type=pcap_datalink(pd); does actually return DLT_EN10MB.

HOWEVER, inserting code to enumerate available link types produces:

EN10MB (Ethernet)  IEEE802_11 (802.11)  IEEE802_11_RADIO (802.11 plus BSD radio information header)

[display code stolen directly from tcpdump]

Farther down in Kismet, the datalink is forced to DLT_IEEE802_11_RADIO as
follows:

        (void) pcap_set_datalink(pd, DLT_IEEE802_11_RADIO);   

This is all fine and good, but does appear to show some change in the
way data link types are returned to pcap (perhaps?)...

Now, my problem.  I have an up-to-date CURRENT system and all seems
to work well, with one exception.  When started, kismet_server proceeds
to eat all available CPU without producing the correct located networks.  

I ran kismet (from ports) directly on a 5.2.1 (from ISO) install and
it did not display this behavior (I'm working on putting together
another system to try to reproduce the problem).

Might anyone have a clue as to where I should start looking to see
what is going on?

I'd really like to retire my Linux box that I use for wardriving, but...

AlanC
-- 
   We have shared the incommunicable experience of war. We felt, we still
   feel, the passion of life to its top. In our youths, our hearts were
   touched by fire.                              -- Oliver Wendall Holmes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAs2DdyJP8xSfQVdsRAjPAAKDImvZn/Osk/3MzQu66JY4Scg++8wCgjhpU
kRUee7PoJ8FxttkNfQko1s8=
=E4Gs
-----END PGP SIGNATURE-----