Kismet Wireless

Kismet Forums


Posted by:dragorn
Subject:orinoco source availability stable vs. newcore
Date:15:55:57 13/05/2009

> It's not a capture issue. I've compiled both 2008_05_R1 and newcore with the same toolchain for a cross-compile target. Assuming the interface is up, the R1 server initializes it and begins capturing normally (source=orinoco,wlan1,Linksys). The newcore version uses "ncsource=null" or "ncsource=wlan1:type=orinoco", with the first source config it fails with "ERROR: Failed to find a type for auto-type source 'null', you will have to tell

You're running old config files, you shouldn't have a ncsource=null line in there (which of course will not work).

The fact that you're seeing fatal exiting errors implies you're also not using current code, even completely misdefined sources are only an error case now which will not cause kismet to exit.

Newcore most definitely has driver entries for 'orinoco' and 'orinoco_cs'. I don't know if it can autodetect - it depends on the driver making proper entries in /sys.

Those errors make me think either you're missing compile-time stuff, or you don't have the latest newcore code.

> I've noticed that the R1 configure output indicates "Linux Netlink capture: yes" but that the configure output for newcore lists "... no" for all the "checking for netlink*" statements. At this point I think it's probably a build-time discrepency.

Totally different things. Stable still included tests to use the ancient netlink capture from wlan-ng. Newcore uses libnl to do netlink control of channels and VAP setup on mac80211 drivers.

And finally, that card you're using isn't an orinoco/hermes device, it's a prism2, and you probably ought to be using the hostap drivers which are designed for it, instead of the orinoco, which kind of support it but may still have timing issues (this has been a years-long debate and we still have a prism2 native driver, hostap, so that's probably the right one to be using.)


Reply to this message