OpenSprinkler › Forums › Hardware Questions › OpenSprinkler Beagle (OSBo) › Edimax Nano, disconnects and packet loss with Ubuntu image
- This topic has 16 replies, 7 voices, and was last updated 9 years, 3 months ago by Ray.
-
AuthorPosts
-
December 17, 2013 at 1:58 pm #22712
polygnwndMemberAm using the recommended Edimax Nano USB wireless adapter and it is performing terribly–
- iwconfig shows lots of “Invalid Misc” packets, but no errors.
- pinging the host from the wireless router results in high variability in response time, with about 25% packets lost and about 30% with >1000ms times
- host disappears from router entirely after about an hour
All tests run with OpenSprinkler host in the same room with router (clear line of sight), and this is not an area with lots of interference (laptop next to OSBo happily pulls 90mbps from the same router).
I see lots of discussion around the Linux drivers for this device (e.g. here and here) and am curious whether the driver in the OSBo custom image is known to work, or I need to compile an update
December 17, 2013 at 2:34 pm #25823
polygnwndMemberSome more debug info (while connected via wired Ethernet):
uname
root@arm:~# uname -a
Linux arm 3.8.13-bone28 #1 SMP Fri Sep 13 01:11:14 UTC 2013 armv7l armv7l armv7l GNU/Linuxdmesg when USB wifi adapter inserted:
[ 188.176953] usb usb1: usb wakeup-resume
[ 188.177052] usb usb1: usb auto-resume
[ 188.177105] hub 1-0:1.0: hub_resume
[ 188.177225] hub 1-0:1.0: port 1: status 0101 change 0001
[ 188.281147] hub 1-0:1.0: state 7 ports 1 chg 0002 evt 0000
[ 188.281274] hub 1-0:1.0: port 1, status 0101, change 0000, 12 Mb/s
[ 188.386435] usb 1-1: new high-speed USB device number 2 using musb-hdrc
[ 188.506564] usb 1-1: default language 0x0409
[ 188.507427] usb 1-1: udev 2, busnum 1, minor = 1
[ 188.507473] usb 1-1: New USB device found, idVendor=7392, idProduct=7811
[ 188.507511] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 188.507545] usb 1-1: Product: 802.11n WLAN Adapter
[ 188.507576] usb 1-1: Manufacturer: Realtek
[ 188.507608] usb 1-1: SerialNumber: 00xxxx00000x
[ 188.511681] usb 1-1: usb_probe_device
[ 188.511742] usb 1-1: configuration #1 chosen from 1 choice
[ 188.513465] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
[ 188.519681] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
[ 188.519802] hub 1-0:1.0: port 1 enable change, status 00000503
[ 189.260354] cfg80211: Calling CRDA to update world regulatory domain
[ 189.496848] rtl8192cu 1-1:1.0: usb_probe_interface
[ 189.496919] rtl8192cu 1-1:1.0: usb_probe_interface - got id
[ 189.497346] rtl8192cu: Chip version 0x10
[ 189.611075] rtl8192cu: MAC address: 80:1f:02:bb:fe:10
[ 189.611153] rtl8192cu: Board Type 0
[ 189.611395] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
[ 189.611783] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin
[ 189.632273] usbcore: registered new interface driver rtl8192cu
[ 189.773844] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[ 189.786898] rtlwifi: wireless switch is on
lsusb
root@arm:~# lsusb
Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hublshw
root@arm:~# lshw -C network -sanitize
*-network:0
description: Ethernet interface
physical id: 1
logical name: eth0
serial: [REMOVED]
capabilities: ethernet physical
configuration: broadcast=yes driver=TI CPSW Driver v1.0 driverversion=1.0 ip=[REMOVED] link=yes multicast=yes
*-network:1
description: Ethernet interface
physical id: 2
logical name: usb0
serial: [REMOVED]
capabilities: ethernet physical
configuration: broadcast=yes driver=g_ether driverversion=29-May-2008 firmware=musb-hdrc ip=[REMOVED] link=no multicast=yes
*-network:2 DISABLED
description: Wireless interface
physical id: 3
bus info: usb@1:1
logical name: wlan1
serial: [REMOVED]
capabilities: ethernet physical wireless
configuration: broadcast=yes driver=rtl8192cu driverversion=3.8.13-bone28 firmware=N/A link=no multicast=yes wireless=IEEE 802.11bgnlsmod
root@arm:~# lsmod
Module Size Used by
arc4 1660 2
rtl8192cu 87084 0
rtlwifi 76713 1 rtl8192cu
rtl8192c_common 59545 1 rtl8192cu
mac80211 494605 3 rtlwifi,rtl8192c_common,rtl8192cu
cfg80211 421373 2 mac80211,rtlwifi
rfkill 18327 1 cfg80211
g_multi 56263 0
libcomposite 17089 1 g_multi
Now bringing up wifi interface
root@arm:~# ifup wlan1
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/wlan1/80:1f:02:bb:fe:10
Sending on LPF/wlan1/80:1f:02:bb:fe:10
Sending on Socket/fallback
DHCPREQUEST of 192.168.1.180 on wlan1 to 255.255.255.255 port 67 (xid=0x230b0c4f)
DHCPREQUEST of 192.168.1.180 on wlan1 to 255.255.255.255 port 67 (xid=0x230b0c4f)
DHCPREQUEST of 192.168.1.180 on wlan1 to 255.255.255.255 port 67 (xid=0x230b0c4f)
DHCPACK of 192.168.1.180 from 192.168.1.1
bound to 192.168.1.180 -- renewal in 38388 seconds.
dmesg now says
[ 744.386533] rtl8192cu: MAC auto ON okay!
[ 744.454592] rtl8192cu: Tx queue select: 0x05
[ 744.912888] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 747.610632] wlan1: authenticate with [WIRELESS_AP_MAC]
[ 747.633050] wlan1: send auth to [WIRELESS_AP_MAC] (try 1/3)
[ 747.833633] wlan1: send auth to [WIRELESS_AP_MAC] (try 2/3)
[ 748.034804] wlan1: send auth to [WIRELESS_AP_MAC] (try 3/3)
[ 748.235955] wlan1: authentication with [WIRELESS_AP_MAC] timed out
[ 749.145721] wlan1: authenticate with [WIRELESS_AP_MAC]
[ 749.166245] wlan1: send auth to [WIRELESS_AP_MAC] (try 1/3)
[ 749.366823] wlan1: send auth to [WIRELESS_AP_MAC] (try 2/3)
[ 749.567988] wlan1: send auth to [WIRELESS_AP_MAC] (try 3/3)
[ 749.769168] wlan1: authentication with [WIRELESS_AP_MAC] timed out
[ 750.674845] wlan1: authenticate with [WIRELESS_AP_MAC]
[ 750.696906] wlan1: send auth to [WIRELESS_AP_MAC] (try 1/3)
[ 750.898088] wlan1: send auth to [WIRELESS_AP_MAC] (try 2/3)
[ 751.099271] wlan1: send auth to [WIRELESS_AP_MAC] (try 3/3)
[ 751.300425] wlan1: authentication with [WIRELESS_AP_MAC] timed out
[ 752.208067] wlan1: authenticate with [WIRELESS_AP_MAC]
[ 752.229125] wlan1: send auth to [WIRELESS_AP_MAC] (try 1/3)
[ 752.429323] wlan1: send auth to [WIRELESS_AP_MAC] (try 2/3)
[ 752.630493] wlan1: send auth to [WIRELESS_AP_MAC] (try 3/3)
[ 752.831660] wlan1: authentication with [WIRELESS_AP_MAC] timed out
[ 753.748137] wlan1: authenticate with [WIRELESS_AP_MAC]
[ 753.768598] wlan1: send auth to [WIRELESS_AP_MAC] (try 1/3)
[ 753.772072] wlan1: authenticated
[ 753.775149] wlan1: associate with [WIRELESS_AP_MAC] (try 1/3)
[ 753.789979] wlan1: RX AssocResp from [WIRELESS_AP_MAC] (capab=0x431 status=0 aid=1)
[ 753.791445] wlan1: associated
[ 753.791551] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes readyiwconfig after a minute or so:
root@arm:~# iwconfig wlan1
wlan1 IEEE 802.11bgn ESSID:"[MY_NETWORK_SSID]"
Mode:Managed Frequency:2.462 GHz Access Point: [WIRELESS_AP_MAC]
Bit Rate=72.2 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=-35 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:12 Missed beacon:0
December 17, 2013 at 7:12 pm #25824
polygnwndMemberSo the kernel drivers seem awful, and there is a Realtek-supplied driver that works a lot better (at least for me). Latest version seems to be available from https://github.com/pvaret/rtl8192cu-fixes/blob/master/README.md
Setup is well documented elsewhere, but there were some minor variations to make it work on the OSBo image:
- Install DKMS support for compiled kernel modules
# build-essential is already on OSBo image
apt-get install dkms - Download precompiled BB headers for OSBo kernel version
wget http://rcn-ee.net/deb/wheezy-armhf/v3.8.13-bone28/linux-headers-3.8.13-bone28_1.0wheezy_armhf.deb
dpkg --install linux-headers-3.8.13-bone28_1.0wheezy_armhf.deb
- Download and install patched driver
git clone https://github.com/pvaret/rtl8192cu-fixes.git
dkms add ./rtl8192cu-fixes
dkms install install 8192cu/1.8
# Watch your build fail due to missing timex.h dependency
- Edit /usr/src/linux-headers-3.8.13-bone28/arch/arm/include/asm/timex.h on line 18 to change
#include
to
#include
This looks pointless, but allows the build to complete (run dkms install again)
- Blacklist the native kernel module so the newly compiled module will be used instead
cp ./rtl8192cu-fixes/blacklist-native-rtl8192.conf /etc/modprobe.d/
- I’ve also disabled radio power saving as leaving it enabled fills the dmesg log with status messages and causes occasional disconnects from AP. Put the following in a new /etc/modprobe.d/8192cu.conf file
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0
Obviously these instructions and links/URLs will not age well– they work nicely as of 17 December 2013.
Now ping is not losing packets:
521 packets transmitted, 521 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.450/6.857/19.328/1.572 msDecember 18, 2013 at 2:34 pm #25825
RayKeymasterThanks for sharing your solution. Sounds great. I will give it a try and include it in the SD card image.
February 26, 2014 at 2:51 am #25826
amigolokoMemberDear Ray,
After the date: Tue Dec 17, 2013 1:12 pm and Wed Dec 18, 2013 8:34 am
of this topic,where you able to repair/upgrade the kernel, and successfully included in all new sd images?
Regards
February 26, 2014 at 7:42 pm #25827
RayKeymasterYes, working on this and should get it done within a day or two.
February 27, 2014 at 8:33 pm #25828
jgoldin9083MemberI attempted the fix, however I noticed something strange. the wifi works consistantly while the ethernet is plugged in, but when the ethernet is unplugged the wifi ceases to work. Any ideas?
March 4, 2014 at 10:46 pm #25829
RayKeymasterSo I followed these steps and I am still not able to get the Edimax Nano connected reliably at all times. The only reliable solution is to use a powered USB hub. When using the powered USB hub, the WiFi works perfectly fine with no disconnection. I think it’s more of a hardware problem (either the 24V AC to 5V DC power conversion, or the PCB design of the BeagleBone Black), and not so much of a software problem.
March 21, 2014 at 1:22 pm #25830
polygnwndMemberCould disabling HDMI (add cape disable parameter to u-boot), per https://groups.google.com/forum/#!msg/beagleboard/sIGi77LojUE/NBmoSC9_PlQJ
March 24, 2014 at 2:35 pm #25831
RayKeymasterThat’s interesting. I didn’t know about it. Will check it shortly. Thanks.
May 30, 2014 at 7:43 pm #25832
mcg1103ParticipantI also had all kinds of trouble maintaining a connection with the USB. I tried two USB wifi devices. The recommended edimax nano and one that I purchased on Ebay with a larger antenna. The one with the larger antenna had a problem with the power plug getting in the way but was able to get it plugged in. Neither worked reliably. I tried two beaglebone black boards (I use them at work so I had several at my disposal for testing). I could get it to connect once in a while but would not hold up a connection. I did not do the above mentioned fix…. found this after I found the solution below.
Finally I purchased a tp-link TL-WR702N. Running this mini router in client mode I was able to and plugging into the rj-45 ethernet port on the bbb I have had absolutely not trouble. It has worked after every reboot and has not stopped once. This device is small enough to fit in the recommended enclosure with a OSBo, one 16 station expansion board and the plug in style transformer. It is a tight fit and requires too many extra cables, but it is working.
I am running my OSBo outside, in the weather proof en-closure. I am interested to see how it holds up to the Phoenix summers. It is 99 degrees right now and it is still running 🙂 We will see what happens when the temp gets up to 115.
-Mark
June 27, 2014 at 8:26 pm #25833
sbrownParticipantI also found the same problem with the driver. After sniffing from another pc running wireshark, it appeared that the aggregation sessions between the ap and the usb radio would deadlock. I tried running in non-ht mode and the problem disappeared. Next, I modified the driver to report no hardware aggregation support and the problem disappeared too. The latter allows you to run at ht speeds.
The problem seems to be that the AP starts an aggregation session and the STA starts one also before the AP session terminates. This seems to hang the driver.
I reported the problem to the linux-wireless list.
A patch is below. It’s not a fix, just a workaround until somebody more knowledgable has time to deal with it.
Steve
==========— a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -59,6 +59,9 @@ static int rtl92cu_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
int err;+ /* disable aggregation until the deadlock is fixed */
+ hw->flags &= ~IEEE80211_HW_AMPDU_AGGREGATION;
+
rtlpriv->dm.dm_initialgain_enable = true;
rtlpriv->dm.dm_flag = 0;
rtlpriv->dm.disable_framebursting = false;June 30, 2014 at 4:45 am #25834
RayKeymasterCool. Thanks for the update. Do you know if the latest Ubuntu for BeagleBone Black has fixed the driver issue? We will be making a new image soon using the latest Ubuntu version, and hopefully the driver issue is fixed in the latest version.
June 30, 2014 at 1:01 pm #25835
sbrownParticipantNo reply to my post on linux-wireless yet.
I built a kernel from here: https://github.com/RobertCNelson/bb-kernel.git
to test the work-around.August 7, 2014 at 4:59 am #25836
RayKeymasterWhile preparing a new OSBo SD card image, I came across this website which describes a method to compile the RTL8192 driver:
http://gencarelle.com/blog/2013/07/19/problems-with-rtl8188cus/
I gave it a try and it seems to work much better than the default driver provided by the system. I followed the instructions and compiled it under kernel 3.8.13-bone56. The custom driver is now integrated into the new OSBo pre-configured SD card image, available for download at:
http://raysfiles.com/osbo/osbo2.zip
Will see from user feedback whether this indeed works more reliably or not.September 6, 2015 at 2:40 pm #40135
max_dieuParticipantRay, I recently purchased and installed the OSBo, which came with kernel version 3.8.13-bone56 armv71. Last weekend, I ordered the Edimax Nano, to find out that I’m having the same problem that have been reported by this thread. Similarly to another member description, the Edimax nano doesn’t work unless I have the usb or Ethernet plugged in. Based on your most recent post on this subject, I don’t see anyone with feedback of the resolution you have compiled in the latest image. Any suggestion is appreciated.
September 8, 2015 at 11:22 pm #40163
RayKeymasterDoes the Edimax Nano work with the latest BBB Debian OS? If so, you can follow the instructions here to install the OpenSprinkler Unified Firmware:
https://opensprinkler.freshdesk.com/solution/categories/5000027039/folders/5000149652/articles/5000631599-installing-and-updating-the-unified-firmware
The pre-configured SD card is based on an old version of kernel so it may not support the latest Edimax dongle. -
AuthorPosts
- You must be logged in to reply to this topic.
OpenSprinkler › Forums › Hardware Questions › OpenSprinkler Beagle (OSBo) › Edimax Nano, disconnects and packet loss with Ubuntu image