Pretty sure no source is needed, just WEXT. However there have been several
reports that kismet doesn't agree with ZD1211's policy on channel changing.

Ulrich:

iw_set_freq() in zd_netdev.c does this:

	u8 channel;
	r = zd_find_channel(&channel, freq);
	if (r < 0)
		return r;
	r = zd_mac_request_channel(mac, channel);

zd_find_channel() in zd_ieee80211.c does this:

int zd_find_channel(u8 *channel, const struct iw_freq *freq)
{
	int i, r;
	u32 mhz;

	if (!(freq->flags & IW_FREQ_FIXED)) {
		return 0;
	}

So, when IW_FREQ_FIXED is set, zd_find_channel returns 0 and does not modify
channel. We then pass some uninitialized value to zd_mac_request_channel(). This
is bad.

In my tests this usually makes it end up requesting channel 177 which is not
part of the regdomain so it gets rejected from inside zd_mac_request_channel():

	if (!zd_regdomain_supports_channel(mac->regdomain, channel)) {
		spin_unlock_irqrestore(&mac->lock, lock_flags);
		return -EINVAL
	}

This is why kismet is failing.

Source 0 (eth3): Enabling monitor mode for bcm43xx source interface eth3 channel
6...
FATAL: Failed to set channel 6 22:Invalid argument

kismet makes no effort to set the flags attribute of the request, it leaves it as 0.

I've done some reading of this thread:
http://marc.theaimsgroup.com/?t=114518684400001&r=1&w=2

And the whole fixed vs auto thing really isn't clear to me, but I'll post a
first attempt at a fix shortly...

Changed my mind slightly. I found the description of "iwconfig freq auto" in the
iwconfig man page. I guess the behavior is expected to be something like:

In monitor mode, auto is meaningless, you'd only ever accepted fixed plus a
frequency to change to.
In managed mode, all SIWFREQ calls would be rejected
In ad-hoc mode before cell join/creation, SIWFREQ is accepted as fixed plus a
frequency, or "auto" in which case it might find the quietest channel (or reject it)
In master mode, SIWFREQ is accepted as fixed plus a frequency, or "auto" in
which case it might find the quietest channel (or reject it)

Given that our current implementation of IW_FREQ_AUTO is incomplete and broken,
I think we should drop it for now. We could always implement a true AUTO scheme
later, although it is really something that should be done in userspace, plus we
have a new 802.11 stack and configuration mechanism under development...

The next question is: should we reject AUTO or simply ignore it? I think we
should ignore it, like all other wireless drivers do (yes, not one in-kernel
driver has IW_FREQ_AUTO support). This has the added advantage that kismet will
work.

At the same time, it is clearly a kismet bug that it is not setting flags to
IW_FREQ_FIXED.

Created attachment 9541 [details]
zd1211rw patch

Ignore flags in SIWFREQ and GIWFREQ

Created attachment 9542 [details]
kismet patch

use IW_FREQ_FIXED flag when changing channel
I'll send this to the kismet maintainer tomorrow

Tried both with nos success. Kismet isn't crashing anymore but I can't get my 
zd1211 device in monitoring mode and kismet didn't recognize sort changing.
I've tried the zd1211 kismet source on 2.6.19-rc6

Please provide actual info - what are the error messages? Which commands are you
using? And try the bcm43xx source.

Patch is now in wireless-dev and netdev trees