Re: timeout problems with certain APs and b43
John H. wrote: > wrt54gs with latest firmware. > > it seems exclusive to linux:O > > On Nov 21, 2007 4:18 PM, Larry Finger <[EMAIL PROTECTED]> wrote: >> John H. wrote: >>> uname -a >>> Linux laptop 2.6.23.1-49.fc8 #1 SMP Thu Nov 8 21:41:26 EST 2007 i686 >>> i686 i386 GNU/Linux >>> fedora 8 >>> >>> on certain APs, the internet works for a long time then stops, and I >>> get authentication time outs, why? It usually works again if I reset >>> the AP itself, which i should not have to do and don't have to if in >>> XP >>> >>> >>> wlan0: switched to long barker preamble (BSSID=00:0f:66:53:3e:24) >>> wlan0: switched to short barker preamble (BSSID=00:0f:66:53:3e:24) >>> >>> >>> >>> wlan0: Initial auth_alg=0 >>> wlan0: authenticate with AP 00:0f:66:53:3e:24 >>> wlan0: authenticate with AP 00:0f:66:53:3e:24 >>> wlan0: authenticate with AP 00:0f:66:53:3e:24 >>> wlan0: authentication with AP 00:0f:66:53:3e:24 timed out >> Do you have the opportunity to capture the wireless traffic with a second >> computer using Kismet or >> Wireshark when this condition occurs? Without that info, it would be hard to >> know what might be >> wrong. Of course, I don't have the problem with either of my AP's. >> >> Could you identify the make/model and firmware revisions of any AP's that >> show this behavior? Please do not top post! The problem is not generic with Linksys AP's. I use a WRT54GL V1.1 and a WRT54G V5. Neither shows the problem. We need a dump of the wireless traffic when this condition occurs. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
Michael Buesch wrote:
>
> partially acked.
> Though, I'm not quite sure yet why you remove that
> address extension bits. The specs clearly say that they _are_ there.
> And it makes sense to use them, as two bytes of the address are used
> for the routing stuff. So the highest 2 bits of the address have to be put
> somewhere else. That's the "Transmit Channel Control Word" and
> "Receive Channel Control Word" where 0x0003 are the extension bits.
>
The appropriate section of dmacontroller_setup() in my patched source is as
follows:
if (ring->tx) {
if (ring->dma64) {
u64 ringbase = (u64) (ring->dmabase);
b43_dma_write(ring, B43_DMA64_TXCTL,
B43_DMA64_TXENABLE);
b43_dma_write(ring, B43_DMA64_TXRINGLO,
(ringbase & 0x));
b43_dma_write(ring, B43_DMA64_TXRINGHI,
(ringbase >> 32));
} else {
.. untouched 32-bit stuff
}
} else {
err = alloc_initial_descbuffers(ring);
if (err)
goto out;
if (ring->dma64) {
u64 ringbase = (u64) (ring->dmabase);
value = (ring->frameoffset << B43_DMA64_RXFROFF_SHIFT)
| B43_DMA64_RXENABLE;
b43_dma_write(ring, B43_DMA64_RXCTL, value);
b43_dma_write(ring, B43_DMA64_RXRINGLO,
(ringbase & 0x));
b43_dma_write(ring, B43_DMA64_RXRINGHI,
(ringbase >> 32));
b43_dma_write(ring, B43_DMA64_RXINDEX, ring->nr_slots *
sizeof(struct b43_dmadesc64));
} else {
... 32-bit stuff
}
No address extensions are used here because the specs clearly state that a flat
64-bit address is
used to specify the Descriptor Ring address. My code matches the specs.
In the 64-bit fill_descriptor routine, the my patches result in the following
code:
addrlo = (u32) (dmaaddr & 0x);
addrhi = (((u64) dmaaddr >> 32) & ~SSB_DMA_TRANSLATION_MASK);
addrext = (((u64) dmaaddr >> 32) & SSB_DMA_TRANSLATION_MASK)
>> SSB_DMA_TRANSLATION_SHIFT;
addrhi |= (ssb_dma_translation(ring->dev->dev) << 1);
if (slot == ring->nr_slots - 1)
ctl0 |= B43_DMA64_DCTL0_DTABLEEND;
if (start)
ctl0 |= B43_DMA64_DCTL0_FRAMESTART;
if (end)
ctl0 |= B43_DMA64_DCTL0_FRAMEEND;
if (irq)
ctl0 |= B43_DMA64_DCTL0_IRQ;
ctl1 |= (bufsize - ring->frameoffset)
& B43_DMA64_DCTL1_BYTECNT;
ctl1 |= (addrext << B43_DMA64_DCTL1_ADDREXT_SHIFT)
& B43_DMA64_DCTL1_ADDREXT_MASK;
In this case, the specs do call for the upper two bits to be masked off the
high 32 bits of the
address to be used for the routing code. These are saved in 'addrext' above.
The routing bits, which
must be '10' for the 64-bit case, are then shifted into that 2-bit field, and
the masked address
bits are encoded into the second control word 'ctl1' in the above snippet. As
far as I can tell, my
code is doing exactly what the specs require - address extensions and all. If
not, please show me
the error.
> However I do think that this might be related to the bug you are explaining
> in the comment:
>> + * For unknown reasons - possibly a hardware error - the BCM4311 rev
>> + * 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
>> + * which accounts for the GFP_DMA flag below.
>
Not true for two reasons. The first one is that it is the address of the ring
buffer that is getting
the error, and that part does not use any extension bits. Secondly, the address
extension stuff
would only apply if my computer had more than 2^(62) bytes of RAM, which is
something like 10
billion GB - an amount that probably exceeds the total RAM in the world. As
best I can tell, this
bug triggers when the Ring Buffer is placed above the 64-Megabyte level.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 regression: doesn't associate automatically
On Thu, 2007-11-22 at 18:18 -0700, Ehud Gavron wrote: > 2. dmesg repeats: wlan0: authentication with AP 00:50:bf:b1:da:64 timed out I think it's an unrelated hardware specific issue. mac80211 tried to associate but failed. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 regression: doesn't associate automatically
I think this may be related. If it isn't, my apologies for thread crapping. If it is, I'm willing to do what I can to help find the problem and correct it. I've had occasional troubles with all sorts of association related issues, and the only solution I've found is to remove the b43 module and reinsert it. (modprobe -r b43 && sleep 1 && modprobe b43). Here are different scenarios that are 100% reproducable: FYI All of my house uses the same ESSID with the same WEP key and different channels (1,6,11 from one end to the other). If I move from the living room (Ch1) to the bedroom (Ch11) then I am still associated to the Living Room AP. ***SOMETIMES*** a "iwconfig wlan0 ap off" will make it reassociate with the bedroom AP ***NEVER*** does an "iwconfig wlan0 essid same-essid" do anything ***SOMETIMES*** does an "iwconfig wlan0 essid no-such-essid && sleep 1 && iwconfig wlan0 essid origina-essid" works ***ALWAYS*** "modprobe -r b43 && sleep 1 && modprobe b43" works If I move from the bedroom (Ch11) to the living room (Ch1) I DON'T NEED TO DO ANYTHING. All APs are buffalo airbridges with the same rev firmware. I find similar symptoms at my Las Vegas hotel where I am this weekend. Here are the exact symptoms: 1. Link quality reads 0. No iwconfig command will fix it (most of the time, sometimes the change of ESSID or ap off will fix it). 2. dmesg repeats: wlan0: authentication with AP 00:50:bf:b1:da:64 timed out 3. an iwlist wlan0 scan DOES show the active APs, but no matter which I choose none will associate 4. I just upgraded to F8 and am now using NM to manage the link (most of the time). Most of the time it does work but every now and then (like here at the hotel after I rebooted the laptop) it will fail to connect. Symptoms #1 and #2 appear in the log, and the "modprobe -4/modprobe" fixes it. I'm not sure if this is a mac80211 or a b43 bug... and if anyone has ideas to try I'm game. Ehud Pavel Roskin wrote: > On Thu, 2007-11-22 at 08:26 -0500, John W. Linville wrote: > > >> As it stands, setting the SSID is the closest thing we have to an >> "associate now" trigger. I would have to advise distros and users to >> always set it last in the wireless init, just before running dhclient >> or whatever. >> > > Maybe mac80211 should have a "grace period" of 0.5 seconds or so to > allow other settings to be set before the scanning starts? The same > applies to other events causing scanning, such as bringing up the > interface. It's too short to be noticeable, yet long enough for the > next command to run even on slow systems. > > I think setting the key should not cause reassociation if there is an > association. It can break some schemes where the WEP key changes > periodically on both sides. > > ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 regression: doesn't associate automatically
On Thu, 2007-11-22 at 08:26 -0500, John W. Linville wrote: > As it stands, setting the SSID is the closest thing we have to an > "associate now" trigger. I would have to advise distros and users to > always set it last in the wireless init, just before running dhclient > or whatever. Maybe mac80211 should have a "grace period" of 0.5 seconds or so to allow other settings to be set before the scanning starts? The same applies to other events causing scanning, such as bringing up the interface. It's too short to be noticeable, yet long enough for the next command to run even on slow systems. I think setting the key should not cause reassociation if there is an association. It can break some schemes where the WEP key changes periodically on both sides. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43: Changes to enable BCM4311 rev 02 with wireless core revision 13
On Wednesday 21 November 2007 22:38:12 Larry Finger wrote:
> The BCM94311MCG rev 02 chip has an 802.11 core with revision 13 and
> has not been supported until now. The changes include the following:
>
> (1) Add the 802.11 rev 13 device to the ssb_device_id table to load b43.
> (2) Add PHY revision 9 to the supported list.
> (3) Fix 64-bit addressing errors.
> (4) Remove some magic numbers in the DMA setup.
>
> The DMA implementation for this chip supports full 64-bit addressing with
> one exception. Whenever the Descriptor Ring Buffer is in high memory, a
> fatal DMA error occurs. This problem was not present in 2.6.24-rc2 due
> to code to "Bias the placement of kernel pages at lower PFNs". When
> commit 44048d70 reverted that code, the DMA error appeared. As a "fix",
> use the GFP_DMA flag when allocating the buffer for 64-bit DMA. At present,
> this problem is thought to arise from a hardware error.
>
> This patch has been tested on my system and by Cédric Caumont
> <[EMAIL PROTECTED]>.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
> ---
>
> John,
>
> This patch is intended for the everything branch of wireless-2.6.
>
> Larry
> ---
>
> dma.c | 50 ++
> main.c |3 ++-
> wa.c |1 +
> 3 files changed, 29 insertions(+), 25 deletions(-)
>
> Index: wireless-2.6/drivers/net/wireless/b43/dma.c
> ===
> --- wireless-2.6.orig/drivers/net/wireless/b43/dma.c
> +++ wireless-2.6/drivers/net/wireless/b43/dma.c
> @@ -165,7 +165,7 @@ static void op64_fill_descriptor(struct
> addrhi = (((u64) dmaaddr >> 32) & ~SSB_DMA_TRANSLATION_MASK);
> addrext = (((u64) dmaaddr >> 32) & SSB_DMA_TRANSLATION_MASK)
> >> SSB_DMA_TRANSLATION_SHIFT;
> - addrhi |= ssb_dma_translation(ring->dev->dev);
> + addrhi |= (ssb_dma_translation(ring->dev->dev) << 1);
> if (slot == ring->nr_slots - 1)
> ctl0 |= B43_DMA64_DCTL0_DTABLEEND;
> if (start)
> @@ -426,9 +426,21 @@ static inline
> static int alloc_ringmemory(struct b43_dmaring *ring)
> {
> struct device *dev = ring->dev->dev->dev;
> + gfp_t flags = GFP_KERNEL;
>
> + /* The specs call for 4K buffers for 30- and 32-bit DMA with 4K
> + * alignment and 8K buffers for 64-bit DMA with 8K alignment. Testing
> + * has shown that 4K is sufficient for the latter as long as the buffer
> + * does not cross an 8K boundary.
> + *
> + * For unknown reasons - possibly a hardware error - the BCM4311 rev
> + * 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
> + * which accounts for the GFP_DMA flag below.
> + */
> + if (ring->dma64)
> + flags = GFP_DMA;
> ring->descbase = dma_alloc_coherent(dev, B43_DMA_RINGMEMSIZE,
> - &(ring->dmabase), GFP_KERNEL);
> + &(ring->dmabase), flags);
> if (!ring->descbase) {
> b43err(ring->dev->wl, "DMA ringmemory allocation failed\n");
> return -ENOMEM;
> @@ -483,7 +495,7 @@ int b43_dmacontroller_rx_reset(struct b4
> return 0;
> }
>
> -/* Reset the RX DMA channel */
> +/* Reset the TX DMA channel */
> int b43_dmacontroller_tx_reset(struct b43_wldev *dev, u16 mmio_base, int
> dma64)
> {
> int i;
> @@ -636,18 +648,12 @@ static int dmacontroller_setup(struct b4
> if (ring->dma64) {
> u64 ringbase = (u64) (ring->dmabase);
>
> - addrext = ((ringbase >> 32) & SSB_DMA_TRANSLATION_MASK)
> - >> SSB_DMA_TRANSLATION_SHIFT;
> - value = B43_DMA64_TXENABLE;
> - value |= (addrext << B43_DMA64_TXADDREXT_SHIFT)
> - & B43_DMA64_TXADDREXT_MASK;
> - b43_dma_write(ring, B43_DMA64_TXCTL, value);
> + b43_dma_write(ring, B43_DMA64_TXCTL,
> + B43_DMA64_TXENABLE);
> b43_dma_write(ring, B43_DMA64_TXRINGLO,
> (ringbase & 0x));
> b43_dma_write(ring, B43_DMA64_TXRINGHI,
> - ((ringbase >> 32) &
> -~SSB_DMA_TRANSLATION_MASK)
> - | trans);
> + (ringbase >> 32));
> } else {
> u32 ringbase = (u32) (ring->dmabase);
>
> @@ -668,20 +674,15 @@ static int dmacontroller_setup(struct b4
> if (ring->dma64) {
> u64 ringbase = (u64) (ring->dmabase);
>
> - addrext = ((ringbase >> 32) & SSB_DMA_TRANSLATION_MASK)
> - >> SSB_DMA_TRANSLATION_SHIFT;
> - value = (ring->frameoffset << B43_DMA64_RXFROFF_SHIFT);
> - val
Re: Instability with 4318 chip
Alexander Koeppe wrote: > Hello list, > > > I'm using Gentoo Linux (2.6.23) on a Apple iBook and was very happy that > my wireless chip is supported. > After installation everything seems to be OK and working fine. > But when the distance to my AP ascends to more than 4 meters, the > connection seems to be down or unstable. Sometimes its also unstable at > a distance of 2 meters. > I also changed the transmission channel on my AP without result. > > I investigated a bit using wireshark and found that the device is > sending ARP who-is broadcast packets that are not seen on the normal > cable network , where it should be normally because no L3 device > between. So transmission gives up because my notebook is'nt able to find > the correct MAC address for the a desired IP. > > I searched the net and found that the driver in relation with the 4318 > chipset has some transmission issues but a fix has been announced for > the 2.6.19 kernel release. > > Is there something I can do? You can start by telling us what kernel you are using (uname -r) and the results of 'dmesg | grep bcm' and 'dmesg | grep b43'. I'm sorry, but I do not know what kernel every distro is using. All versions of bcm43xx has some problems with the 4318. Only with b43 were those problems fixed. That driver does not appear in mainline until 2.6.24. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 regression: doesn't associate automatically
On Thu, Nov 22, 2007 at 02:05:52PM +0100, Johannes Berg wrote: > > Note that the same happens if I let Debian manage the card. An excerpt > > from my /etc/network/interfaces shows: > > That sucks, I guess debian's scripts need to be fixed. As it stands, setting the SSID is the closest thing we have to an "associate now" trigger. I would have to advise distros and users to always set it last in the wireless init, just before running dhclient or whatever. John -- John W. Linville [EMAIL PROTECTED] ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: mac80211 regression: doesn't associate automatically
First off, let me state that I don't think this is a regression. > $ iwconfig eth1 essid BLAHMUMPF > HW CONFIG: channel=1 freq=2412 phymode=2 [...] As you can see, it doesn't find anything that matches the current configuration. > $ iwconfig eth1 key s:1 > b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: > ff:ff:ff:ff:ff:ff You've now enabled a key, but not told it to associate using that key. > As you can see, I'm not associated. However, this sequence used > to work with non-mac80211 based WLAN drivers. However, I can actually > associate if I reverse the essid/key, e.g. first set the key, then > the ssid. Can't say that matters since wext is actually sufficiently undefined to allow both behaviours. :) I'm strongly against changing the behaviour in mac80211 because wext is sufficiently undefined that once we accept one of these things we'll have a HUGE mess of code because all sorts of wext ioctls affect possible association etc. > Note that the same happens if I let Debian manage the card. An excerpt > from my /etc/network/interfaces shows: That sucks, I guess debian's scripts need to be fixed. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Request for information regarding BCM94311MCG rev 02
> > You said before that we should be fine allocating the DMA rings below > > 1GB and then doing arbitrary DMA buffers. If this is the case, then imho > > we should just do that, the six DMA rings or whatever we should be able > > to fit into low memory. > > No it isn't right. When I booted with a mem=512M option, the DMA error still > occurred as long as I > didn't allocate the ring buffer with the GFP_DMA flag. Allocating below the 1 > GB boundary is not > sufficient. > It may be even worse. They seem to have made this device look like an ISA > device and force the ring > buffer to below the 16 MB boundary. Hmm. No, that definitely doesn't make sense. There must be something else going wrong like bad windowing in the PCI(e) core. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Instability with 4318 chip
On Thu, 22 Nov 2007, Alexander Koeppe wrote: > I'm using Gentoo Linux (2.6.23) on a Apple iBook and was very happy that > my wireless chip is supported. > After installation everything seems to be OK and working fine. > But when the distance to my AP ascends to more than 4 meters, the > connection seems to be down or unstable. Sometimes its also unstable at > a distance of 2 meters. > I also changed the transmission channel on my AP without result. Are you using the bcm43xx driver? If so, you might want to try downloading the wireless-2.6 kernel tree and compiling the b43 driver which now supercedes bcm43xx and is considerably more stable. # get a copy of the tree git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git cd wireless-2.6 # checkout all the other stuff git checkout -b everything # copy your existing kernel config cp /boot/configx .config make menuconfig # make sure the bcm driver is configured as a module make sudo make install though there may be a tidier way to compile kernels into packages on gentoo, I'm not sure. Then you need to follow the firmware installation procedure for b43 (which uses a different cutter program and a newer firmware). http://linuxwireless.org/en/users/Drivers/b43 Gavin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Instability with 4318 chip
Hello list, I'm using Gentoo Linux (2.6.23) on a Apple iBook and was very happy that my wireless chip is supported. After installation everything seems to be OK and working fine. But when the distance to my AP ascends to more than 4 meters, the connection seems to be down or unstable. Sometimes its also unstable at a distance of 2 meters. I also changed the transmission channel on my AP without result. I investigated a bit using wireshark and found that the device is sending ARP who-is broadcast packets that are not seen on the normal cable network , where it should be normally because no L3 device between. So transmission gives up because my notebook is'nt able to find the correct MAC address for the a desired IP. I searched the net and found that the driver in relation with the 4318 chipset has some transmission issues but a fix has been announced for the 2.6.19 kernel release. Is there something I can do? Cheers Alex ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
mac80211 regression: doesn't associate automatically
I'm on wireless-2.6, branch everything, git commit 7446b6c0e3b18fd2c5f9c406bb20841e6193d058 When I insert a b43 based card, I don't get associated automatically. This happens: $ # Insert the card pccard: CardBus card inserted into slot 0 PCI: Enabling device :03:00.0 ( -> 0002) ACPI: PCI Interrupt :03:00.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device :03:00.0 to 64 ssb: SPROM revision 1 detected. ssb: Sonics Silicon Backplane found on PCI device :03:00.0 b43-phy0: Broadcom 4306 WLAN found b43-phy0 debug: Found PHY: Analog 2, Type 2, Revision 2 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 phy0: Selected rate control algorithm 'simple' $ ifconfig eth1 up b43-phy0 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) b43-phy0 debug: Chip initialized b43-phy0 debug: 30-bit DMA initialized b43-phy0 debug: Wireless interface started b43-phy0 debug: Adding Interface type 2 $ iwconfig eth1 essid BLAHMUMPF HW CONFIG: channel=1 freq=2412 phymode=2 HW CONFIG: channel=2 freq=2417 phymode=2 HW CONFIG: channel=3 freq=2422 phymode=2 HW CONFIG: channel=4 freq=2427 phymode=2 HW CONFIG: channel=5 freq=2432 phymode=2 HW CONFIG: channel=6 freq=2437 phymode=2 HW CONFIG: channel=7 freq=2442 phymode=2 HW CONFIG: channel=8 freq=2447 phymode=2 HW CONFIG: channel=9 freq=2452 phymode=2 HW CONFIG: channel=10 freq=2457 phymode=2 HW CONFIG: channel=11 freq=2462 phymode=2 HW CONFIG: channel=1 freq=2412 phymode=2 $ iwconfig eth1 key s:1 b43-phy0 debug: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff $ iwconfig eth1 eth1 IEEE 802.11g ESSID:"BLAHMUMPF" Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Tx-Power=27 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:3131-3131-31 Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 As you can see, I'm not associated. However, this sequence used to work with non-mac80211 based WLAN drivers. However, I can actually associate if I reverse the essid/key, e.g. first set the key, then the ssid. Note that the same happens if I let Debian manage the card. An excerpt from my /etc/network/interfaces shows: allow-hotplug eth1 iface eth1 inet static address 10.2.1.3 netmask 255.255.255.0 wireless-essid BLAHMUMPF wireless-key1 s:1 (the test above has been made completely manually, without this entry) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
