b43 on gutsy using 2.6.24 doesn't work
Hi,
i just can't get my wlan work properly on my extensa 5220.
Here's a bunch of information about my notebook.
uname -r
2.6.24-8-generic
lspci | grep -i netw
04:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI
(rev 01)
dmesg | grep b43
[ 34.924306] b43-phy0: Broadcom 4311 WLAN found
[ 40.414718] input: b43-phy0 as /devices/virtual/input/input9
[ 42.491768] Registered led device: b43-phy0:tx
[ 42.491789] Registered led device: b43-phy0:rx
[ 42.491806] Registered led device: b43-phy0:radio
dmesg | grep -i wlan
[ 34.924306] b43-phy0: Broadcom 4311 WLAN found
[ 51.908877] ADDRCONF(NETDEV_UP): wlan0: link is not ready
ifconfig
eth0 Protokoll:Ethernet Hardware Adresse 00:1D:72:0C:BD:FB
inet Adresse:192.168.123.101 Bcast:192.168.123.255 Maske:
255.255.255.0
inet6 Adresse: fe80::21d:72ff:fe0c:bdfb/64
Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9667 errors:0 dropped:0 overruns:0 frame:0
TX packets:5021 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:12138424 (11.5 MB) TX bytes:580582 (566.9 KB)
Interrupt:16
loProtokoll:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
wlan0 Protokoll:Ethernet Hardware Adresse 00:1E:4C:4E:15:14
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
wmaster0 Protokoll:UNSPEC Hardware Adresse
00-1E-4C-4E-15-14-00-00-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
iwconfig
lono wireless extensions.
eth0 no wireless extensions.
irda0 no wireless extensions.
wmaster0 no wireless extensions.
wlan0 IEEE 802.11g ESSID:
Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated
Tx-Power=27 dBm
Retry min limit:7 RTS thr:off Fragment thr=2346 B
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
sudo iwlist scan
loInterface doesn't support scanning.
eth0 Interface doesn't support scanning.
irda0 Interface doesn't support scanning.
wmaster0 Interface doesn't support scanning.
wlan0 Scan completed :
Cell 01 - Address: 00:C0:49:E3:59:B6
ESSID:HONOLULU
Mode:Master
Channel:8
Frequency:2.447 GHz (Channel 8)
Quality=90/100 Signal level=-45 dBm Noise level=-67
dBm
Encryption key:off
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 22 Mb/s
6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
36 Mb/s; 48 Mb/s; 54 Mb/s
Extra:tsf=00b5c96d4121
cat /etc/network/interfaces
auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0
iface wlan0 inet dhcp
wireless-rate 11M
wireless-essid HONOLULU
cat /etc/udev/rules.d/70-persistent-net.rules
# This file maintains persistent names for network interfaces.
# See udev(7) for syntax.
#
# Entries are automatically added by the 75-persistent-net-generator.rules
# file; however you are also free to add your own entries.
# PCI device 0x14e4:0x1693 (tg3)
SUBSYSTEM==net, DRIVERS==?*, ATTRS{address}==00:1d:72:0c:bd:fb,
NAME=eth0
# PCI device 0x14e4:0x4311 (b43-pci-bridge)
SUBSYSTEM==net, DRIVERS==?*, ATTRS{address}==00:1e:4c:4e:15:14,
ATTRS{type}==1, NAME=wlan0
sudo dhclient wlan0
There is already a pid file /var/run/dhclient.pid with pid 134519120
Internet Systems Consortium DHCP Client V3.0.5
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
wmaster0: unknown hardware address type 801
wmaster0: unknown hardware address type 801
Listening on LPF/wlan0/00:1e:4c:4e:15:14
Sending on LPF/wlan0/00:1e:4c:4e:15:14
Sending on Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER
Re: b43 on gutsy using 2.6.24 doesn't work
ext Peter Diesner wrote: Hi, i just can't get my wlan work properly on my extensa 5220. Here's a bunch of information about my notebook. [...] dmesg | grep b43 [ 34.924306] b43-phy0: Broadcom 4311 WLAN found [ 40.414718] input: b43-phy0 as /devices/virtual/input/input9 [ 42.491768] Registered led device: b43-phy0:tx [ 42.491789] Registered led device: b43-phy0:rx [ 42.491806] Registered led device: b43-phy0:radio There is a debug option in the kernel configuration that can be enabled for this module (sorry, I don't remember the name, but it's in the same place as the other b43 related options). That will provide more information. Ciao, Alberto -- http://www.mardy.it -- Geek in un lingua international! ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Cannot associate (4318 on HP laptop)
ext Alberto Mardegan wrote: wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:13:49:68:98:85 wlan0: authenticate with AP 00:13:49:68:98:85 wlan0: authenticate with AP 00:13:49:68:98:85 wlan0: authentication with AP 00:13:49:68:98:85 timed out A short follow-up: a user suggested me to move closer to the AP. That made it to work (and NetworkManager reported full signal power, which is hard to believe since I moved only one metre aside). But unfortunately that's not a feasible setup for me, and I had to switch back to ndiswrapper. It's kind of strange to me though, since I'm only 4 metres away from the AP! Ciao, Alberto -- http://www.mardy.it -- Geek in un lingua international! ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH RFT] b43: Fix beaconing
On Thu, 2008-02-21 at 17:57 +0100, Michael Buesch wrote: Can you please test if this fixes beaconing? Hmm, unfortunately not. This results in continuous beacon update interrupts because when both templates are valid we keep them valid all the time. Hence, it's not usable. I really wonder wtf. is going on. Why do we even have two beacon templates if we can't mark them both as valid at the same time? My earlier debugging change marked only the first one ever valid and that seems to work because the machine is fast enough... Basically, I think the machine has to always be fast enough to upload a beacon template within a beacon interval. That's pretty much guaranteed though so no big deal. I guess the only reason why there are two beacon templates is the processing latency. When the beacon template ready (for modification by host) interrupt comes in, we might only get to process it even later than that, and the ucode might need another beacon rather quickly. It needs to be guaranteed that the ucode has another beacon before it needs to send one, so the latency must not be higher than the beacon interval, but that should be fine. If we have to then change/upload the beacon though, maybe the thinking is that the latency combined with the template RAM write might be long enough to not allow uploading the complete beacon again before the next one is needed. Hence, the ability to upload both and with a just one MMIO read and write switch to the second one before uploading the first. I think what we should do is this: * we upload both beacon templates whenever we control them and it's necessary * however, we only mark one of them as hardware valid Then, when the beacon template ready (for modification by host) interrupt comes in, we check for which one the interrupt came in and mark the other template as valid immediately. This allows us to mark it *really* quickly, ie. with just a single MMIO read/write and could be done even in the interrupt handler itself. Then, we can lazily see later if we need to change the beacon template data and upload that without having too much timing pressure. Then, on the next interrupt, we switch to this one etc. 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: [PATCH RFT] b43: Fix beaconing
On Friday 22 February 2008 14:16:06 Johannes Berg wrote: On Thu, 2008-02-21 at 17:57 +0100, Michael Buesch wrote: Can you please test if this fixes beaconing? Hmm, unfortunately not. This results in continuous beacon update interrupts because when both templates are valid we keep them valid all the time. Hence, it's not usable. I really wonder wtf. is going on. Why do we even have two beacon templates if we can't mark them both as valid at the same time? I _guess_ they have two templates to update them round-robin. So if you need one updated, the microcode still has a copy of the old one to use in the other template. Just a guess, but makes sense to me. I think what we should do is this: * we upload both beacon templates whenever we control them and it's necessary * however, we only mark one of them as hardware valid Then, when the beacon template ready (for modification by host) interrupt comes in, we check for which one the interrupt came in and mark the other template as valid immediately. This allows us to mark it *really* quickly, ie. with just a single MMIO read/write and could be done even in the interrupt handler itself. Then, we can lazily see later if we need to change the beacon template data and upload that without having too much timing pressure. Then, on the next interrupt, we switch to this one etc. tricky :) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Cannot associate (4318 on HP laptop)
On Fri, 2008-02-22 at 14:45 +0200, Alberto Mardegan wrote: ext Alberto Mardegan wrote: wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:13:49:68:98:85 wlan0: authenticate with AP 00:13:49:68:98:85 wlan0: authenticate with AP 00:13:49:68:98:85 wlan0: authentication with AP 00:13:49:68:98:85 timed out A short follow-up: a user suggested me to move closer to the AP. That made it to work (and NetworkManager reported full signal power, which is hard to believe since I moved only one metre aside). The problem is, this driver is written only from reverse engineered data, but the device needs a lot of attention from the host software. Many things just cannot be implemented without a good understanding of the hardware registers. The driver is getting better, but it not perfect. I do appreciate that you have tested it and that we know that the physical layer is likely suspect. But unfortunately that's not a feasible setup for me, and I had to switch back to ndiswrapper. It's kind of strange to me though, since I'm only 4 metres away from the AP! You may want to try a different channel or bigger antennas. And if you go to ndiswrapper, it would be great to see you back once the driver handles your setup better. -- Regards, Pavel Roskin ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
