Orange Pi Zero Mainline NetworkManager WLAN AP


jkajolin
 Share

0

Recommended Posts

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

Link to post
Share on other sites

Donate and support the project!

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 messages
There 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

Link to post
Share on other sites

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 messages
There 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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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)

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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?

Link to post
Share on other sites

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!

Link to post
Share on other sites

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?)

Link to post
Share on other sites

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.  :unsure:

 

 

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.

Link to post
Share on other sites

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)

Link to post
Share on other sites

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!

Link to post
Share on other sites

Guest
This topic is now closed to further replies.
 Share

0