You are not logged in.

#1 2016-03-09 20:01:04

HandySam
Member
Registered: 2016-03-08
Posts: 4

Broadcom BCM43224 unusable since linux 4.4

After a recent upgrade I have a problem with my Wi-Fi connection. The connection has become completely unstable.

I am using a MacBook Air (2012, Ivy Bridge), dual boot OS X and Arch. I have been using Arch on this machine for quite some time without any major issues. For the Wi-Fi connection, I was Always able to use the official Broadcom open source driver. The Broadcom chip in my laptop is the BCM43224. I use netctl and wpa_actiond for Wi-Fi connectivity. This setup worked really well.

During a recent upgrade (including kernel and other stuff)  my Wi-Fi stopped working. After experiencing the Wi-Fi problems I tried to make a connection manually using wpa_supplicant.

I used this command to set up the connection:

wpa_supplicant -B -i [interface] -c <(wpa_passphrase "[SSID]" "[password]")
dhcpcd [interface]

Normally I get a message like

brcmsmac bcma0:1: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement)

After this message I know I can start pinging. Now (after the upgrade) this message doesn't show or appears later. When I was connected and I was able to ping another device on my network, the latency was very high. Normally the latency to my router is something around 3ms over Wi-Fi.

PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=31.2 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=255 time=48.7 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=255 time=27.2 ms
64 bytes from 10.0.0.1: icmp_seq=6 ttl=255 time=95.9 ms
64 bytes from 10.0.0.1: icmp_seq=7 ttl=255 time=154 ms
64 bytes from 10.0.0.1: icmp_seq=8 ttl=255 time=7.63 ms
64 bytes from 10.0.0.1: icmp_seq=18 ttl=255 time=13.8 ms
64 bytes from 10.0.0.1: icmp_seq=21 ttl=255 time=45.3 ms
64 bytes from 10.0.0.1: icmp_seq=22 ttl=255 time=17.1 ms
64 bytes from 10.0.0.1: icmp_seq=23 ttl=255 time=47.7 ms

--- 10.0.0.1 ping statistics ---
23 packets transmitted, 10 received, 56% packet loss, time 22036ms
rtt min/avg/max/mdev = 7.637/48.941/154.413/42.513 ms

The system disconnects a lot as well. This ping report was created during a moment where I had a "connection".

I have included the full systemd log in which you can see a lot of message about the connecting and reconnecting. I don't really know how to interpret this. I see there are sometimes multiple attempts to authenticate with the access point but I have no idea what's casuing this.

Mar 08 23:44:55 arch systemd[1]: Starting Network Service...
Mar 08 23:44:55 arch dhcpcd[460]: wlp2s0b1: deleting address fe80::2adc:94c7:3480:f74b
Mar 08 23:44:55 arch systemd-networkd[525]: Enumeration completed
Mar 08 23:44:55 arch dhcpcd[460]: wlp2s0b1: deleting default route via 10.0.0.1
Mar 08 23:44:55 arch systemd[1]: Started Network Service.
Mar 08 23:44:55 arch systemd-networkd[525]: wlp2s0b1: Removing non-existent address: fe80::2adc:94c7:3480:f74b/64 (valid forever)
Mar 08 23:44:55 arch systemd-networkd[525]: wlp2s0b1: Removing non-existent address: 10.0.0.41/24 (valid forever)
Mar 08 23:45:16 arch kernel: wlp2s0b1: authenticate with d0:03:4b:d6:5a:09
Mar 08 23:45:16 arch kernel: wlp2s0b1: send auth to d0:03:4b:d6:5a:09 (try 1/3)
Mar 08 23:45:16 arch kernel: wlp2s0b1: send auth to d0:03:4b:d6:5a:09 (try 2/3)
Mar 08 23:45:16 arch kernel: wlp2s0b1: send auth to d0:03:4b:d6:5a:09 (try 3/3)
Mar 08 23:45:16 arch kernel: wlp2s0b1: authentication with d0:03:4b:d6:5a:09 timed out
Mar 08 23:45:54 arch kernel: wlp2s0b1: authenticate with d0:03:4b:d6:5a:09
Mar 08 23:45:54 arch kernel: wlp2s0b1: send auth to d0:03:4b:d6:5a:09 (try 1/3)
Mar 08 23:45:54 arch kernel: wlp2s0b1: send auth to d0:03:4b:d6:5a:09 (try 2/3)
Mar 08 23:45:54 arch kernel: wlp2s0b1: send auth to d0:03:4b:d6:5a:09 (try 3/3)
Mar 08 23:45:54 arch kernel: wlp2s0b1: authentication with d0:03:4b:d6:5a:09 timed out
Mar 08 23:45:58 arch kernel: wlp2s0b1: authenticate with d0:03:4b:d6:5a:09
Mar 08 23:45:58 arch kernel: wlp2s0b1: send auth to d0:03:4b:d6:5a:09 (try 1/3)
Mar 08 23:45:58 arch kernel: wlp2s0b1: send auth to d0:03:4b:d6:5a:09 (try 2/3)
Mar 08 23:45:58 arch kernel: wlp2s0b1: send auth to d0:03:4b:d6:5a:09 (try 3/3)
Mar 08 23:45:58 arch kernel: wlp2s0b1: authentication with d0:03:4b:d6:5a:09 timed out
Mar 08 23:46:08 arch kernel: wlp2s0b1: authenticate with d0:03:4b:d6:5a:09
Mar 08 23:46:08 arch kernel: wlp2s0b1: send auth to d0:03:4b:d6:5a:09 (try 1/3)
Mar 08 23:46:08 arch kernel: wlp2s0b1: authenticated
Mar 08 23:46:08 arch kernel: wlp2s0b1: associate with d0:03:4b:d6:5a:09 (try 1/3)
Mar 08 23:46:08 arch kernel: wlp2s0b1: RX AssocResp from d0:03:4b:d6:5a:09 (capab=0x1011 status=0 aid=1)
Mar 08 23:46:08 arch kernel: brcmsmac bcma0:1: brcmsmac: brcms_ops_bss_info_changed: associated
Mar 08 23:46:08 arch kernel: brcmsmac bcma0:1: brcms_ops_bss_info_changed: qos enabled: true (implement)
Mar 08 23:46:08 arch kernel: wlp2s0b1: associated
Mar 08 23:46:09 arch kernel: brcmsmac bcma0:1: brcmsmac: brcms_ops_bss_info_changed: disassociated
Mar 08 23:46:09 arch kernel: brcmsmac bcma0:1: brcms_ops_bss_info_changed: qos enabled: false (implement)
Mar 08 23:46:58 arch systemd[1]: Starting Network Service...

The full log can be found here.

I have tested the Arch Linux image from february (with the 4.3 kernel) and the Arch Linux image from March (with the 4.4 kernel). I have no problems on the february image but the March image gives me the same problems.

I hope someone can help because I was quite content with the Broadcom open source driver and it worked all this time. I'm happy to provide extra information if needed.

Offline

#2 2016-03-10 13:40:46

mrunion
Member
From: Jonesborough, TN
Registered: 2007-01-26
Posts: 1,938
Website

Re: Broadcom BCM43224 unusable since linux 4.4

I assume after upgrading the Kernel you are rebuilding the Broadcom driver as well, right?


Matt

"It is very difficult to educate the educated."

Offline

#3 2016-03-10 17:34:31

HandySam
Member
Registered: 2016-03-08
Posts: 4

Re: Broadcom BCM43224 unusable since linux 4.4

Honestly I can't say. I upgraded using

pacman -Syu

I don't know if the drivers are getting rebuilt using this method.
But the issue is also visible on the March image and it isn't on the February image. So I don't think the way I upgraded the system has anything to do with this problem.

A fresh install didn't help either. I was hoping it would have been fixed with some incremental update.

Offline

#4 2016-03-11 00:42:22

jeremy31
Member
Registered: 2015-11-01
Posts: 149

Re: Broadcom BCM43224 unusable since linux 4.4

lsmod | egrep 'b43|ssb'

They can interfere with the brcm(s)(f)mac modules

Offline

#5 2016-03-11 19:50:15

HandySam
Member
Registered: 2016-03-08
Posts: 4

Re: Broadcom BCM43224 unusable since linux 4.4

jeremy31 wrote:
lsmod | egrep 'b43|ssb'

They can interfere with the brcm(s)(f)mac modules

This is what I get when I run this command:

b43                   405504  0
mac80211              647168  2 b43,brcmsmac
cfg80211              483328  3 b43,brcmsmac,mac80211
ssb                    61440  1 b43
mmc_core              114688  2 b43,ssb
rng_core               16384  1 b43
pcmcia                 49152  1 ssb
led_class              16384  4 b43,brcmsmac,applesmc,input_leds
bcma                   49152  2 b43,brcmsmac

So clearly b43 was loaded. I thought I had blacklisted it once and it didn't make a difference. But after running

rmmod b43

and connecting again using the wpa_supplicant method, my Wi-Fi seems to be working again as expected.

I will take a look in the wiki to blacklist the b43 module.

Thanks for the help!

Offline

#6 2016-03-15 22:35:14

HandySam
Member
Registered: 2016-03-08
Posts: 4

Re: Broadcom BCM43224 unusable since linux 4.4

Saddly the problem is still there.

lsmod | egrep 'b43|ssb'

Does not return anything, so I am pretty sure that I have successfully blacklisted the b43 driver.

My Wi-Fi connection only worked 2 times or so after blacklisting the driver. Now I have the same issue again. All the log message are the same.

Has anyone experienced this before?

Offline

Board footer

Powered by FluxBB