Date: Tue, 25 May 2004 14:19:45 -0700 From: Sam Leffler <sam@errno.com> To: freebsd-mobile@freebsd.org Subject: Re: DWL-650 & Kismet Message-ID: <200405251419.45151.sam@errno.com> In-Reply-To: <20040525203957.GC5559@moya.lambermont.dyndns.org> References: <200405200904.37966.fish@fish-mail.com> <20040525200110.GY72221@shazam.wetworks.org> <20040525203957.GC5559@moya.lambermont.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 25 May 2004 01:39 pm, Hans Lambermont wrote: > Alan B. Clegg wrote: > > Out of the ether, Alan B. Clegg spewed forth the following bitstream: > >> 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). > > > > I must be hallucinating, as I've just done a clean re-instll from the > > same media, and it acts the same way, WCPU of kismet_server going to > > 107% (!), the machine going nearly comatose, and networks not being > > found. > > > > I'm now really confused as to where I need to start looking, as I don't > > have a working reference point. > > > > Can someone that has kismet working correctly run it with stderr pointed > > elsewhere and see if you get the: > > > > "WARNING: pcap reports link type of EN10MB but we'll fake it on BSD." > > > > message? > > Yes, this message is in my kismet's stderr. > > Here's my top kismet part: > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > 13391 root 76 0 2776K 2140K select 0:06 2.34% 2.34% > kismet_server 13389 hans 76 0 2980K 2416K select 0:00 0.00% > 0.00% kismet_server 13393 hans 76 0 3104K 2484K select 0:00 > 0.00% 0.00% kismet_client 13394 hans 76 0 2904K 2224K select > 0:00 0.00% 0.00% kismet_client and some more clients. > > WCPU is 2.34% for kismet_server. I'm starting to remember about this stuff. I did the kismet code to support radiotap and freebsd. The complaint about the DLT type is because I didn't want to cannibalize the kismet code that handles this stuff--fixing the code to not complain would've required major surgery and Mike wasn't keen on that (or maybe I wasn't?). As to the cpu usage, I believe this was an unresolved problem with the wi driver that didn't happen with ath. Despite seeing high cpu usage with the wi driver things appeared to work fine for me and I ran out of time to spend chasing the problem. So what everyone is seeing is probably just the way I left it when I did the original work. kismet is a useful tool but a bit painful to debug with gdb because of the heavy use of STL. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200405251419.45151.sam>