Wireless networking problem with Slackware 14.2 on a 2012 MacBook Pro
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Wireless networking problem with Slackware 14.2 on a 2012 MacBook Pro
I started with Slackware 3.0 in 1996 on my 486DX2 desktop and have run it ever since on my desktops and servers. I remember that it took me several days to get X to work and I was afraid that I'd destroy my expensive CRT monitor the whole time.
Now, many years later, since Apple will be leaving me stranded for an OS on my MacBook Pro, and since I've become less happy with the quality of macOS over the last several years, I've decided to jump to Slackware64 on my MacBook Pro (macbookpro9,2). I completely removed macOS. Slackware64 14.2 is installed and nearly all the hardware works, with the sole exception of the SD card reader, which is nearly the least important piece of hardware to me. I managed to get full disk encryption and sleep (suspend) working, as well as the Broadcom 4331 wifi card using the b43 driver.
I can connect at home to my wifi with WPA2-PSK, but I can't for the life of me connect to my employer's wifi. I've tried their public wifi with no encryption, their private wifi with WPA2-Enterprise (PEAP-MSCHAPV2), and the eduroam wifi, also with WPA2-PEAP-MSCHAPV2. None works. Yet I have two other laptops that came with Linux (a Librem 13, and a Pinebook Pro with Debian) and they both connect just fine to all wifi I've tried. So I know that I have the correct script for wpa_supplicant (though to be fair, these machines do have somewhat newer versions of all installed software). I'm running the 4.4.230 kernel that I've configured and compiled just for the MacBook Pro. (It doesn't work with the stock 4.4.14 kernel either.) I've tried many things, from making sure that crda knows I'm in the US, trying both wicd and NetworkManager, trying options on the b43 driver, to trying the broadcom-sta proprietary driver, all to no avail. The wl driver doesn't even see the access points, whereas the b43 driver does. It seems to be a big hint that I can't even connect to the unprotected wifi. There are no certificates needed for any of the access points. Networking is still a weak point of mine; I've spent tens of hours on this specific wifi problem and it's starting to frustrate me. Does anyone have any suggestions for something that I might have overlooked? I give a little bit of information below.
In Slackware 14.2 the wpa_supplicant version is 2.6 and the last time the eduroam network was mentioned here in the Slackware Forum, the user who reported having issues connecting to it finally got it resolved by using wpa_supplicant 2.7 with some additional patches: https://www.linuxquestions.org/quest...ml#post5944370
Here, in a more recent thread, wpa_supplicant 2.9 was successfully used for a wired connection to eduroam (maybe wpa_supplicant 2.9 doesn't need any patches): https://www.linuxquestions.org/quest...er-4175668012/
I was excited to read your post and wondered how I had missed the post you reference. But, the earlier poster was running slackware-current and I'm running 14.2. The first patch (allow-tlsv1) is to make openssl-1.1.1 downgrade to TLS-1, but I have openssl-1.0.2u, so the patch makes the compilation fail. I did try patching the config/dot.config file without the allow-tlsv1 patch, but though it does compile, it brought no joy.
Earlier I had tried to compile wpa_supplicant-2.9 but it has the allow-tlsv1 patch and doesn't compile with openssl-1.0.2u with the patch. I also had to upgrade libnl3-3.2.27 to -3.5.0 and the kernel to 4.19.133 to have all the headers. I suppose I could try to upgrade to openssl-1.1.1, but what will break, or have to be recompiled because of that?
So, I figured that perhaps something besides encryption was wrong with wpa_supplicant--maybe I needed to compile with different options--and I tried the wpa_supplicant-2.6 source from slackware64-current from 5/2018, which was a lucky find on mirror.ic.ufmt.br, and compiled it, but it behaves the same (i.e., won't connect). I even tried compiling with CONFIG_TLS=internal (using the internal TLS library instead of openssl), which meant I had to grab and install libtommath from SBo before compiling, but still no joy. Then I tried the shipped wpa_supplicant-2.5 from 14.2 and it fails just the same as -2.6 and all the rest: either wpa_supplicant gets timed out or gives a "bad password" error. In frustration, I grabbed the wpa_supplicant-2.0 source from slack 14.1 and compiled it and still no joy!
It seems to me that something other than wpa_supplicant is broken. I don't think it can be encryption because I can't even connect to the unsecured guest wifi at my employer with any version of wpa_supplicant from 2.0 on. My suspicion is that the b43 driver isn't playing nicely with wpa_supplicant, but the alternative Broadcom wl driver doesn't even seem to work at all. I've ordered some usb wifi dongles that are supported by the linux kernel to see if I can connect through them and I'll report back when I get them.
This is frustrating because Debian 10 connects just fine to eduroam, to the WPA2-Enterprise wifi, and to the unsecured wifi at work and I'm using the same configs that work there. Besides the slight difference in software versions, the only real difference is the wifi hardware. It can't be the hardware per se, because macOS can connect.
Has anyone else had problems with the Broadcom 4331 b43 driver and WPA2-Enterprise? Or maybe someone can point out something else I'm completely overlooking.
I'm now eager to have Slackware64 15.0 in my hands so that I can see if that'll solve this problem. This is the last real hurdle to having a useful replacement for macOS on the MacBook Pro.
Sorry to hear my hints didn't work and all your efforts didn't bring any joy.
Now I got a little more info about your setup (card/driver & automation tools) and there is another more serious issue highlighted -> not able to connect to an open WiFi network. This should work "out of the box" and is not related to the more demanding eduroam authentication.
First I'd focus on the open WiFi network and try to provide some answers to your questions:
- the Broadcom 4331 b43 driver looks OK (no issues reported in the table): https://wireless.wiki.kernel.org/en/users/drivers/b43
- and it does have an option to disable HW encryption. However, I remember I only had to disable it a (very) long time ago on some Atheros devices. Here it is in bold (output from a Slack 14.2 with the 4.4.227 kernel)
Code:
~# /sbin/modinfo b43 | grep parm
parm: bad_frames_preempt:enable(1) / disable(0) Bad Frames Preemption (int)
parm: fwpostfix:Postfix for the .fw files to load. (string)
parm: hwpctl:Enable hardware-side power control (default off) (int)
parm: nohwcrypt:Disable hardware encryption. (int)
parm: hwtkip:Enable hardware tkip. (int)
parm: qos:Enable QOS support (default on) (int)
parm: btcoex:Enable Bluetooth coexistence (default on) (int)
parm: verbose:Log message verbosity: 0=error, 1=warn, 2=info(default), 3=debug (int)
parm: pio:Use PIO accesses by default: 0=DMA, 1=PIO (int)
parm: allhwsupport:Enable support for all hardware (even it if overlaps with the brcmsmac driver) (int)
- if you want to disable it, either:
Code:
#unload the driver:
/sbin/rmmod b43
# and load it with the HW encryption disabled
/sbin/modprobe b43 nohwcrypt=1
For troubleshooting WiFi connectivity I usually suggest to go down to the basics, use the primitive manual tools and disable any automation (Network Manager & wicd). As mentioned in the beginning, I'd focus first on the open WiFi connection.
- first, clean up the "automation mess"
- then, make sure your wpa_supplicant is properly populated for the open WiFi network.
- if you know the ESSID of that network and only need to connect to that particular one, then you'll need to have an entry like this in wpa_supplicant (substitute open-essid withe actual ESSID):
Code:
network={
ssid="open-essid"
key_mgmt=NONE
}
- if you like to connect to any open networks automatically, then you'll need something like this in wpa_supplicant:
Following you have a manual connection (& disconnection) method:
Code:
# up:
#just making sure there are no leftovers
/usr/bin/killall wpa_supplicant
/sbin/ip link set dev wlan0 up
/sbin/ip address flush dev wlan0
# if you need your card to "tune" to an essid use the following and substitute actual-essid
#/sbin/iwconfig wlan0 essid actual-essid
/usr/bin/sleep 3
/usr/sbin/wpa_supplicant -D nl80211 -i wlan0 -B -c /etc/wpa_supplicant.conf
/usr/bin/sleep 3
/sbin/dhclient wlan0
# if no errors it should be up and running - test connectivity
#down:
/usr/bin/killall wpa_supplicant
/sbin/ip address flush dev wlan0
/sbin/ip link set dev wlan0 down
If you manage to connect to the open WiFi network, then we could move to the more "complicated" eduroam.
If you believe the b43 driver that comes with the Slackware 14.2 kernel is faulty, you can always load and use the more actual Slackware -current kernel by following this old how-to of mine (substitute all the versions to match the actual ones): https://www.linuxquestions.org/quest...ml#post6053120
abga, these were helpful pointers you gave and I made a bit of progress. First, though, let me report that I tried with a USB wifi dongle that uses the rt2800usb driver and I can connect to all of the wifi SSIDs at work, including eduroam as well as the unsecured guest wifi through that USB device. So I'm sure that my configs for wpa_supplicant are correct and that the official wpa_supplicant-2.6 patch for Slackware64-14.2 works fine with every wifi access point. So, it seems to me that it's certainly some kind of driver problem. I played with the options of the b43 driver and nothing helped, though pio=1 stops the driver from even finding the access points. Then I played with the options for the cfg80211 and mac80211 modules that b43 depends on, specifically
and then wpa_supplicant managed to associate with the unsecured guest wifi with the bcm4331 and its b43 driver, but something odd happened next. First dhclient didn't succeed--it just hung--so I tried dhcpcd next. dhcpcd gave me an IP address but apparently no routing information or dns server; I couldn't get to the captive web page to click on the agreement in order to use the network as one has to do. The IP address wasn't part of the 172.xx.xx.xx local subnet, either, but rather a 169.254.xx.xx address that I don't recognize. Despite this progress, there's still no joy on eduroam or the secured WPA2-Enterprise network. It's not the worst thing in the world to have to use a usb wifi adapter to access WPA2-Enterprise, but the adapter does get hot--too hot to touch on the metal usb shielding--and now I'm very curious as to why the b43 driver doesn't work, or the Broadcom wl driver for that matter! In the kernel config there are several options regarding the b43 driver. In my 4.4.230 kernel, I have
Code:
CONFIG_B43=m
CONFIG_B43_BCMA=y
CONFIG_B43_SSB=y
CONFIG_B43_BUSES_BCMA_AND_SSB=y
# CONFIG_B43_BUSES_BCMA is not set
# CONFIG_B43_BUSES_SSB is not set
CONFIG_B43_PCI_AUTOSELECT=y
CONFIG_B43_PCICORE_AUTOSELECT=y
CONFIG_B43_SDIO=y
CONFIG_B43_BCMA_PIO=y
CONFIG_B43_PIO=y
CONFIG_B43_PHY_G=y
CONFIG_B43_PHY_N=y
CONFIG_B43_PHY_LP=y
CONFIG_B43_PHY_HT=y
CONFIG_B43_LEDS=y
CONFIG_B43_HWRNG=y
# CONFIG_B43_DEBUG is not set
# CONFIG_B43LEGACY is not set
CONFIG_SSB_B43_PCI_BRIDGE=y
In configuring the b43 driver in the kernel, one has a choice of using just bcma, just ssb, or both bcma and ssb, and the default is both. Perhaps just one or the other, but not both, is the right choice for the BCM4331. Or maybe I should set CONFIG_B43_BCMA_PIO=n and CONFIG_B43_PIO=n
in the kernel config since the pio=1 option for b43 stops the driver from working. Checking the various combinations will eat up some time in testing! It feels like the problem is narrowed down quite a bit now, but it's still very frustrating because even with increased verbosity of both wpa_supplicant and b43, the error messages don't seem helpful. I got tired of the frustration this afternoon but will continue to investigate tomorrow. I certainly didn't expect this level of difficulty since everything works fine on WPA2-PSK at home.
Ok, so we're getting somewhere, narrowing it down to the actual driver & firmware.
Some answers/suggestions:
Answers:
- I deliberately instructed you to use the dhclient tool because it's simple, reliable (does the job) and exits once it's done or if it times out. In your case it didn't receive the DHCP info, timed out and exited, meaning, either wpa_supplicant or the actual driver/card didn't successfully bring up the connection (no traffic/communication).
- dhcpcd on the other hand (which I simply don't use (nor the init scripts where it's called) - but that's me) apart from staying resident it also tries to outsmart the user. It finally manages to spread confusion, like in this case with that 169.254.xx.xx link local address. I presume it couldn't get the info through DHCP and automatically configured the 169.254.xx.xx link local address, much like M$ is doing (was dhcpcd designed my M$ BTW?) https://en.wikipedia.org/wiki/Link-local_address
- on the kernel configuration related to the b43 driver, just for comparison, I'm running a Raspberry Pi with a Raspbian (Debian) 4.14.79 kernel that I didn't touch (configuration-wise) and just checked some of the options you were curious about:
Code:
modprobe configs
cp /proc/config.gz /tmp/
rmmod configs
cd /tmp/
gunzip config.gz
# the file config should be available to inspect
grep B43 config
CONFIG_B43=m
CONFIG_B43_BCMA=y
CONFIG_B43_SSB=y
CONFIG_B43_BUSES_BCMA_AND_SSB=y
# CONFIG_B43_BUSES_BCMA is not set
# CONFIG_B43_BUSES_SSB is not set
CONFIG_B43_SDIO=y
CONFIG_B43_BCMA_PIO=y
CONFIG_B43_PIO=y
CONFIG_B43_PHY_G=y
# CONFIG_B43_PHY_N is not set
CONFIG_B43_PHY_LP=y
CONFIG_B43_PHY_HT=y
CONFIG_B43_LEDS=y
CONFIG_B43_HWRNG=y
# CONFIG_B43_DEBUG is not set
CONFIG_B43LEGACY=m
CONFIG_B43LEGACY_LEDS=y
CONFIG_B43LEGACY_HWRNG=y
CONFIG_B43LEGACY_DEBUG=y
CONFIG_B43LEGACY_DMA=y
CONFIG_B43LEGACY_PIO=y
CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y
# CONFIG_B43LEGACY_DMA_MODE is not set
# CONFIG_B43LEGACY_PIO_MODE is not set
rm config
- I don't own a Broadcom WiFi device and also trying to stay away from them, given the bad reputation they have with the OSS world. So I'm not able o help you with your particular driver questions but only suggest that you could install the Slackware kernel sources, get into the kernel sources directory and run "make menuconfig", then navigate to the options you're curious about and press "?" once on them - that will open the module option help/info.
- from the following Debian page I learned that for your BCM4331 adapter you could use the proprietary Broadcom wireless LAN driver (wl, aka broadcom-sta) or the OSS b43 that you're experiencing issues with now. https://wiki.debian.org/wl
- you could unload and blacklist the b43 driver and try the proprietary one instead:
Suggestions:
- try to compile a newer b43 driver - there are several repos I found online (google)
- try to load the Slackware -current kernel (newer driver) like I already suggested previously
- and a radical one: maybe you could change the internal WiFi adapter (usually a mini PCIe card) and opt for a better supported one (I'd suggest Atheros) https://www.ifixit.com/Guide/MacBook...lacement/27656
Last edited by abga; 07-21-2020 at 06:59 PM.
Reason: BCM4311 -> BCM4331
Thanks for the further hints, abga. I looked into a few things that you suggested.
First, I looked for other drivers but the best I could manage was to upgrade to kernel 5.4.52, which I compiled and installed. The 5.4.52 kernel upgrade made no difference.
The broadcom-sta (wl) driver and the b43 firmware (v6.30.163.46) on SBo don't seem to work with the BCM4331 and, as I said, that was one of the first things I tried. Besides the 6.30.163.46 firmware for the b43 driver, which is said to incompatible with the wl driver for the BCM4331, I also have the 5.100.x firmware that is also said to be incompatible, but I couldn't find a driver with the 6.20.x firmware that is said to be necessary to make the wl driver work with the BCM4331.
At home I found two other usb wifi dongles and found that one worked (using the zd1211rw driver) and the other (using the r8712u staging driver) didn't work. The one using r8712u couldn't even successfully scan the access points. Curious. Both dongles work well at home. I'm suspecting that there could be something odd about the wifi at work and how it interacts with some wifi cards and I'll talk to our IT department about it when the Linux support person gets back from vacation.
It then occurred to me that perhaps the issue was that the driver didn't get enough power to the hardware, so I went and sat right next to an access point so that its apparent power was the same as the wifi at home, but that didn't make a difference.
I'm OK with hardware modifications as I've done board-level repair and several years ago I successfully replaced the wifi board in an old MacBook Pro 2010 (twice, since the first replacement board was defective). However, the wifi module in the MacBook Pro 2012 is connected with a proprietary connector (see https://www.ifixit.com/Guide/MacBook...lacement/10363), so I doubt that there are any alternative wifi cards that will connect, which is too bad because it looks like a much easier job than in the 2010 model.
Now I think it would be good to write to the b43 driver maintainers and ask if they know of any bugs or have any ideas what might be wrong with trying to connect to my employer's wifi.
I'll update when I know more. At least now I have an acceptable work-around if the issue with the BCM4331 and my employer's wifi can't be resolved. I appreciate all your help.
I doubt there's something "non-standard" with the WiFi system at work, instead, I believe it's also a driver issue with your r8712u adapter.
Driver support for a similar Realtek adapter was recently discussed here: https://www.linuxquestions.org/quest...4/#post6074678
- note: "r8712u is a USB driver for RTL8712U/RTL8192SU devices. It's going to be replaced by rtl8192su"
- source: https://wireless.wiki.kernel.org/en/...rivers/rtl819x
- however, the OP ( justwantin ) managed to get it working with the staging r8712u kernel driver
- r8712u looks to have some limitations: https://deviwiki.com/wiki/R8712u#Supported_modes
- and if you google it, you'll get plenty of issues reported with it ...
Relatek, which is a little better supported compared to Broadcom, has its own problems, people looking for help quite often here on LQ.
Off the record:
I had my own recent experience with a Realtek USB WiFi adapter that I used for several years in STA mode (client) and considered the driver stable and performing well. Up until I tried to use the adapter in Access Point mode - see here: https://www.linuxquestions.org/quest...-a-4175675897/
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
