rPi+HM4 LAN and WiFi Issue


Eric Thomas

TVWBB Member
I'm moving my future musings about my Wireless stability issues here to keep from cluttering other threads. I'm not looking for any quick resolution feedback, but I want to keep posting findings as I dig deeper in case anyone else has similar problems. If anyone happens to have an idea, please let me know.

The log below was captured today with the HM4+rPi running with the Edimax wireless chip.
In this setup, I have both lan and wlan enabled, but there is no ethernet cable connected.

Feb  9 09:53:32 kernel: [ 3277.225589] cfg80211_rtw_add_virtual_intf, ifname=tmp.wlan0, type=2
Feb  9 09:53:32 kernel: [ 3277.228970] ndev=  (null)
Feb  9 09:53:32 sysinit: 09:53:32,54 min,-67 dBm
Feb  9 09:54:02 kernel: [ 3307.481017] cfg80211_rtw_add_virtual_intf, ifname=tmp.wlan0, type=2
Feb  9 09:54:02 kernel: [ 3307.484323] ndev=  (null)
Feb  9 09:54:02 sysinit: 09:54:02,55 min,-67 dBm
Feb  9 09:54:32 kernel: [ 3337.652658] cfg80211_rtw_add_virtual_intf, ifname=tmp.wlan0, type=2
Feb  9 09:54:32 kernel: [ 3337.655927] ndev=  (null)
Feb  9 09:54:32 sysinit: 09:54:32,55 min,-67 dBm
Feb  9 09:55:02 kernel: [ 3367.823684] cfg80211_rtw_add_virtual_intf, ifname=tmp.wlan0, type=2
Feb  9 09:55:02 kernel: [ 3367.826960] ndev=  (null)
Feb  9 09:55:02 sysinit: 09:55:02,56 min,-67 dBm
Feb  9 09:55:33 kernel: [ 3397.995044] cfg80211_rtw_add_virtual_intf, ifname=tmp.wlan0, type=2
Feb  9 09:55:33 kernel: [ 3397.998404] ndev=  (null)
Feb  9 09:55:33 sysinit: 09:55:33,56 min,-61 dBm
Feb  9 09:56:03 kernel: [ 3428.166231] cfg80211_rtw_add_virtual_intf, ifname=tmp.wlan0, type=2
Feb  9 09:56:03 kernel: [ 3428.169560] ndev=  (null)
Feb  9 09:56:03 sysinit: 09:56:03,57 min,-61 dBm
Feb  9 09:56:33 kernel: [ 3458.386982] cfg80211_rtw_add_virtual_intf, ifname=tmp.wlan0, type=2
Feb  9 09:56:33 kernel: [ 3458.390356] ndev=  (null)
Feb  9 09:56:33 sysinit: 09:56:33,57 min,-90 dBm
Feb  9 09:57:03 kernel: [ 3488.557924] cfg80211_rtw_add_virtual_intf, ifname=tmp.wlan0, type=2
Feb  9 09:57:03 kernel: [ 3488.561252] ndev=  (null)
Feb  9 09:57:03 sysinit: 09:57:03,58 min,-94 dBm
Feb  9 09:57:06 kernel: [ 3491.756614] usb 1-1.1: USB disconnect, device number 3
Feb  9 09:57:06 netifd: lan (201): Read error: Network is down, reopening socket
Feb  9 09:57:06 kernel: [ 3491.760180] smsc95xx 1-1.1:1.0: eth0: unregister 'smsc95xx' usb-bcm2708_usb-1.1, smsc95xx
Feb  9 09:57:06 kernel: [ 3491.774887] usb 1-1.3: USB disconnect, device number 4
Feb  9 09:57:06 kernel: [ 3491.778625]
Feb  9 09:57:06 kernel: [ 3491.778640] cfg80211_rtw_disconnect
Feb  9 09:57:06 kernel: [ 3491.784813] rtw_cfg80211_indicate_disconnect
Feb  9 09:57:06 kernel: [ 3491.788087] cfg80211_rtw_del_key
Feb  9 09:57:06 kernel: [ 3491.791193] cfg80211_rtw_del_key
Feb  9 09:57:06 kernel: [ 3491.794117] cfg80211_rtw_del_key
Feb  9 09:57:06 kernel: [ 3491.796890] cfg80211_rtw_del_key
Feb  9 09:57:06 kernel: [ 3491.799613] cfg80211_rtw_del_key
Feb  9 09:57:06 kernel: [ 3491.802228] cfg80211_rtw_del_key
Feb  9 09:57:06 kernel: [ 3491.804795] rtw_cfg80211_indicate_disconnect
Feb  9 09:57:06 kernel: [ 3491.807296] pwdev->sme_state=0
Feb  9 09:57:07 kernel: [ 3491.958592] cfg80211: Calling CRDA to update world regulatory domain
Feb  9 09:57:07 netifd: lan (201): udhcpc: bind: No such device
Feb  9 09:57:07 netifd: Interface 'lan' is now down
Feb  9 09:57:07 netifd: wireless (459): udhcpc: SIOCGIFINDEX: No such device

So, for some reason, USB is disconnecting. I captured a nearly identical event shortly after this without the HM board connected (rPi only) and with lan disabled (ifdown eth0). usb is reset a number of times using dwc_otg, but continues to disconnect after 30-40 seconds. This is consistent with the LAN failures and resets that I saw when only using eth0.

Unplugging the Edimax usb rebooted the rPi board.
How big is your power supply? From what I've read, the single biggest contributor to rPi instabilities are related to a too small power supply.

How big is your power supply? From what I've read, the single biggest contributor to rPi instabilities are related to a too small power supply.


Yeah, I was going to ask about this earlier, as I have heard the same.

I have no wifi instability issues, but my rPi will reboot if I unplug the Edimax dongle as well.
When I first set mine up, I tried to power it with a 5v phone charger via USB, and couldn't get the Edimax dongle to stay powered up. EDIT: Wanted to add, this was supposedly a 1A wall charger for a phone. Appears it didn't quite put out that much.

As soon as I powered it with the 12v wall wart, it was rock solid.

Yeah don't unplug the Edimax dongle while the power is on if you want your LinkMeter to not reboot. The driver does not support device removal.
No real solutions yet, but a few updates in my ongoing testing:

0. The problem is repeatable, but not deterministic. When it occurs once, after powering off for 60+ seconds and rebooting, the problem will typically occur again within a few minutes.
1. @Dave: Thanks, but I've mostly ruled out power supply problems since I'm now using a 5A 12V bench supply. I've been using 1A and 1.2A 12V wall warts, but I'm becoming convinced this issue is unrelated to the common rPi pwr supply issues. Also, I'm using a rev B which provides more current to the SMSC LAN9512.
2. 3.3V and 1.8V supplies to the rPi LAN9512 look good under normal conditions. TODO: I want to remeasure when my USB goes offline.
3. There are other reports of this same USB disappearing problem by rPi users. Most people seem to solve the problem by just switching over to the 3.6 kernel (latest raspbian) which has the rtl8192cu driver built in; end of story.
4. Thinking that some of the newer dwg_otg usb work might help, I started cherry-picking patches and created openwrt compatible patch sets that I added to Bryan's build process (for 3.3 kernel). These include commits:
(for those paying close attention ... these are all renamed to 06x0- level patches when moved into the openwrt build)

However, even with fiq and microscheduler enabled, my usb is still dropping out.

5. Just for kicks, I booted the HM/openwrt FS with a hand-built 3.6.11+ kernel. Works great over ethernet. The kernel recognizes the 8192cu and it shows up in /sys; but the openwrt wireless config tools cannot find it. I don't know enough about the openwrt wifi config to know yet whether this is something minor in the radio config, but I suspect that it is expecting a different cfg80211/mac80211 interface that the 3.6.11 driver doesn't have. The rtl8192cu driver in 3.6.11+ is not using #define CONFIG_IOCTL_CFG80211 (which Bryan enables with a patch for 3.3 kernel) ... enabling this in 3.6.11+ breaks the build since cfg80211 definitions/interfaces have changed and those portions were not updated when it was merged into 3.6.

Bryan: How important is CONFIG_IOCTL_CFG80211 to getting an wifi driver working with openwrt? I see that you pulled in compat-wireless to the rtl8192cu driver; I presume so that the realtek 3.4 kernel driver would work with the 3.3 kernel ?? For the 3.6 kernel, what I guess is needed is a way to add the older 3.3 kernel interfaces for cfg80211 back in so that the rtl driver compiles.

So, the net-net is that either I have not hit on the right patches for 3.3 kernel yet, I'm going to need openwrt rPi to update do 3.6 kernel, or I'm pursuing a one-off HW issue.

Now, I'm finally going to let the raspbian wheezy 3.6.11+ kernel run for a few days on my rPi, with and without the LM board attached, just to rule out the HW problem possibility.

- eric
Last edited:
Well, since my last post my rPi+HM has been running flawlessly without any USB or WiFi dropouts using Bryan's stock HM build. This is either great news for me or a clear sign that the spirits are waiting to return during my next long smoke. only time will tell ...
I just wish I knew what changed.
Oh man I seem to have missed this back when you posted Feb-20. I'll provide a little more information about the driver build for posterity sake.

First and foremost, Attitude Adjustment OpenWrt (as well as Linux in general) uses nl80211 as the standard mechanism of accessing wireless devices and is trying to phase out "wext". nl80211 is a handful of modules and standard interfaces but really cfg80211 is the one you see the most (followed by mac80211, for software mac devices). Supporting the CONFIG_IOCTL_CFG80211 define is vital to OpenWrt wireless tools support as I know it. I see a lot of code in Wrt still refers to wext, so there may be a way to use that?

I'm not sure what interface the 8192cu driver supports out of the box, but it sure ain't cfg80211. I'm not even sure what devices the standard rtl8192cu driver that's in the linux kernel supports, but it sure ain't these Edimax or Rosewill devices. Note the difference there: the stock linux kernel is rtl8192cu, which relies on rtlwifi and a whole shmorgasbord of other modules, as well as requiring a firmware file in /lib/firmware. The 8192cu I custom compile has the firmware and all of the rtlwifi built into the module itself, relying simply on cfg80211. I believe the wifi driver in raspbian is actually a custom 8192cu, and not the standard rtl8192cu from the mainlines.

The 8192cu package relies on compat-wireless solely as a build prerequisite. In fact, the 8192cu package is incompatible with an installed compat-wireless. Compat wireless is not at all what it sounds like and actually is just a way of interfacing manufacturer "blob" drivers with an incompatible off-brand of cfg80211. This difference meant that something built for real mainstream cfg80211 won't work at all with it, by design.
My wifi & USB did start crashing again, fortunately before I started a long cook.

With the information from Bryan, I managed to get HM and OpenWrt running on a 3.6 kernel with the 8192cu driver in wext mode.
However, about an hour into my smoke, USB dropped out again.
I rebooted, and switched to wired ethernet and again the HM worked like a charm.

Anyway, this narrows my strange issue down to either the rPi board or my Access Point. Several people have suggested that a lot of similar sounding issues are caused by odd AP parameter, low-power mode, or some non-standard communication that propagates into the wifi driver and ends up crashing USB.
So, now I've switched to a different AP and will continue testing for a few weeks ...
After your comment I thought maybe it had something to do with the power management mode of the wifi adapter so I was going to suggest turning it on/off via cfg80211. Although the command works `iw dev wlan0 set power_save off`, I just looked at the source code and all it does it return true so power management isn't implemented for cfg80211.

It looks like it is for wext, but it uses a conservative power management mode by default, waking every beacon interval which I think would be the most reliable. None of this is useful information, but at least it doesn't appear to be defaulting to a too-conservative power management mode.
Just to close out on this thread, I seemed to resolved the problem by changing out my access point.
The problems I was experiencing all occurred when connecting to an ASUS RT-N16 running dd-wrt.
I don't know what was causing the wifi disconnects and subsequent usb crashes, but I'm suspecting some kind of driver <--> AP issue.
However, I've been running stable 24/7 for about 3 weeks connected to my AT&T Uverse router and another 3 weeks to the RT-N16 w/ tomato.
- Eric