jkajolin Posted February 18, 2017 Posted February 18, 2017 Had some free time to toy around with Orange Pi Zero Used a image "Armbian_5.26_Orangepizero_Ubuntu_xenial_dev_4.10.0.img" build with 'compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=no PROGRESS_DISPLAY=plain RELEASE=xenial BUILD_DESKTOP=no' - which should not do anything special ? 1) First steps - run upgrades and normal tweaking (changed hostname, disabled ipv6, changed ntp, changed time-zone, generated correct locale) 2) Ensure that WLAN0 is working as client - using 'nmtui' created a new connection to my desktop WLAN router - disabled auto connect from eth0 - reboot with serial connection - run example speedtest-cli to see that the driver do work 3) Removed the client profile and redo the eth0 for auto connection 4) I used these lines to create the sample profile but them afterwards tweaked it around with nmtui 'edit profile' nmcli c add type wifi ifname wlan0 con-name ap-wlan0 autoconnect no ssid zmserver nmcli connection modify ap-wlan0 802-11-wireless.mode ap 802-11-wireless.band bg ipv4.method shared nmcli connection modify ap-wlan0 wifi-sec.key-mgmt wpa-psk nmcli connection modify ap-wlan0 wifi-sec.psk "password" nmcli connection up ap-wlan0 Key points here are 802-11-wireless.mode ap and shared - shared means that network manager creates "internet-connection sharing" like MacOS and Windows wizards - you cannot give dns-server or any other setting while using the shared - selection Ensure that the "automatically connect" is selected to make sure that the connection is started when booted 5) I do have the basic nat lines enabled with 'iptables-persistent' sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT 6) Actual profile root@iothub1:/etc/NetworkManager/system-connections# more AP [connection] id=AP uuid=8e0bb6d9-52f9-4000-bbfa-d49db6790598 type=wifi interface-name=wlan0 permissions= secondaries= timestamp=1487425840 [wifi] band=bg channel=1 mac-address-blacklist= mac-address-randomization=0 mode=ap seen-bssids=12:42:13:81:F5:29; ssid=IotHub1 [wifi-security] group= key-mgmt=wpa-psk pairwise= proto= psk=iothub123 [ipv4] dns-search= method=shared [ipv6] addr-gen-mode=stable-privacy dns-search= method=ignore Some output # nmcli d DEVICE TYPE STATE CONNECTION eth0 ethernet connected Wired connection 1 wlan0 wifi connected AP lo loopback unmanaged -- # nmcli c NAME UUID TYPE DEVICE AP 8e0bb6d9-52f9-4000-bbfa-d49db6790598 802-11-wireless wlan0 Wired connection 1 b9e400ce-f567-3f12-b459-366adc05a7f2 802-3-ethernet eth0 # ifconfig eth0 Link encap:Ethernet HWaddr 02:42:13:81:f5:29 inet addr:192.168.88.206 Bcast:192.168.88.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:45505 errors:0 dropped:0 overruns:0 frame:0 TX packets:28178 errors:0 dropped:0 overruns:0 carrier:0 collisions:20 txqueuelen:1000 RX bytes:66887562 (66.8 MB) TX bytes:2051800 (2.0 MB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 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 TX bytes:0 (0.0 wlan0 Link encap:Ethernet HWaddr 12:42:13:81:f5:29 inet addr:10.42.0.1 Bcast:10.42.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:27567 errors:0 dropped:0 overruns:0 frame:0 TX packets:44475 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1901813 (1.9 MB) TX bytes:67699829 (67.6 MB) # iwconfig wlan0 wlan0 IEEE 802.11 Mode:Master Tx-Power=20 dBm Retry short limit:7 RTS thr:off Fragment thr:off Power Management:off 7) Does it work ==> YES Is it fast ==> NO Is it realiable ==> DO NOT KNOW Feb 18 16:25:35 iothub1 wpa_supplicant[706]: wlan0: AP-STA-DISCONNECTED 78:45:61:ee:43:47 Feb 18 16:25:35 iothub1 kernel: [ 1723.628815] ieee80211 phy0: vif 0: set_key cmd 1 Feb 18 16:25:35 iothub1 wpa_supplicant[706]: Device is trying to offload WPS Probe Response while not supporting this Feb 18 16:25:38 iothub1 wpa_supplicant[706]: Device is trying to offload WPS Probe Response while not supporting this Feb 18 16:25:38 iothub1 wpa_supplicant[706]: wlan0: AP-STA-CONNECTED 78:45:61:ee:43:47 Feb 18 16:25:38 iothub1 kernel: [ 1726.789198] ieee80211 phy0: vif 0: set_key cmd 0 Feb 18 16:25:38 iothub1 kernel: [ 1726.789213] ieee80211 phy0: CCMP_PAIRWISE keylen=16! Feb 18 16:25:38 iothub1 dnsmasq-dhcp[902]: DHCPREQUEST(wlan0) 10.42.0.153 78:45:61:ee:43:47 Feb 18 16:25:38 iothub1 dnsmasq-dhcp[902]: DHCPACK(wlan0) 10.42.0.153 78:45:61:ee:43:47 ideapad Feb 18 16:26:07 iothub1 kernel: [ 1755.102706] sunxi-mmc 1c10000.mmc: smc 1 err, cmd 53, RD DCE !! Feb 18 16:26:07 iothub1 kernel: [ 1755.109460] sunxi-mmc 1c10000.mmc: data error, sending stop command 1
jkajolin Posted February 18, 2017 Author Posted February 18, 2017 It seems to have the same problem than with hostap.It works fine for a while but then the client connection starts to fail and the kernel starts to spam these messagesThere is nothing to do other than disconnect the client and try again as it seems to work again Feb 18 16:48:13 iothub1 kernel: [ 3081.881165] xradio_wlan mmc1:0001:1: received frame has no key status
matheweis Posted February 19, 2017 Posted February 19, 2017 I've also done a bit of work with the OPi Zero in AP mode. Here's what I can share: Stability: WiFi channel #1 is borked on the OPi Zero. I'm not clear if this is a hardware, firmware, or driver issue - but I believe it is the reason for the widely inconsistent results that have been reported here on the forums. Using a higher channel it seems to be generally "reliable" (as much as one can reasonably expect from a device at this price point). Bandwidth: I get a stable 5.5Mbit/s or so from a meter or so away (measured with a MacBook Pro client and iperf3) It seems to have the same problem than with hostap.It works fine for a while but then the client connection starts to fail and the kernel starts to spam these messagesThere is nothing to do other than disconnect the client and try again as it seems to work again If you still have NetworkManager installed, either stop/remove it, or exclude the AP with [keyfile] unmanaged-devices=mac: (see man NetworkManager.conf). NetworkManager and hostapd don't play nice together, adding additional confusion to the question of reliability.
jkajolin Posted February 19, 2017 Author Posted February 19, 2017 Using wlan scanner from mobile phone I did notice that the channel 1 was not the best one.I have 3 wlan routers in differend rooms and hard wired lan cables between them so there might be some overlapping.i did the test on cheap market lenovo laptop it showed about 4mbit speed. From a normal wlan router the speed was something like 15mbit.With hostap I removed the network manager alltogether. I have the same configuration on pc plus and pc 2e which seem to work fine atleast with one esp8266 client posting iot data on 1 min intervals. Have't done any stresstests yet with multiple clients. I have around 20 units ready to be used some day hopefully soon
tkaiser Posted February 19, 2017 Posted February 19, 2017 WiFi channel #1 is borked on the OPi Zero. I'm not clear if this is a hardware, firmware, or driver issue - but I believe it is the reason for the widely inconsistent results that have been reported here on the forums. Hmm... the people who looked already in depth at the problem came to different conclusions: https://forum.armbian.com/index.php/topic/3243-orange-pi-zero-wireless-module-status-xradio-st-cw1200/ I also wonder why you think everyone would be using channel 1? Most people complaining try to use OPi Zero as client and I really doubt every AP on this planet is stupidly hardwired to use channel 1. Please also note that most people here use legacy kernel (as recommended) but the driver included there is just the original code drop we got from Allwinner without any changes made by community (the above discussion and all the work done happened with the mainline variant of the driver -- based on Allwinner's legacy driver though). I get a stable 5.5Mbit/s or so from a meter or so away (measured with a MacBook Pro client and iperf3) Strange, so you're not experiencing high count of TX retransmissions that ruin throughput in TX direction if you get stable 5.5Mbits/s in both directions? Or is this just in one direction? If so why and are you then talking about RX or TX? And since we're at it: are you talking about legacy or mainline kernel? Edit: Would be interesting to look at a screenshot from your MBP when you option click on the WiFi symbol in the menubar (you could also enable 'Wi-Fi monitoring' there which would be interesting regarding long term reliability)
tkaiser Posted February 19, 2017 Posted February 19, 2017 I have the same configuration on pc plus and pc 2e which seem to work fine atleast with one esp8266 client posting iot data on 1 min intervals. Have't done any stresstests yet with multiple clients. I have around 20 units ready to be used some day hopefully soon This would be really interesting. At least for me since this is one of the few use cases where OPi Zero IMO fits. Being a wireless gateway for a bunch of ESP8266 equipped Sonoff devices if distance to the main AP is too far.
reverend_t Posted February 19, 2017 Posted February 19, 2017 The other use I see for a vaguely working AP mode on the OPZ is to have a simple web server/control panel accessible wirelessly at close proximity. Useful as a status checking backdoor if ethernet fails.
tkaiser Posted February 19, 2017 Posted February 19, 2017 Useful as a status checking backdoor if ethernet fails. Just for the record: on Orange Pi Zero legacy images there's a serial console active on the Micro USB port (serial USB gadget) so if networking completely fails (for example due to messing up with network settings) you're always able to login through USB (same with OPi Lite and NanoPi Air). Though since most people will power the Zero through the Micro-USB port this is not that useful after setting up the board in the beginning.
matheweis Posted February 19, 2017 Posted February 19, 2017 Hmm... the people who looked already in depth at the problem came to different conclusions: https://forum.armbian.com/index.php/topic/3243-orange-pi-zero-wireless-module-status-xradio-st-cw1200/ I also wonder why you think everyone would be using channel 1? Most people complaining try to use OPi Zero as client and I really doubt every AP on this planet is stupidly hardwired to use channel 1. I was specifically referring to AP mode, in which context it seems reasonable that channel 1 might be the first one folks would pick for testing. I have done very little work with the OPi Zero in client mode, but about reliability in client mode; this quote reminded me of something... The other use I see for a vaguely working AP mode on the OPZ is to have a simple web server/control panel accessible wirelessly at close proximity. Useful as a status checking backdoor if ethernet fails. ... not to pick on NetworkManager too much, but I found by accident that it was also causing reliability issues with the wired ethernet interface. My OPi Zero was dropping Ethernet every 30 minutes or so until I removed NetworkManager (to do testing with hostapd as above) and the problem went away. Later I found that it was dropping the connection when trying to renew a DHCP release. Perhaps the same thing is happening on the wireless interface in client mode?
matheweis Posted February 19, 2017 Posted February 19, 2017 Strange, so you're not experiencing high count of TX retransmissions that ruin throughput in TX direction if you get stable 5.5Mbits/s in both directions? Or is this just in one direction? If so why and are you then talking about RX or TX? And since we're at it: are you talking about legacy or mainline kernel? Edit: Would be interesting to look at a screenshot from your MBP when you option click on the WiFi symbol in the menubar (you could also enable 'Wi-Fi monitoring' there which would be interesting regarding long term reliability) Good point about the direction of traffic. I get 5.5Mbit from MacBook to OPi Zero in AP mode. If the OPi Zero is sending then I get about 2.5Mbit on avg (it does fluctuate quite a bit between 1Mbit and 4.5Mbit) I am using the Ubuntu Legacy 3.4.113 build. Interesting bits from the MBP WiFi menu are: Channel: 3 (2.4Ghz, 20Mhz) RSSI: -40dBm [ fluctuates in the range -45 to -40 ] Noise: -83dBm [ fluctuates in the range -90 to -80 ] Tx Rate: 11Mbps PHY Mode: 802.11g Let me know if you would like to see anything else. Cheers!
tkaiser Posted February 19, 2017 Posted February 19, 2017 Well, instead of blaming network-manager and numerous 'perhaps' what about investigating the 'issues' instead? We've dozens of SBC running with network-manager active and not a single one shows these Ethernet symptoms so 'perhaps' it's something else you're experiencing? Regarding channel 1: Why would anyone choose this by default? The minimum approach is IMO to check the output of 'nmcli device wifi list' and then choose the best channel out of 1, 6 or 11 (1, 5, 9 and 13 in areas where 12/13 are allowed). Since you're using legacy kernel worst performance is expected (only the mainline driver variant received some love) and it's interesting that your MBP lists the connection as 802.11g (also low Tx rate and signal/noise ratio). Thanks for providing performance numbers in both directions (-R switch with iperf3) so TX retransmit problem confirmed (the packets are already retransmitted below TCP layer so I would assume you see no retransmits in iperf3's output?)
matheweis Posted February 19, 2017 Posted February 19, 2017 Well, instead of blaming network-manager and numerous 'perhaps' what about investigating the 'issues' instead? We've dozens of SBC running with network-manager active and not a single one shows these Ethernet symptoms so 'perhaps' it's something else you're experiencing? I did debug it as far as determining that NM was trying to re-add the default route during the renewal process when one already existed; when that would fail NM would assume that the entire lease renewal failed, but I didn't dig further than that. Regarding channel 1: Why would anyone choose this by default? The minimum approach is IMO to check the output of 'nmcli device wifi list' and then choose the best channel out of 1, 6 or 11 (1, 5, 9 and 13 in areas where 12/13 are allowed). Well in my case ch 1 was the least used. But the difference is between "works", and "totally unusable" was the use (or not) of channel 1... I didn't mean to discount the efforts that the other folks had done - obviously those folks know what they are doing and it seems like there is more than one problem with the board. I actually came here more to report that "it works for me too" than to poke at the problems Since you're using legacy kernel worst performance is expected (only the mainline driver variant received some love) and it's interesting that your MBP lists the connection as 802.11g (also low Tx rate and signal/noise ratio). Thanks for providing performance numbers in both directions (-R switch with iperf3) so TX retransmit problem confirmed (the packets are already retransmitted below TCP layer so I would assume you see no retransmits in iperf3's output?) Correct, no retransmits seen in the iperf output. Even at the TCP layer (as seen from netstat -s) the retransmits were in the 1% range.
matheweis Posted February 19, 2017 Posted February 19, 2017 For what it's worth, I [just] ran the same tests in as similar an environment as possible using the mainline nightly release and couldn't get more than 3Mbit in either direction.
tkaiser Posted February 20, 2017 Posted February 20, 2017 For what it's worth, I [just] ran the same tests in as similar an environment as possible using the mainline nightly release and couldn't get more than 3Mbit in either direction. Well, I don't know your timezone and by how many APs you are surrounded. But part of my 'environment' here are way too much 2.4GHz Wi-Fis (NetSpot counted 139 networks when running for 48 hours and only 14 of them were 5GHz) and so I'm only able to do any reasonable testing in the night. Throughout the day 2.4Ghz Wi-Fi is somewhat useable, in the evening it gets totally unusable and only when everyone else around is already sleeping doing 'tests' makes some sense. This also reflects the numbers iperf3 spits out here (~20 Mbits/sec being the maximum with various onboard Wi-Fi solutions, though I were never able to measure with the Zero myself since Wi-Fi broken physically there for some reason)
matheweis Posted February 21, 2017 Posted February 21, 2017 Well, I don't know your timezone and by how many APs you are surrounded... GMT -7 in a relatively rural area. There may be a dozen or so networks that are occasionally seen, but I would not consider it a noisy environment by any means. Let me know if there's anything I can do to help. Cheers!
Recommended Posts