Whenst last we left our hero, I had let yum upgrade my kernel on FC6 to 2.6.22.1-32.fc6, which required bcm43xx drivers version 4. However, bcm43xx-fwcutter had not been upgraded and would not handle the new drives. Moving forward, last night I updated to the latest bcm43xx-fwcutter and extracted the version 4 drivers. My laptop's wireless now works but not at boot time. I have to run 'modprobe bcm43xx-mac80211' and 'ifup eth1' to get an actual network connection. I tried to illustrate the situation with the output below. It seems like there is a timing or order issue.
Anyone know what I'm doing wrong or need to do differently to get the new version of bcm43xx working on my laptop?
Thanks!
Andrew Robinson
[root@proteus ~]# lsmod | grep bcm43xx
bcm43xx_mac80211 397601 0 ssb 35141 1 bcm43xx_mac80211 mac80211 145865 2 rc80211_simple,bcm43xx_mac80211
[root@proteus ~]# iwlist eth1 scan
Warning: Driver for device eth1 has been compiled with version 22 of Wireless Extension, while this program supports up to version 20. Some things may be broken...
eth1 Scan completed : Cell 01 - Address: 00:18:39:7A:B4:C0 ESSID:"robinson" Mode:Master Channel:6 Frequency:2.437 GHz Quality=47/100 Signal level=-50 dBm Noise level=-68 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s 24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s 12 Mb/s; 48 Mb/s Extra:tsf=0000059292340402 Cell 02 - Address: 00:16:B6:DB:0B:8C ESSID:"robinson" Mode:Master Channel:6 Frequency:2.437 GHz Quality=41/100 Signal level=-60 dBm Noise level=-68 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s 24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s 12 Mb/s; 48 Mb/s Extra:tsf=000005929477611c
[root@proteus ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:90:96:79:86:70 inet addr:192.168.1.25 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::290:96ff:fe79:8670/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:71 errors:0 dropped:0 overruns:0 frame:0 TX packets:89 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4118 (4.0 KiB) TX bytes:9175 (8.9 KiB)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3837 errors:0 dropped:0 overruns:0 frame:0 TX packets:3837 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4849964 (4.6 MiB) TX bytes:4849964 (4.6 MiB)
wmaster0 Link encap:UNSPEC HWaddr 00-90-96-79-86-70-28-49-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 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[root@proteus ~]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. From 192.168.1.25 icmp_seq=2 Destination Host Unreachable From 192.168.1.25 icmp_seq=3 Destination Host Unreachable
--- 192.168.1.1 ping statistics --- 3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2008ms , pipe 2
[root@proteus ~]# modprobe bcm43xx-mac80211
[root@proteus ~]# ifup eth1
[root@proteus ~]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.87 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.31 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.95 ms
--- 192.168.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 1.876/2.714/3.310/0.609 ms
On Tue, 28 Aug 2007, Andrew Robinson wrote:
Whenst last we left our hero, I had let yum upgrade my kernel on FC6 to 2.6.22.1-32.fc6, which required bcm43xx drivers version 4. However, bcm43xx-fwcutter had not been upgraded and would not handle the new drives. Moving forward, last night I updated to the latest bcm43xx-fwcutter and extracted the version 4 drivers. My laptop's wireless now works but not at boot time. I have to run 'modprobe bcm43xx-mac80211' and 'ifup eth1' to get an actual network connection.
a wild shot in the dark -- what about adding
alias eth1 bcm43xx-mac80211
to /etc/modprobe.conf?
rday
Robert P. J. Day wrote:
On Tue, 28 Aug 2007, Andrew Robinson wrote:
Whenst last we left our hero, I had let yum upgrade my kernel on FC6 to 2.6.22.1-32.fc6, which required bcm43xx drivers version 4. However, bcm43xx-fwcutter had not been upgraded and would not handle the new drives. Moving forward, last night I updated to the latest bcm43xx-fwcutter and extracted the version 4 drivers. My laptop's wireless now works but not at boot time. I have to run 'modprobe bcm43xx-mac80211' and 'ifup eth1' to get an actual network connection.
a wild shot in the dark -- what about adding
alias eth1 bcm43xx-mac80211
to /etc/modprobe.conf?
It's already there.
Andrew
On Tue, Aug 28, 2007 at 01:44:28PM -0400, Andrew Robinson wrote:
[root@proteus ~]# lsmod | grep bcm43xx
bcm43xx_mac80211 397601 0 ssb 35141 1 bcm43xx_mac80211 mac80211 145865 2 rc80211_simple,bcm43xx_mac80211
[root@proteus ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:90:96:79:86:70 inet addr:192.168.1.25 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::290:96ff:fe79:8670/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:71 errors:0 dropped:0 overruns:0 frame:0 TX packets:89 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4118 (4.0 KiB) TX bytes:9175 (8.9 KiB)
[root@proteus ~]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. From 192.168.1.25 icmp_seq=2 Destination Host Unreachable From 192.168.1.25 icmp_seq=3 Destination Host Unreachable
--- 192.168.1.1 ping statistics --- 3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2008ms , pipe 2
[root@proteus ~]# modprobe bcm43xx-mac80211
[root@proteus ~]# ifup eth1
[root@proteus ~]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.87 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.31 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.95 ms
Did you leave something out? The lsmod showed that you already had bcm43xx-mac80211 loaded ('-' == '_' for lsmod), and you already had eth1 marked up and with an IP address assigned. I can't think of any reason why those commands should make any difference.
Is this repeatable? Did you move the laptop during this process?
John
John W. Linville wrote:
On Tue, Aug 28, 2007 at 01:44:28PM -0400, Andrew Robinson wrote:
[root@proteus ~]# lsmod | grep bcm43xx
bcm43xx_mac80211 397601 0 ssb 35141 1 bcm43xx_mac80211 mac80211 145865 2 rc80211_simple,bcm43xx_mac80211
[root@proteus ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:90:96:79:86:70 inet addr:192.168.1.25 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::290:96ff:fe79:8670/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:71 errors:0 dropped:0 overruns:0 frame:0 TX packets:89 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4118 (4.0 KiB) TX bytes:9175 (8.9 KiB)
[root@proteus ~]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. From 192.168.1.25 icmp_seq=2 Destination Host Unreachable From 192.168.1.25 icmp_seq=3 Destination Host Unreachable
--- 192.168.1.1 ping statistics --- 3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2008ms , pipe 2
[root@proteus ~]# modprobe bcm43xx-mac80211
[root@proteus ~]# ifup eth1
[root@proteus ~]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.87 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.31 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.95 ms
Did you leave something out? The lsmod showed that you already had bcm43xx-mac80211 loaded ('-' == '_' for lsmod), and you already had eth1 marked up and with an IP address assigned. I can't think of any reason why those commands should make any difference.
Is this repeatable? Did you move the laptop during this process?
It's repeatable. I found I did not need to do the 'modprobe bcm43xx-mac80211', just the 'ifup eth1' to get the network working. It seems like some kind of timing problem, like ifcfg-eth1 is getting run before the bcm43xx-mac80211 module has made eth1 the network interface. If eth1 were a wired network interface, it would be like I forgot to plug in the ethernet cable. Does that make any sense or help describe the problem?
Thanks!
Andrew
Andrew Robinson wrote:
John W. Linville wrote:
On Tue, Aug 28, 2007 at 01:44:28PM -0400, Andrew Robinson wrote:
[root@proteus ~]# lsmod | grep bcm43xx
bcm43xx_mac80211 397601 0 ssb 35141 1 bcm43xx_mac80211 mac80211 145865 2 rc80211_simple,bcm43xx_mac80211
[root@proteus ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:90:96:79:86:70 inet addr:192.168.1.25 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::290:96ff:fe79:8670/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:71 errors:0 dropped:0 overruns:0 frame:0 TX packets:89 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4118 (4.0 KiB) TX bytes:9175 (8.9 KiB)
[root@proteus ~]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. From 192.168.1.25 icmp_seq=2 Destination Host Unreachable From 192.168.1.25 icmp_seq=3 Destination Host Unreachable
--- 192.168.1.1 ping statistics --- 3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2008ms , pipe 2
[root@proteus ~]# modprobe bcm43xx-mac80211
[root@proteus ~]# ifup eth1
[root@proteus ~]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.87 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.31 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.95 ms
Did you leave something out? The lsmod showed that you already had bcm43xx-mac80211 loaded ('-' == '_' for lsmod), and you already had eth1 marked up and with an IP address assigned. I can't think of any reason why those commands should make any difference.
Is this repeatable? Did you move the laptop during this process?
It's repeatable. I found I did not need to do the 'modprobe bcm43xx-mac80211', just the 'ifup eth1' to get the network working. It seems like some kind of timing problem, like ifcfg-eth1 is getting run before the bcm43xx-mac80211 module has made eth1 the network interface. If eth1 were a wired network interface, it would be like I forgot to plug in the ethernet cable. Does that make any sense or help describe the problem?
Thanks!
Andrew
Hi Andrew are you using the normal "network" or are you using "Network Manager"?
Karl Larsen wrote:
Andrew Robinson wrote:
John W. Linville wrote:
On Tue, Aug 28, 2007 at 01:44:28PM -0400, Andrew Robinson wrote:
[root@proteus ~]# lsmod | grep bcm43xx
bcm43xx_mac80211 397601 0 ssb 35141 1 bcm43xx_mac80211 mac80211 145865 2 rc80211_simple,bcm43xx_mac80211
[root@proteus ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:90:96:79:86:70 inet addr:192.168.1.25 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::290:96ff:fe79:8670/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:71 errors:0 dropped:0 overruns:0 frame:0 TX packets:89 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4118 (4.0 KiB) TX bytes:9175 (8.9 KiB)
[root@proteus ~]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. From 192.168.1.25 icmp_seq=2 Destination Host Unreachable From 192.168.1.25 icmp_seq=3 Destination Host Unreachable
--- 192.168.1.1 ping statistics --- 3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2008ms , pipe 2
[root@proteus ~]# modprobe bcm43xx-mac80211
[root@proteus ~]# ifup eth1
[root@proteus ~]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.87 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=3.31 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=2.95 ms
Did you leave something out? The lsmod showed that you already had bcm43xx-mac80211 loaded ('-' == '_' for lsmod), and you already had eth1 marked up and with an IP address assigned. I can't think of any reason why those commands should make any difference.
Is this repeatable? Did you move the laptop during this process?
It's repeatable. I found I did not need to do the 'modprobe bcm43xx-mac80211', just the 'ifup eth1' to get the network working. It seems like some kind of timing problem, like ifcfg-eth1 is getting run before the bcm43xx-mac80211 module has made eth1 the network interface. If eth1 were a wired network interface, it would be like I forgot to plug in the ethernet cable. Does that make any sense or help describe the problem?
Thanks!
Andrew
Hi Andrew are you using the normal "network" or are you using "Network Manager"?
I use configuration files. I set up ifcfg-eth1 one parameter at a time with iwconfig back in FC4 using ndiswrapper. I haven't had to change it since.
I've tried Network Manager a couple of times, but it caused some problems and I didn't stick with it long enough to figure out what they were. I just like seeing the setting in a parameter file. Yes I know I need to join the 21st century :).
Andrew
Andrew Robinson wrote:
Karl Larsen wrote:
Andrew Robinson wrote:
John W. Linville wrote:
On Tue, Aug 28, 2007 at 01:44:28PM -0400, Andrew Robinson wrote: Snip
Hi Andrew are you using the normal "network" or are you using "Network Manager"?
I use configuration files. I set up ifcfg-eth1 one parameter at a time with iwconfig back in FC4 using ndiswrapper. I haven't had to change it since.
I've tried Network Manager a couple of times, but it caused some problems and I didn't stick with it long enough to figure out what they were. I just like seeing the setting in a parameter file. Yes I know I need to join the 21st century :).
Andrew
You are using network then. Have you looked at the regular GUI network system? Often it will give you a hint about what is wrong. Go to System Administration Networks and see what it shows for your system.
Also it is the opinion of some that Network Manager adds more confusion to the issue. My experience is that it works fine and is an asset on my laptop.
Karl Larsen wrote:
Hi Andrew are you using the normal "network" or are you using "Network Manager"?
Talking of this: Can NetworkManager be used with WPA?
Somebody in the thread at some point said:
Karl Larsen wrote:
Hi Andrew are you using the normal "network" or are you using "Network Manager"?
Talking of this: Can NetworkManager be used with WPA?
Yes, if it will work at all with your device and virtual network interfaces if you are using them.
-Andy
Martin Marques wrote:
Karl Larsen wrote:
Hi Andrew are you using the normal "network" or are you using "Network Manager"?
Talking of this: Can NetworkManager be used with WPA?
Do as if I never asked this.
Answer: Yes.
Somebody in the thread at some point said:
[root@proteus ~]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. From 192.168.1.25 icmp_seq=2 Destination Host Unreachable From 192.168.1.25 icmp_seq=3 Destination Host Unreachable
What does
route -n
say during the bad times?
-Andy
Andy Green wrote:
Somebody in the thread at some point said:
[root@proteus ~]# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. From 192.168.1.25 icmp_seq=2 Destination Host Unreachable From 192.168.1.25 icmp_seq=3 Destination Host Unreachable
What does
route -n
say during the bad times?
-Andy
The default route this there. However, that doesn't (yet) matter because I cannot ping the gateway (192.168.1.1).
Andrew
Somebody in the thread at some point said:
The default route this there. However, that doesn't (yet) matter because I cannot ping the gateway (192.168.1.1).
Hum. There was some change recently IIRC to defer loading firmware until the interface comes up... but your interface says it is up. But you don't mention looking in dmesg for bcm43xx-mac80211-related messages.... might be interesting to do that before and after the ifup that fixes it.
-Andy
Somebody in the thread at some point said:
Somebody in the thread at some point said:
The default route this there. However, that doesn't (yet) matter because I cannot ping the gateway (192.168.1.1).
Hum. There was some change recently IIRC to defer loading firmware until the interface comes up... but your interface says it is up. But you don't mention looking in dmesg for bcm43xx-mac80211-related messages.... might be interesting to do that before and after the ifup that fixes it.
Hm you didn't show iwconfig output either when it was bad, that can also have a clue.
-Andy
Andy Green wrote:
Somebody in the thread at some point said:
Somebody in the thread at some point said:
The default route this there. However, that doesn't (yet) matter because I cannot ping the gateway (192.168.1.1).
Hum. There was some change recently IIRC to defer loading firmware until the interface comes up... but your interface says it is up. But you don't mention looking in dmesg for bcm43xx-mac80211-related messages.... might be interesting to do that before and after the ifup that fixes it.
Hm you didn't show iwconfig output either when it was bad, that can also have a clue.
Here are the pertinent parts (I hope) of the messages log before running ifup. After running ifup, there were no changes to that file:
Aug 28 19:49:34 proteus kernel: bcm43xx_mac80211: 30-bit DMA initialized Aug 28 19:49:34 proteus kernel: bcm43xx_mac80211: Adding Interface type 2 Aug 28 19:49:34 proteus kernel: bcm43xx_mac80211: Broadcom 4306 WLAN found Aug 28 19:49:34 proteus kernel: bcm43xx_mac80211: Chip initialized Aug 28 19:49:34 proteus kernel: bcm43xx_mac80211: Found PHY: Analog 2, Type 2, Revision 2 Aug 28 19:49:34 proteus kernel: bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 Aug 28 19:49:34 proteus kernel: bcm43xx_mac80211: Radio enabled by hardware Aug 28 19:49:34 proteus kernel: bcm43xx_mac80211: Radio turned off Aug 28 19:49:34 proteus kernel: bcm43xx_mac80211: Radio turned on Aug 28 19:49:34 proteus kernel: bcm43xx_mac80211: !WARNING! Idle-TSSI phy->cur_idle_tssi measuring failed. (cur=0, tgt=62). Disabling TX power adjustment. Aug 28 19:49:34 proteus kernel: bcm43xx_mac80211: Wireless interface started Aug 28 19:49:34 proteus kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready Aug 28 19:49:34 proteus kernel: ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x04, vendor 0x4243) Aug 28 19:49:34 proteus kernel: ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x05, vendor 0x4243) Aug 28 19:49:34 proteus kernel: ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x02, vendor 0x4243) Aug 28 19:49:34 proteus kernel: ssb: Core 3 found: V90 (cc 0x807, rev 0x02, vendor 0x4243) Aug 28 19:49:34 proteus kernel: ssb: Core 4 found: PCI (cc 0x804, rev 0x09, vendor 0x4243) Aug 28 19:49:34 proteus kernel: ssb: Sonics Silicon Backplane found on PCI device 0000:00:0c.0 Aug 28 19:49:34 proteus kernel: ssb: Switching to ChipCommon core, index 0 Aug 28 19:49:34 proteus kernel: ssb: Switching to ChipCommon core, index 0 Aug 28 19:49:34 proteus kernel: ssb: Switching to IEEE 802.11 core, index 1 Aug 28 19:49:34 proteus kernel: ssb: Switching to IEEE 802.11 core, index 1 Aug 28 19:49:34 proteus kernel: ssb: Switching to IEEE 802.11 core, index 1 Aug 28 19:49:34 proteus kernel: ssb: Switching to PCI core, index 4 Aug 28 19:49:34 proteus kernel: ssb: Switching to PCI core, index 4 Aug 28 19:50:39 proteus avahi-daemon[2735]: avahi-daemon 0.6.16 starting up. Aug 28 19:50:39 proteus avahi-daemon[2735]: Found user 'avahi' (UID 70) and group 'avahi' (GID 70). Aug 28 19:50:39 proteus avahi-daemon[2735]: Successfully called chroot(). Aug 28 19:50:39 proteus avahi-daemon[2735]: Successfully dropped remaining capabilities. Aug 28 19:50:39 proteus avahi-daemon[2735]: Successfully dropped root privileges. Aug 28 19:50:39 proteus avahi-daemon[2735]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns! Aug 28 19:50:40 proteus avahi-daemon[2735]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.1.25. Aug 28 19:50:40 proteus avahi-daemon[2735]: Loading service file /services/sftp-ssh.service. Aug 28 19:50:40 proteus avahi-daemon[2735]: Network interface enumeration completed. Aug 28 19:50:40 proteus avahi-daemon[2735]: New relevant interface eth1.IPv4 for mDNS. Aug 28 19:50:40 proteus avahi-daemon[2735]: Registering HINFO record with values 'I686'/'LINUX'. Aug 28 19:50:40 proteus avahi-daemon[2735]: Registering new address record for 192.168.1.25 on eth1. Aug 28 19:50:40 proteus avahi-daemon[2735]: Server startup complete. Host name is proteus.local. Local service cookie is 4165375634. Aug 28 19:50:41 proteus avahi-daemon[2735]: Service "SFTP File Transfer on proteus" (/services/sftp-ssh.service) successfully established. Aug 28 19:52:20 proteus kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready Aug 28 19:52:21 proteus avahi-daemon[2735]: Joining mDNS multicast group on interface eth1.IPv6 with address fe80::290:96ff:fe79:8670. Aug 28 19:52:21 proteus avahi-daemon[2735]: New relevant interface eth1.IPv6 for mDNS. Aug 28 19:52:21 proteus avahi-daemon[2735]: Registering new address record for fe80::290:96ff:fe79:8670 on eth1. Aug 28 19:58:18 proteus avahi-daemon[2735]: Got SIGTERM, quitting. Aug 28 19:58:18 proteus avahi-daemon[2735]: Leaving mDNS multicast group on interface eth1.IPv4 with address 192.168.1.25. Aug 28 19:58:18 proteus avahi-daemon[2735]: Leaving mDNS multicast group on interface eth1.IPv6 with address fe80::290:96ff:fe79:8670. Aug 28 19:59:44 proteus kernel: bcm43xx_mac80211: Broadcom 4306 WLAN found Aug 28 19:59:44 proteus kernel: bcm43xx_mac80211: Found PHY: Analog 2, Type 2, Revision 2 Aug 28 19:59:44 proteus kernel: bcm43xx_mac80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 Aug 28 19:59:44 proteus kernel: bcm43xx_mac80211: Radio turned off Aug 28 19:59:44 proteus kernel: ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x04, vendor 0x4243) Aug 28 19:59:44 proteus kernel: ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x05, vendor 0x4243) Aug 28 19:59:44 proteus kernel: ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x02, vendor 0x4243) Aug 28 19:59:44 proteus kernel: ssb: Core 3 found: V90 (cc 0x807, rev 0x02, vendor 0x4243) Aug 28 19:59:44 proteus kernel: ssb: Core 4 found: PCI (cc 0x804, rev 0x09, vendor 0x4243) Aug 28 19:59:44 proteus kernel: ssb: Sonics Silicon Backplane found on PCI device 0000:00:0c.0 Aug 28 19:59:44 proteus kernel: ssb: Switching to ChipCommon core, index 0 Aug 28 19:59:44 proteus kernel: ssb: Switching to IEEE 802.11 core, index 1 Aug 28 19:59:44 proteus kernel: ssb: Switching to PCI core, index 4 Aug 28 19:59:45 proteus kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready Aug 28 19:59:45 proteus kernel: bcm43xx_mac80211: 30-bit DMA initialized Aug 28 19:59:45 proteus kernel: bcm43xx_mac80211: Adding Interface type 2 Aug 28 19:59:45 proteus kernel: bcm43xx_mac80211: Chip initialized Aug 28 19:59:45 proteus kernel: bcm43xx_mac80211: Radio enabled by hardware Aug 28 19:59:45 proteus kernel: bcm43xx_mac80211: Radio turned on Aug 28 19:59:45 proteus kernel: bcm43xx_mac80211: !WARNING! Idle-TSSI phy->cur_idle_tssi measuring failed. (cur=0, tgt=62). Disabling TX power adjustment. Aug 28 19:59:45 proteus kernel: bcm43xx_mac80211: Wireless interface started Aug 28 19:59:45 proteus kernel: ssb: Switching to ChipCommon core, index 0 Aug 28 19:59:45 proteus kernel: ssb: Switching to IEEE 802.11 core, index 1 Aug 28 19:59:45 proteus kernel: ssb: Switching to IEEE 802.11 core, index 1 Aug 28 19:59:45 proteus kernel: ssb: Switching to PCI core, index 4 Aug 28 20:00:49 proteus avahi-daemon[2735]: avahi-daemon 0.6.16 starting up. Aug 28 20:00:49 proteus avahi-daemon[2735]: Found user 'avahi' (UID 70) and group 'avahi' (GID 70). Aug 28 20:00:49 proteus avahi-daemon[2735]: Successfully dropped root privileges. Aug 28 20:00:49 proteus avahi-daemon[2735]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns! Aug 28 20:00:50 proteus avahi-daemon[2735]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.1.25. Aug 28 20:00:50 proteus avahi-daemon[2735]: Loading service file /services/sftp-ssh.service. Aug 28 20:00:50 proteus avahi-daemon[2735]: Network interface enumeration completed. Aug 28 20:00:50 proteus avahi-daemon[2735]: New relevant interface eth1.IPv4 for mDNS. Aug 28 20:00:50 proteus avahi-daemon[2735]: Registering HINFO record with values 'I686'/'LINUX'. Aug 28 20:00:50 proteus avahi-daemon[2735]: Registering new address record for 192.168.1.25 on eth1. Aug 28 20:00:50 proteus avahi-daemon[2735]: Successfully called chroot(). Aug 28 20:00:50 proteus avahi-daemon[2735]: Successfully dropped remaining capabilities. Aug 28 20:00:51 proteus avahi-daemon[2735]: Server startup complete. Host name is proteus.local. Local service cookie is 852509285. Aug 28 20:00:51 proteus avahi-daemon[2735]: Service "SFTP File Transfer on proteus" (/services/sftp-ssh.service) successfully established.
Here is the iwconfig output:
eth1 IEEE 802.11g ESSID:"robinson" Mode:Managed Frequency:2.437 GHz Access Point: 00:18:39:7A:B4:C0 Bit Rate=54 Mb/s Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:4138-9E74-82F5-7848-53EF-79E1-FE Link Quality=43/100 Signal level=-39 dBm Noise level=-69 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
I don't think there was a change after the ifup:
eth1 IEEE 802.11g ESSID:"robinson" Mode:Managed Frequency:2.437 GHz Access Point: 00:18:39:7A:B4:C0 Bit Rate=1 Mb/s Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:4138-9E74-82F5-7848-53EF-79E1-FE Link Quality=44/100 Signal level=-39 dBm Noise level=-69 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Thanks!
Andrew
Somebody in the thread at some point said:
Aug 28 19:49:34 proteus kernel: bcm43xx_mac80211: !WARNING! Idle-TSSI phy->cur_idle_tssi measuring failed. (cur=0, tgt=62). Disabling TX power adjustment.
Mode:Managed Frequency:2.437 GHz Access Point:
00:18:39:7A:B4:C0 Bit Rate=54 Mb/s
Bit Rate=1 Mb/s
How far away are you from the AP? I notice that the Bit Rate changed between "before and after"...
-Andy
Andrew Robinson escribió:
Whenst last we left our hero, I had let yum upgrade my kernel on FC6 to 2.6.22.1-32.fc6, which required bcm43xx drivers version 4. However, bcm43xx-fwcutter had not been upgraded and would not handle the new drives. Moving forward, last night I updated to the latest bcm43xx-fwcutter and extracted the version 4 drivers. My laptop's wireless now works but not at boot time. I have to run 'modprobe bcm43xx-mac80211' and 'ifup eth1' to get an actual network connection. I tried to illustrate the situation with the output below. It seems like there is a timing or order issue.
Anyone know what I'm doing wrong or need to do differently to get the new version of bcm43xx working on my laptop?
# grep wlan0 /etc/modprobe.conf alias wlan0 bcm43xx-mac80211
Martin Marques wrote:
Andrew Robinson escribió:
Whenst last we left our hero, I had let yum upgrade my kernel on FC6 to 2.6.22.1-32.fc6, which required bcm43xx drivers version 4. However, bcm43xx-fwcutter had not been upgraded and would not handle the new drives. Moving forward, last night I updated to the latest bcm43xx-fwcutter and extracted the version 4 drivers. My laptop's wireless now works but not at boot time. I have to run 'modprobe bcm43xx-mac80211' and 'ifup eth1' to get an actual network connection. I tried to illustrate the situation with the output below. It seems like there is a timing or order issue.
Anyone know what I'm doing wrong or need to do differently to get the new version of bcm43xx working on my laptop?
# grep wlan0 /etc/modprobe.conf alias wlan0 bcm43xx-mac80211
Question, what does that do to eth1? That's the name of the interface at the moment.
Thanks!
Andrew
Andrew Robinson wrote:
Martin Marques wrote:
# grep wlan0 /etc/modprobe.conf alias wlan0 bcm43xx-mac80211
Question, what does that do to eth1? That's the name of the interface at the moment.
I have always used wlanX for wireless conections.
On Wed, 29 Aug 2007, Martin Marques wrote:
Andrew Robinson wrote:
Martin Marques wrote:
# grep wlan0 /etc/modprobe.conf alias wlan0 bcm43xx-mac80211
Question, what does that do to eth1? That's the name of the interface at the moment.
I have always used wlanX for wireless conections.
in earlier fedoras, it was eth1. i remember that distinctly.
rday
On Wed, Aug 29, 2007 at 03:33:54PM -0400, Robert P. J. Day wrote:
On Wed, 29 Aug 2007, Martin Marques wrote:
I have always used wlanX for wireless conections.
in earlier fedoras, it was eth1. i remember that distinctly.
It depends on the driver, and they can be renamed FWIW.
John