Siduction Forum
Siduction Forum => Hardware - Support => Topic started by: GoinEasy9 on 2018/10/11, 23:41:06
-
I've made the mistake over time of leaving the Ethernet adapter plugged in to my EEEpc. Today when I tried the wifi it did connect, but was so slow downloading updates, I gave up and plugged the ETH back in.
Is there any simple way of removing the old drivers so I can test the driver that is supposed to be in the kernel, or else, reinstall the old proprietary driver if that doesn't work?
System: Host: EEEpc-1015px Kernel: 4.18.13-towo.1-siduction-amd64 x86_64 bits: 64 Desktop: LXQt
Distro: siduction 17.1.0 Patience - lxqt - (201703051830)
Machine: Device: laptop System: ASUSTeK product: 1015PX v: x.x serial: N/A
Mobo: ASUSTeK model: 1015PE v: x.xx serial: N/A BIOS: American Megatrends v: 1401 date: 08/30/2011
Network: Card-1: Qualcomm Atheros AR8152 v2.0 Fast Ethernet driver: atl1c
IF: enp1s0 state: up speed: 100 Mbps duplex: full mac: f4:6d:04:82:31:63
Card-2: Broadcom Limited BCM4313 802.11bgn Wireless Network Adapter driver: bcma-pci-bridge
IF: wlp2s0b1 state: up mac: 48:5d:60:f6:6a:58
And some related errors:
Oct 11 14:00:46 EEEpc-1015px kernel: brcmsmac bcma0:1: brcms_ops_bss_info_changed: qos enabled: false (implement)
Oct 11 14:00:46 EEEpc-1015px kernel: brcmsmac bcma0:1: brcms_ops_config: change power-save mode: false (implement)
Oct 11 14:00:47 EEEpc-1015px avahi-daemon[514]: chroot.c: open() failed: No such file or directory
Oct 11 14:00:49 EEEpc-1015px kernel: brcmsmac bcma0:1: brcmsmac: brcms_ops_bss_info_changed: associated
Oct 11 14:00:49 EEEpc-1015px kernel: brcmsmac bcma0:1: brcms_ops_bss_info_changed: qos enabled: true (implement)
Oct 11 14:00:52 EEEpc-1015px connmand[505]: __connman_inet_get_pnp_nameservers: Cannot read /proc/net/pnp Failed to open file “/proc/net/pnp”: No such file or directory
Oct 11 14:00:53 EEEpc-1015px connmand[505]: The name net.connman.vpn was not provided by any .service files
Oct 11 14:00:53 EEEpc-1015px wpa_supplicant[506]: Failed to initialize control interface '/run/wpa_supplicant'.
You may have another wpa_supplicant process already running or the file was
left by an unclean termination of wpa_supplicant in which case you will need
to manually remove this file before starting wpa_supplicant again.
Oct 11 14:05:35 EEEpc-1015px kernel: brcmsmac bcma0:1: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement)
Thanks in Advance
-
Unfortunately, I'm not using Unstable right now. However, I searched Synaptic under Debian Stretch and came up with broadcom-sta-dkms as a possibility. Try searching Synaptic and see if you come up with the same search results. If so, uninstall the proprietary driver and install dkms and broadcom-sta-dkms. I think installing broadcom-sta-dkms will pull in broadcom-sta-common as well.
Edit: Just discovered (https://packages.debian.org/stretch/broadcom-sta-dkms) that you need the wireless-tools package as well, if it's not automatically installed.
-
Thanks tranquil.
I did install Synaptic to do some searching yesterday. My apt-cache policy commands were lacking. I did see the broadcom-sta drivers listed, as working for the BCM4313, but I thought I remember them as being outdated. I may be wrong, and, if nothing else works, I'll experiment with them.
Right now I have remnants of the b43 and b43legacy drivers on the machine. I would like to remove them and just try the driver that now is in the kernel. Maybe just blacklisting those drivers before doing a purge may help. The errors seem to revolve around the brcmsmac driver, which, I think is the kernel driver. As soon as I get time, I'll play with it and see.
Thanks for the response
-
No problem. I have a Broadcom BCM4352 WiFi chip in my ASUS AIO and I use the broadcom-sta drivers without any major issues. I do experience issues under Debian Stretch when suspending. Sometimes network manager will ask for my WiFi password when coming out of suspension, but the password doesn't work. I have to issue the following command to reconnect to WiFi:
sudo systemctl restart network-manager
Sometimes I have to issue the above command a number of times before I'm able to reconnect to WiFi.
-
I added blacklist.conf to /etc/modules.d
Blacklisted b43 and ssb
rebooted without Ethernet cable
Speed on wifi back to normal
Even though lsmod looks exactly the same
$ lsmod | egrep 'b43|brcm' (before blacklist of b43 and ssb)
brcmsmac 577536 0
cordic 16384 1 brcmsmac
brcmutil 16384 1 brcmsmac
b43 454656 0
mac80211 827392 2 b43,brcmsmac
cfg80211 774144 3 b43,mac80211,brcmsmac
ssb 81920 1 b43
mmc_core 172032 2 b43,ssb
rng_core 16384 1 b43
bcma 61440 2 b43,brcmsmac
$ lsmod | egrep -i 'b43|brcm' (after blacklist of b43 and ssb)
brcmsmac 577536 0
cordic 16384 1 brcmsmac
brcmutil 16384 1 brcmsmac
b43 454656 0
mac80211 827392 2 b43,brcmsmacf it works
cfg80211 774144 3 b43,mac80211,brcmsmac
ssb 81920 1 b43
mmc_core 172032 2 b43,ssb
rng_core 16384 1 b43
bcma 61440 2 b43,brcmsmac
If it works don't fix it, but, I've got to find out why.
-
If it works don't fix it, but, I've got to find out why.
I agree. It's not helpful to fix something without understanding why it broke in the first place.
-
After 2 reboots, wifi slows to a crawl again. Tried purging all proprietary drivers, but, kernel driver was no help. The sta driver failed, even though it is the one meant for the bcm4313. Reinstall of b43 leaves me where I started off. I'm going to have to do more research and possible try a usb wifi dongle. It works on the widows 7 install it's dual booted with, so, it may or may not be hardware related. Damn.
-
Definitely understand the frustration. In what way did the STA driver fail? Did it fail to install or did WiFi just not work?
-
My EeePc will show the wifi light, and gkrellm, with an active window for wifi. The sta driver didn't show on gkrellm at all. There was no active wifi with it. Right now, b43-fwcutter and its firmware are installed, and as before, it seems to connect, but, is too slow to use.
Next up will be the broadcom-wl driver. It's also listed for the bcm4313.
-
Hi... the "b43" driver CAN NOT work with this card. It is supported by either the native "brcmsmac" (requires no additional firmware for this card) or proprietary "wl" driver (which you already had in the first report).
So my guess is that it is the "brcmsmac" that is automatically loading (obviously) after removing (purging) the "wl" driver, and installing the firmware has absolutely nothing to do with the fix.