UWN-200 WiFi Dongle support in 3.14 kernels...

I have recently started to try out the new 3.14.19-ti kernel using the 2014-09-03 image.

Apparently the UWN-200 (Ralink) WiFi dongle is no longer recognized in the 3.14 kernel. Seems to work fine in with the 3.8 kernel.

From the 3.14.19-ti-r26 kernel dmesg:

[ 32.371373] usb 2-1.4.3: device v148f p7601 is not supported
[ 32.384124] usb 2-1.4.3: New USB device found, idVendor=148f, idProduct=7601
[ 32.384151] usb 2-1.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3

And in the rootfs:

ls /lib/modules/3.14.19-ti-r26/kernel/drivers/net/wireless
at76c50x-usb.ko libertas p54 rtl818x ti zd1211rw
ath mwifiex rt2x00 rtlwifi zd1201.ko

Whilst for the 3.8 kernel:

ls /lib/modules/3.8.13-bone64/kernel/drivers/net/wireless
at76c50x-usb.ko brcm80211 mac80211_hwsim.ko rndis_wlan.ko ti
ath hostap mt7601Usta.ko rt2x00 zd1201.ko
b43 libertas mwifiex rtl818x zd1211rw
b43legacy libertas_tf p54 rtl8192cu

I don’t see the mt7601Usta.ko module in the 3.14 area.

Is this chipset no longer supported in the 3.14 kernel? Is it inadvertently missing?

Cheers,

ba

sudo apt-get install mt7601u-modules-`uname -r`
sudo depmod -a `uname -r`
sudo update-initramfs -uk `uname -r`

Regards,

sudo apt-get install mt7601u-modules-uname -r
sudo depmod -a uname -r
sudo update-initramfs -uk uname -r

Done. Still no go. dmesg:

[ 31.962611] usb 2-1.4.3: device v148f p7601 is not supported
[ 31.974163] usb 2-1.4.3: New USB device found, idVendor=148f, idProduct=7601
[ 31.974191] usb 2-1.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 31.978577]
[ 31.978577]
[ 31.978577] === pAd = e0de5000, size = 860808 ===
[ 31.978577]
[ 31.979148] ERROR: 256 KiB atomic DMA coherent pool is too small!
[ 31.979148] Please increase it with coherent_pool= kernel parameter!
[ 32.014321] ← ERROR in Alloc Bulk buffer for HTTxContext!
[ 32.014353] —> RTMPFreeTxRxRingMemory
[ 32.014394] <— RTMPFreeTxRxRingMemory
[ 32.014405] ERROR!!! Failed to allocate memory - TxRxRing
[ 32.015109] ← RTMPAllocAdapterBlock, Status=3
[ 32.015759] rt2870: probe of 2-1.4.3:1.0 failed with error -1

I do see the new driver:

ls /lib/modules/3.14.19-ti-r26/kernel/drivers/net/wireless
at76c50x-usb.ko ath libertas mt7601Usta.ko mwifiex p54 rt2x00 rtl818x rtlwifi ti zd1201.ko zd1211rw

ba

We are closer.. :wink: (someday i should actually take those modules out
of the bag and really test. :wink: )

can you add:

coherent_pool=2M

To the "cmdline" option in /boot/uEnv.txt

cmdline=<whats there> coherent_pool=2M

and retest..

Regards,

We are closer… :wink: (someday i should actually take those modules out
of the bag and really test. :wink: )

Ha! And some day I’ll get around to buying a couple TP-Link TL-WN722N and stop having to muck around with this stuff!

can you add:

coherent_pool=2M

Done. Well, that got rid of the alloc errors. Still get the unknown device in dmesg, but apparently that is to be expected as other devices that load correctly seem to exhibit the same unknown device message.

Now onwards through the fog…

I have the following in /etc/network/interfaces (sans actual AP ssid and credentials) which worked just fine with 3.8:

auto wlan0
iface wlan0 inet dhcp
wpa-ssid “xxxx”
wpa-psk “yyyy”

Logic Supply UWN-200 (RaLink)

auto ra0
iface ra0 inet dhcp
wpa-ssid “xxxx”
wpa-psk “yyyy”

I now need to manually enable the link (ifup ra0) to get the interface to come up. Shouldn’t these interfaces come up at boot time due to the “auto” stanza? They did in 3.8. Has something changed in 3.14 that prevents the interface from coming up automagically at boot time? I have the same problem with another USB dongle, I need to manually enable the link (ifup wlan0).

And of course…when I unplugged the 2 dongles (that were both up), everything froze (no panic, no nice blue led’s flashing, just the power led on). I think its the Realtec dongle that was on wlan0. Rebooted, with just the Realtec dongle, can plug and unplug it with no problems. But if I enable the link (ifup wlan0), then unplug it, boom. Doing the same with the UWN-200 RaLink dongle doesn’t seem to cause the same crash/hang.

Note that neither the UWN-200 nor the Realtec devices are successfully associating with the AP configured in /etc/network/interfaces. They associate just fine in 3.8 with the same /etc/network/interfaces.

Geez, back to WiFi dongle hell…

ba

Brian

I am having WLAN problems similar to yours in 3.14: freezes, having to manually bring up the link, etc. Wired links work fine. Did you make any progress? A couple of things I found along the way that might help you or others.

  • “iwconfig” in 3.14 says my dongle has no wireless extensions. But “iw” works properly. I believe that iwconfig is being depracated in favor of iw.

  • newer kernels are apparently defaulting to inhibiting RF output. I figured this out when I tried to do an “ifconfig wlan0 up” in Jessie and it complained it couldn’t because of “rfkill”. Doing this in wheezy just failed silently… nice. Doing “apt-get install rfkill” followed by “rfkill unblock all” got that working. Next I have to tell systemd to remember that across reboots.

I have a TP-Link dongle that causes the kernel to Ooops, and a ZD1211-based one that doesn’t see the outside world even after it gets an IP address via me manually running “dhclient wlan0” on it. I feel your pain.

DeKay,

No, unfortunately I have not gotten back to this. The BBB is my occasional hobby, and I have not had the time recently to get back to things. And, I am finding it a challenge to keep up with the plethora of snapshots and kernel upgrades…not quite sure what to choose as a “stable” option so that I can actually do something useful besides flashing snapshots and updating kernels. But, I have recently made good on my threat to acquire some TP-Link dongles, so I will try things out when I have a chance (traveling this week, so probably won’t get to this for a week or so).

I am having WLAN problems similar to yours in 3.14: freezes, having to manually bring up the link, etc. Wired links work fine. Did you make any progress? A couple of things I found along the way that might help you or others.

I’d like to try my scenarios again with the latest 3.14 kernels using the TP-Link. Have you tried the latest and greatest? Not sure I really care about anything any more besides the Atheros chip sets as everything else seems to be a huge waste of time.

  • “iwconfig” in 3.14 says my dongle has no wireless extensions. But “iw” works properly. I believe that iwconfig is being depracated in favor of iw.

Yes, that is also my understanding.

  • newer kernels are apparently defaulting to inhibiting RF output. I figured this out when I tried to do an “ifconfig wlan0 up” in Jessie and it complained it couldn’t because of “rfkill”. Doing this in wheezy just failed silently… nice. Doing “apt-get install rfkill” followed by “rfkill unblock all” got that working. Next I have to tell systemd to remember that across reboots.

Interesting. Guess I need to have a look at rfkill, thats a new one on me. So, are you thinking that in newer kernels (beyond 3.8), the default is to not obey the enable on boot stanzas in /etc/networking/interfaces? That additional stuff is needed? Can someone confirm or deny this assumption? Seems a bit odd that this is necessary, but I suppose it would explain the observed behavior. Has anyone else had this type of problem with enabling wireless interfaces in 3.14 kernels?

I have a TP-Link dongle that causes the kernel to Ooops, and a ZD1211-based one that doesn’t see the outside world even after it gets an IP address via me manually running “dhclient wlan0” on it. I feel your pain.

Yes, like I said I never got back to this. It feels like deju vu all over again with WiFi dongles. One of the reasons I caved in and bought a bunch of TP-Link dongles is that most of the recommendations indicate that the Atheros chipset and the ath9k_htc driver is one of the better options. Is anyone else using WiFi dongles with 3.14?

BTW, I never saw a kernel ooops. It just hung, no dmesg, no console log indications. But, the hang was when I unplugged the dongle on an enabled interface. A bit different than what you are seeing I believe, except for the common fact that we cannot actually send traffic thru the dongle/interface to the outside world. It seems implausible that everyone else is also not able to send traffic thru the wireless interface on newer kernels without a flurry of reports here, so I am thinking we are missing something. Could this be something with the gateway config having changed in newer kernels? I can’t remember whether I could get to the BBB via WiFi from a machine on the same subnet as I probably was SSHing to the BBB via a hardwired ethernet connection. It might be interesting to see if you can access the BBB via WiFi from a machine on the same subnet (without a hardwired ethernet connection) if you haven’t already done so.

On side note, the kernel command line option was indicated not via an ooops, but a failure to load the driver as I remember. The error was pretty clear in the dmesg log. The solution wasn’t, but Robert got me past that quite quickly.

ba

DeKay,

No, unfortunately I have not gotten back to this. The BBB is my occasional hobby, and I have not had the time recently to get back to things. And, I am finding it a challenge to keep up with the plethora of snapshots and kernel upgrades…not quite sure what to choose as a “stable” option so that I can actually do something useful besides flashing snapshots and updating kernels.

Exactly this.

But, I have recently made good on my threat to acquire some TP-Link dongles, so I will try things out when I have a chance (traveling this week, so probably won’t get to this for a week or so).

I am having WLAN problems similar to yours in 3.14: freezes, having to manually bring up the link, etc. Wired links work fine. Did you make any progress? A couple of things I found along the way that might help you or others.

I’d like to try my scenarios again with the latest 3.14 kernels using the TP-Link. Have you tried the latest and greatest?

The latest 3.14 kernels, yes.

https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/e7RVYNowOEQ

Not sure I really care about anything any more besides the Atheros chip sets as everything else seems to be a huge waste of time.

The TP-Link dongle I have is Ooopsing my kernel right now :frowning:

Interesting. Guess I need to have a look at rfkill, thats a new one on me. So, are you thinking that in newer kernels (beyond 3.8), the default is to not obey the enable on boot stanzas in /etc/networking/interfaces? That additional stuff is needed? Can someone confirm or deny this assumption? Seems a bit odd that this is necessary, but I suppose it would explain the observed behavior. Has anyone else had this type of problem with enabling wireless interfaces in 3.14 kernels?

What I do know is that my eth0 was completed commented out after I flashed my Bone with 3.14, yet the wired network interface came up without issue in /etc/network/interfaces. Now that I think about it, the image I flashed for Jessie contains lxqt, so maybe there is kind of tool working behind the scenes. I’m doing everything from a serial console and might not have noticed this.

… Ah, I see that connman is working behind the scenes. Hmmmm…

I have a TP-Link dongle that causes the kernel to Ooops, and a ZD1211-based one that doesn’t see the outside world even after it gets an IP address via me manually running “dhclient wlan0” on it. I feel your pain.

Could this be something with the gateway config having changed in newer kernels? I can’t remember whether I could get to the BBB via WiFi from a machine on the same subnet as I probably was SSHing to the BBB via a hardwired ethernet connection. It might be interesting to see if you can access the BBB via WiFi from a machine on the same subnet (without a hardwired ethernet connection) if you haven’t already done so.

Between crashes on the Atheros stick, I was able to get a network connection by bringing it up manually.

rfkill unblock all
ifconfig wlan0 up
iw wlan0 connect essidname (my network is wide open)
dhclient wlan0

I later found I could also get the network going with the ZD1211 stick with the old USB extender cable trick, but I got DUP packets out of it during a ping. Never saw those before, but Google says DUP packets are a sign your network setup is a mess. The Atheros stick, when it worked, never gave DUP packets.

Well, so much for that. With my ZD1211 stick connected via a USB extension cable…

root@beaglebone:~# ifconfig
wlan0 Link encap:Ethernet HWaddr 00:11:e2:01:85:9d
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)

root@beaglebone:~# connmanctl scan wifi
Error /net/connman/technology/wifi: Not supported
root@beaglebone:~# iw wlan0 connect Wlan1-97AA60
root@beaglebone:~# connmanctl scan wifi
Error /net/connman/technology/wifi: Not supported
root@beaglebone:~# dhclient wlan0
root@beaglebone:~# ifconfig
wlan0 Link encap:Ethernet HWaddr 00:11:e2:01:85:9d
inet addr:176.16.1.62 Bcast:176.16.1.255 Mask:255.255.255.0
inet6 addr: fe80::211:e2ff:fe01:859d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:43 errors:0 dropped:0 overruns:0 frame:0
TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8261 (8.0 KiB) TX bytes:10616 (10.3 KiB)
root@beaglebone:~# ping www.google.com
<no response this morning, gave me DUPs yesterday>

Sigh…

FWIW, I should note that my original problems were on a wheezy image. I switched back and forth between a 3.8 and a 3.14 kernel. My problems were all with the 3.14 kernel.

I am not familiar with jessie as of yet. So, your problems may be modulated by that too besides the kernel. Does jessie use systemd? Does jessie use a different wireless configuration mechanism than wheezy? I suppose its time to do some research unless someone has already dealt with wireless configuration with jessie and cares to weigh in.

ba