Here is what I get:
With the old bcm43xx (softmac) driver, iwconfig returns "Operation not
permitted" for "iwconfig <card> channel 14". Kismet's backend process
crashes if I set its channel hopping range to include channel 14.
NetworkManager and iwlist scan doesn't scan on ch14. Channels 12 and 13 are
not affected, only the Japanese channel 14. Channels 1 through 13 work fine,
I can scan, associate, transmit, receive, even monitor mode works.
With the new mac80211 driver (b43), things are a bit more complicated: When
mac80211 (or cfg80211 on wireless-testing) is loaded without
ieee80211_regdom, iwconfig goes up to channel 11, after that, "Operation not
permitted". Kismet doesn't crash though, it just prints an error when it
tries to switch to a channel over 11. NetworkManager and iwlist scan skips
channels 12, 13 and 14. Loading {mac|cfg}80211 with ieee80211_regdom=64
(which is Japan AFAIK, so it should allow 14 channels) makes channels 12 and
13 work to some extent, but not channel 14. Iwconfig works up to ch13, while
ch14 gives "Operation not permitted". Kismet goes into channel 12 and 13
nicely, but crashes on channel 14. (It doesn't crash, only throws an error
when {mac|cfg}80211 is loaded without ieee80211_regdom.)
Iwlist/NetworkManager scan like with bcm43xx. The different errors of Kismet
suggest a regional lockout on the hardware, which is likely specific to this
card, and not present on non-Asus 4318s. Maybe there is a protection/"cop"
chip connected to the radio, I don't know as I haven't removed the cover of
the radio.
However, this is a heavy digression from the thread's topic. The biggest
problem is that regardless of ieee80211_regdom, only scanning and monitor
mode (that is, tasks that only require receiving data, not transmitting)
work, anything that requires transmitting (association, packet injection
with Packetspammer, software AP mode) is broken. The card's LED doesn't show
activity when it tries to transmit, and I fail to capture Packetspammer's
test packets on another interface. When trying to associate, dmesg shows
"Authentication with <BSSID>" 3 or 4 times, then "Authentication with
<BSSID> timed out". No "PHY Transmission Error"s, and in general, no b43
errors (or even warnings) show up, even if I compile b43 with debugging
enabled. This error shows up with all kernels I tested, including
wireless-testing and 2.6.24. This might be a mac80211 problem, as on
wireless-testing, a similar error affected my rt73 USB dongle. Judging from
the fact that the card's LED doesn't blink while transmitting/trying to
transmit (as it does on Windows), even though I compiled my kernel with LED
support enabled, I suspect that the card doesn't even try to transmit. The
problem is not unique to me, as Szilveszter Erdeg (another Hungarian, with
an EU WL-138G V2) has the same problem. Likely the US version of the 138G is
identical to the Japanese one, only the EU version has the lockout, so the 2
problems might be related.
On Mon, Mar 17, 2008 at 1:29 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Monday 17 March 2008 13:22:02 Stefanik Gábor wrote:
> > I got that with bcm43xx (not b43!), which is ieee80211-softmac-based.
> AFAIK
> > that defaults to Japan, yet it doesn't let me switch to channel 14.
> Channel
> > 13 works fine, though. (In bcm43xx. In b43, nothing works.) (This
> message is
> > a repost of my previous message that I accidentally sent to Johannes
> Berg
> > only.)
>
> The hardware does not limit the channel. The firmware hardly knows about
> the current channel anyway. It just makes sure that packets are
> transmitted on
> the currently selected channel. No matter which one that is.
>
> But what does it mean when you say "it doesn't let me switch to channel
> 14"?
> Does it return an error code, or does iwconfig report success, but it
> doesn't
> _work_ on channel 14? That would make a major difference to debug this
> problem.
>
> --
> Greetings Michael.
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
_______________________________________________
Bcm43xx-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
