0

Is there a new way to configure WiFi on Raspbian because since I upgraded to 4.4.13, my pi's WiFi broke.

pi@Y3moP1:~ $ sudo iwlist wlan0 scan
  wlan0     Interface doesn't support scanning.

If I don't get that warning then it's something like 'Interface is busy'!

I had a perfectly functioning raspberry pi 2 until I upgraded the firmware to 4.4.13-v7+.

pi@Y3moP1:~ $ uname -r
  4.4.13-v7+

After that WiFi stopped working. Actually, the interface wlan0 won't go up. I didn't update the /etc/network/interfaces given that the warning in the header discourages to do so. So here is what I have:

pi@Y3moP1:~ $ cat /etc/network/interfaces
  # interfaces(5) file used by ifup(8) and ifdown(8)

  # Please note that this file is written to be used with dhcpcd
  # For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

  # Include files from /etc/network/interfaces.d:
  source-directory /etc/network/interfaces.d

  auto lo
  iface lo inet loopback

  iface eth0 inet manual

  allow-hotplug wlan0
  iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

  allow-hotplug wlan1
  iface wlan1 inet manual
      wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

However, I updated my wpa_supplicant.conf to include 2 WiFi networks - both unencrypted, one hidden - for testing purposes.

pi@Y3moP1:~ $ sudo cat /etc/wpa_supplicant/wpa_supplicant.conf 
  country=TG
  ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
  update_config=1

  network={
      ssid="R3B3LZ"
      scan_ssid=1
      key_mgmt=NONE
  }

  network={
      ssid="dd-wrt"
      key_mgmt=NONE
  }

First off, I am using a Ralink RT5370, and it is being picked up.

pi@Y3moP1:~ $ lsusb
  Bus 001 Device 004: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
  Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
  Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. 
  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Second, all the drivers seem to be up and loaded. At least the ones Ralink wifi devices require.

pi@Y3moP1:~ $ lsmod
  Module                  Size  Used by
  bnep                   10340  2 
  bluetooth             326105  5 bnep
  arc4                    1958  2 
  rt2800usb              17554  0 
  rt2800lib              71894  1 rt2800usb
  rt2x00usb               8943  1 rt2800usb
  rt2x00lib              37529  3 rt2x00usb,rt2800lib,rt2800usb
  mac80211              532034  3 rt2x00lib,rt2x00usb,rt2800lib
  cfg80211              427855  2 mac80211,rt2x00lib
  crc_ccitt               1278  1 rt2800lib
  rfkill                 16037  4 cfg80211,bluetooth
  snd_bcm2835            20511  1 
  snd_pcm                75698  1 snd_bcm2835
  snd_timer              19160  1 snd_pcm
  snd                    51844  5 snd_bcm2835,snd_timer,snd_pcm
  bcm2835_gpiomem         3040  0 
  bcm2835_wdt             3225  0 
  uio_pdrv_genirq         3164  0 
  uio                     8000  1 uio_pdrv_genirq
  i2c_dev                 5859  0 
  fuse                   83461  3 
  ipv6                  347530  46

Third, here's what I get when I run ifconfig -a

pi@Y3moP1:~ $ sudo ifconfig -a
  eth0      Link encap:Ethernet  HWaddr b8:27:eb:bc:26:83  
        inet addr:192.168.1.145  Bcast:192.168.1.255  Mask:255.255.255.0
        inet6 addr: fe80::fb39:efaf:b2bf:2a4a/64 Scope:Link
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:2937 errors:0 dropped:7 overruns:0 frame:0
        TX packets:2186 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1000 
        RX bytes:199598 (194.9 KiB)  TX bytes:276407 (269.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:65536  Metric:1
        RX packets:223 errors:0 dropped:0 overruns:0 frame:0
        TX packets:223 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1 
        RX bytes:20740 (20.2 KiB)  TX bytes:20740 (20.2 KiB)

  wlan0     Link encap:Ethernet  HWaddr 00:13:ef:c0:05:a9  
        inet6 addr: fe80::475a:4576:d95:13f4/64 Scope:Link
        UP BROADCAST 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)

NOTE: I did attempt to modify the network interfaces file to replace 'manual' with 'dhcp' and to add 'auto wlan0' like I used to but that didn't fix things at all.

But eth0 and wired connections to my modem work fine with SSH and all.

  • Did you see any errors in the output of dmesg ? – Shreyas Murali Oct 2 '16 at 18:55
  • @ShreyasMurali: good call. the dmesg show a warning like [ 83.979381] ieee80211 phy0: rt2800usb_tx_sta_fifo_read_completed: Warning - TX status read failed -71 repeated 100+ times. – igreka Oct 3 '16 at 17:08
1

Part 1 - Clarifying the terminology

I like to visualize the different parts like so

[kernel] <=> [device driver] <=> [firmware] <=> [physical device]

sometimes a device might not require a specialized firmware and the driver can directly communicate with the physical device.

here are some common commands and the o/p they produce:

uname -a : gives you the kernel version (4.4.13-v7+ in your case)

cat /etc/os-release : gives you the friendly OS version (e.g raspbian/wheezy or raspbian/jessie)

apt list --installed *firm* : gives you the list of all packages that have a the word firm in their names

modinfo rt2800usb : gives you the version details of the driver loaded for the ralink usb wifi dongle

for completeness sake, i will add lsmod : gives you the list of drivers (kernel modules) that are currently loaded

In your case it appears both the kernel and the driver (rt2800usb) have been updated successfully.

Part 2 - Diagnosing the problem

Searching for rt2800usb_tx_sta_fifo_read_completed in the linux source code cross reference I found it located here.

Clicking the identifier took me to a page that lists all the references and one such reference is the method, rt2x00usb_register_read_async which is located here.

The method rt2800usb_tx_sta_fifo_read_completed has been passed in as a callback to be executed when the read completes (successfully or not)

183 void rt2x00usb_register_read_async(struct rt2x00_dev *rt2x00dev,
184                                    const unsigned int offset,
185                                    bool (*callback)(struct rt2x00_dev*, int, u32))
186 {
187         struct usb_device *usb_dev = to_usb_device_intf(rt2x00dev->dev);
188         struct urb *urb;
189         struct rt2x00_async_read_data *rd;
190 
191         rd = kmalloc(sizeof(*rd), GFP_ATOMIC);
192         if (!rd)
193                 return;
194 
195         urb = usb_alloc_urb(0, GFP_ATOMIC);
196         if (!urb) {
197                 kfree(rd);
198                 return;
199         }
200 
201         rd->rt2x00dev = rt2x00dev;
202         rd->callback = callback;
203         rd->cr.bRequestType = USB_VENDOR_REQUEST_IN;
204         rd->cr.bRequest = USB_MULTI_READ;
205         rd->cr.wValue = 0;
206         rd->cr.wIndex = cpu_to_le16(offset);
207         rd->cr.wLength = cpu_to_le16(sizeof(u32));
208 
209         usb_fill_control_urb(urb, usb_dev, usb_rcvctrlpipe(usb_dev, 0),
210                              (unsigned char *)(&rd->cr), &rd->reg, sizeof(rd->reg),
211                              rt2x00usb_register_read_async_cb, rd);
212         usb_anchor_urb(urb, rt2x00dev->anchor);
213         if (usb_submit_urb(urb, GFP_ATOMIC) < 0) {
214                 usb_unanchor_urb(urb);
215                 kfree(rd);
216         }
217         usb_free_urb(urb);
218 }

from the above definition it appears the USB read call is failing with error code -71 and thats what is getting printed in dmesg

so WTH does-71 mean ? Again googling around, I found a number of posts such as

  • this which claims is a problem with usbcore and also suggests a fix like so

An internet search indicated this is not an uncommon problem, and usbcore, which is compiled as a module in Hardy’s kernel, seems to be the culprit. Plenty of suggestions were offered online (including recompiling the kernel) but most of them did not help me at all. Finally, I found something on an old mailing list that solved the problem. All I needed to do was add the following line to /etc/modprobe.d/options: options usbcore use_both_schemes=y (If you are curious as to why this solved the problem, please read this clear explanation.)

  • this which claims it is current consumption related.

And found a few more like those.

Since you have mentioned the device used to work prior to updating, I m inclined to think update might have broken compatiblity with the firmware package (firmware-ralink) installed which is showing up with different error messages.

If you can check the version of the firmware installed by running apt list --installed firmware-ralink and share the details, it might help identifying/narrow down the problem.

You could also try updating the firmware package like so apt-get install --only-upgrade firmware-ralink and checking it it makes a difference.


You could also try the following to check if it actually power supply related

  • use a 5V, 2A+ power supply
  • disconnect all unnecessary usb devices (keyboard/mouse/hub/flash drive etc) and use ssh via ethernet to login
  • It seems modprobe does not have an option file. Also I have the latest firmware-ralink version. I also only had the WiFi Usb dongle plugged in while SSH-ing into the Pi via Ethernet linked to a modem. Just for checks, I changed the power adaptor to the one my friend uses, to no avail. apt list --installed firmware-ralink gives firmware-ralink/stable,now 0.43+rpi5 all [installed] and the upgrade command outputs firmware-ralink is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded. – igreka Oct 4 '16 at 14:03
1

It turns out a distro upgrade solved my issue. I just followed the steps in the 'upgrading and updating' section of the documentation.

After this, the dongle worked just fine.

-1

Had the same problem, it turned out that the usb cable(s) between the pc and the usbwifi, were simply too long to provide proper power/voltage, so if you're using cable extensions, dont let them be too long and check for faulty ones

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.