Kismet Wireless

Kismet Forums


Posted by:dragorn
Subject:newcore and svn CPU/server problems
Date:13:38:57 19/09/2009

> > > I've tried running both Kismet-2009-06-R1 and svn devel release with reasonably default configurations and with both iwl3945 and rtl8187 drivers/sources on a dual core Lenovo x60. In all cases, the server does not respond (after usual startup messages) and CPU use hits 100% with memory use slowly increasing to 50% after a few minutes. I've tried changing options such as channels and hopping without success.
> >
> > Sounds like a driver bug, definitely not seen anything like that. Will need detailed debug traces to do anything more.
> >
> From gdb it seems to be looping here:
> #3 0xb7ea4695 in nl_recvmsgs () from /usr/lib/
> #4 0x0808872f in mac80211_get_chanlist (interface=0x97e624c "wlan1", chan_list=0xbfa32210, errstr=0xbfa31c3c "�006") at
> and in strace:
> recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\344\3\0\0\25\0\2\0\207\254\264J\300M\0\0\3\1\0\0\10\0\1\0\1\0\0\0\t\0\2\0p"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 996
> I hope that's enough information. Many thanks. M

It's definitely getting stuck in a loop talking to the driver (and not even in my code, somewhere in libnl). It's *possible* Kismet is setting up something wrong before calling libnl, but that doesn't happen anywhere else and I've never seen it before, which makes me think it isn't the Kismet code.

Here's a few things to try:

1 - `make distclean' in your kismet svn source dir, reconfigure, recompile, reinstall. It's possible sometimes for things to get weird and then nothing works right in inexplicable ways.

2 - Upgrade to the latest drivers. Most distributions should have some version of the compat-wireless package, check google for yours. has directions for Ubuntu aready. This will upgrade your wifi drivers to the latest development code.

3 - if you don't want to, or can't, or whatever, upgrade your wifi drivers, try setting a manual channel list in Kismet. Edit kismet_server.conf, copy the 802.11g channel list, add whatever other stuff you want (11a, etc) then define your source with a custom channel list. (ncsource=wlan0:channellist=customlist). That should at least bypass the part of the code that queries the supported channels via netlink.

I'd be curious which of the three you end up doing, and if you find out anything else let me know. I'll doublecheck the netlink calling code, but it really has never caused an issue like this before.


Reply to this message