7

I have a raspberry pi 3 (which has internal WiFi), running raspbian.

I decided to run it as "testing", by changing the apt list.

Now, I can't use WiFi.

Whenever I use wpa_supplicant, it complains that there's no wlan0 device (which there isn't in /dev)

What can I do to setup the wlan device and get wpa_supplicant back up?

uname -r is 4.4.13-v7+

lsmod shows:

AppleTalk
psnap
llc
axc25
bncp
hci_uart
btbcm
Bluetooth
joydcv
evdev
hid_microsoft
brcmfmac
brcmutil
cfg80211
rfkill
snd_bcm2835
snd_pcm
snd_timer
snd
spi_bcm8235
bcm8235_gpiomen
bcm8235_wdt
uio_pdrv_genirq
uio
ipv6
goldilocks
  • 58,859
  • 17
  • 112
  • 227
Wert
  • 71
  • 1
  • 3
  • 1
    Hmm, well brcmfmac is the driver and you are using the current kernel. Does ip link show anything besides lo and eth0? I have a card with "stretch" (Raspbian testing) on it but haven't used or updated it in a while (or tried it in my Pi 3). They may have switched over to using "predictable interface naming", which can seem a bit counter-intuitive and may result in the interface having a different name. It will still probably start with w though. – goldilocks Aug 07 '16 at 20:49
  • Anyway, also edit in the output from sudo ip link (you can highlight and use the { } button to get the formatting right); it's important to determine whether it has mysteriously loaded the driver yet created no interface, or is just using a new name for it (which would screw up your existing configuration). – goldilocks Aug 07 '16 at 20:49
  • @goldilocks just lo and enxb827eb.... link/ether – Wert Aug 07 '16 at 21:11
  • Same with ifconfig – Wert Aug 07 '16 at 21:12
  • Yeah, enxb827eb sounds like that renaming scheme to me (did I mention "counter-intuitive"?). BTW ifconfig only shows interfaces that are in an "UP" state (ifconfig -a will show all of them, but has been depreciated in favour of the ip toolset, see man ifconfig). The renamings are logged though; try sudo grep wlan /var/log/syslog and see if there's any clue there. Note they may also have stopped using rsyslog by default in stretch so you'd have to check through journald instead (or enable rsyslog and reboot). – goldilocks Aug 07 '16 at 21:32
  • Beware any timestamps in the log involving network interfaces may be misleading if there is no network at that point -- the correct time will not have been set. – goldilocks Aug 07 '16 at 21:33
  • @goldilocks all it says is could not read wlan0 flags. No such device – Wert Aug 07 '16 at 23:29
  • Well, I guess this is part of why they call it "unstable/testing", so you've potentially noticed an issue, although it may have to do with the state of the system when it was upgraded. You could report it but OTOH, it's significant enough that it is almost certain to be picked up by those responsible sooner or later anyway. – goldilocks Aug 07 '16 at 23:39
  • @goldilocks but brcmfmac4340-sdio.bin failed with error -2 – Wert Aug 08 '16 at 02:39
  • @goldilocks in Debian, testing is almost perfectly unable. – Wert Aug 08 '16 at 03:11
  • To the extent I've used it I agree (actually the first version of Debian I remember was "slink", 2.1, when they differentiated the testing version by using .1 instead of rolling forward into them) -- but same with Raspbian; I used jessie when it was testing and I was using stretch for a while almost a year ago, just that card has been on the shelf. Anyway, I think an additional issue w/ Raspbian is there is not nearly as many people involved but they are basically incorporating the entire Debian repo into a distro that is tweaked in various odd ways, including how the kernel is dealt with. – goldilocks Aug 08 '16 at 11:10
  • I am positive they do not have the people to attend to apply human oversight to the incorporation of each package, so there could easily be all kinds of little issues sneak in. The problem with brcmfmac4340-sdio.bin -- is that from the logs? It's odd because you are using the current kernel (I'm sure that's the one in my 3). That .bin file is a piece of firmware included w/ the kernel, so first check if it actually exists: It should be in /lib/firmware/brcm. – goldilocks Aug 08 '16 at 11:16
  • If it isn't, or that directory is not there, there's your problem; stretch has perhaps replaced the kernel's firmware directory (unlike modules, there is only one, not one per kernel version) with the one from standard Debian. Oddly, none of it seems to be in the github binary repo -- but that whole brcm directory is not in the vanilla tree either. :/ The easiest place to get it might be out of a Raspbian jessie-lite image (see here for how to get it out). – goldilocks Aug 08 '16 at 11:22
  • @goldilocks its there – Wert Aug 08 '16 at 17:30

4 Answers4

7

The package that provides the Wi-Fi firmware is called firmware-brcm80211. To downgrade this package to a version that works:

sudo apt-get install firmware-brcm80211=0.43+rpi5

To prevent this package from being upgraded (either before an upgrade to stretch, or after downgrading the firmware):

sudo apt-mark hold firmware-brcm80211
NobodyNada
  • 171
  • 1
  • 4
3

Same problem here. Upgraded raspbian jessie to raspbian stretch and lost wifi (due to the upgrading of firmware-brcm80211 package). Just copied the contents of /lib/firmware/brcm from raspbian jessie (from another pi) and rebooted. Now wifi works on raspbian stretch.

William Mitchell Jr
  • 31
  • 2
2

I found a solution to this problem by the Raspberry Pi forum users iulius_felix and wdmjun (link to original answer):

  1. Get brcmfmac43430-sdio.bin and brcmfmac43430-sdio.txt from this repo or from the /lib/firmware/brcm folder of a working Raspberry Pi.
  2. Copy the above mentioned files to /lib/firmware/brcm on the problematic Raspberry Pi.
  3. Reboot the Raspberry Pi.
stefanblaginov
  • 21
  • 2
0

This Blogpost suggests, that you can use the kernel commandline to disable the wifi-device name changes introduced in stretch. Adding net.ifnames=0 to cmdline.txt on the boot partition should do the trick.

fps
  • 1