Jump to content

Orange Pi Zero Wifi connection Issues


Akula

Recommended Posts

Hi guys,

 

I noticed when i switch over to wifi only and turn of the ethernet connection i get issues...

 ping 192.168.1.12
PING 192.168.1.12 (192.168.1.12): 56 data bytes
64 bytes from 192.168.1.12: icmp_seq=2 ttl=64 time=522.139 ms
64 bytes from 192.168.1.12: icmp_seq=3 ttl=64 time=237.595 ms
64 bytes from 192.168.1.12: icmp_seq=4 ttl=64 time=971.235 ms
64 bytes from 192.168.1.12: icmp_seq=5 ttl=64 time=280.141 ms
64 bytes from 192.168.1.12: icmp_seq=6 ttl=64 time=243.838 ms
64 bytes from 192.168.1.12: icmp_seq=7 ttl=64 time=420.975 ms
64 bytes from 192.168.1.12: icmp_seq=8 ttl=64 time=25.459 ms
64 bytes from 192.168.1.12: icmp_seq=9 ttl=64 time=352.204 ms
64 bytes from 192.168.1.12: icmp_seq=10 ttl=64 time=478.331 ms
64 bytes from 192.168.1.12: icmp_seq=11 ttl=64 time=88.426 ms
64 bytes from 192.168.1.12: icmp_seq=12 ttl=64 time=317.575 ms
64 bytes from 192.168.1.12: icmp_seq=13 ttl=64 time=639.275 ms
64 bytes from 192.168.1.12: icmp_seq=14 ttl=64 time=66.482 ms
......
Request timeout for icmp_seq 61
Request timeout for icmp_seq 62
Request timeout for icmp_seq 63
Request timeout for icmp_seq 64
Request timeout for icmp_seq 65
Request timeout for icmp_seq 66
Request timeout for icmp_seq 67
Request timeout for icmp_seq 68
ping: sendto: No route to host
Request timeout for icmp_seq 69
ping: sendto: Host is down
Request timeout for icmp_seq 70
ping: sendto: Host is down
Request timeout for icmp_seq 71
ping: sendto: Host is down
Request timeout for icmp_seq 72
ping: sendto: Host is down
Request timeout for icmp_seq 73
ping: sendto: Host is down
Request timeout for icmp_seq 74
ping: sendto: Host is down
.....
64 bytes from 192.168.1.12: icmp_seq=120 ttl=64 time=105.389 ms
64 bytes from 192.168.1.12: icmp_seq=121 ttl=64 time=318.659 ms
64 bytes from 192.168.1.12: icmp_seq=122 ttl=64 time=542.973 ms
64 bytes from 192.168.1.12: icmp_seq=123 ttl=64 time=150.190 ms
64 bytes from 192.168.1.12: icmp_seq=124 ttl=64 time=576.509 ms
64 bytes from 192.168.1.12: icmp_seq=125 ttl=64 time=159.787 ms
64 bytes from 192.168.1.12: icmp_seq=126 ttl=64 time=213.605 ms
64 bytes from 192.168.1.12: icmp_seq=127 ttl=64 time=641.519 ms
64 bytes from 192.168.1.12: icmp_seq=128 ttl=64 time=54.892 ms
64 bytes from 192.168.1.12: icmp_seq=129 ttl=64 time=291.052 ms
64 bytes from 192.168.1.12: icmp_seq=130 ttl=64 time=513.572 ms
 
Guys if i switch eth0 back on while the cable is pluged in, it goes away, but i wanna run it on wifi only.
 
Any ideas?
 
Thank you in advance.

 

Link to comment
Share on other sites

Hi Akula,

 

have something very similar with the NanoPiNeoAir... Maybe the tips there work for you...

https://forum.armbian.com/index.php/topic/3269-nano-pi-neo-air-unstable-wi-fi/

 

so long,

Patrik

Thanks Patrik,

 

I don't think the issue is the same, actually my ping respond times over wifi are good as long as the ethernet is hooked up.

 

But as soon as i unhook the ethernet i get i weird response stuff, i connect it up with "nmtui" command, the issue happened with both debian and ubuntu builds, it straight up doesn't work with the beta.

 

I might put it into another orange pi zero to help figure out, also i'll install airmon-ng and do some wireless scanning to see package drops and QoS.

 

thanks anyway

Link to comment
Share on other sites

hi tnx for working wifi on 4.3.9 kernel

but sometime it drop kernel ((((((

root@OpenWrt:/# [ 1244.983831] ------------[ cut here ]------------
[ 1244.988569] WARNING: CPU: 0 PID: 626 at drivers/net/wireless/xradio/txrx.c:1526 xradio_tx_confirm_cb+0x460/0x54c [xradio_wlan]
[ 1245.000018] Modules linked in: xradio_wlan mac80211 cfg80211 rfkill ccm g_ether usb_f_rndis usb_f_ncm usb_f_ecm usb_f_eem u_ether libcomposite sunxi_cir sun8i_ths cpufreq_dt thermal_sys
[ 1245.016776] CPU: 0 PID: 626 Comm: xradio_bh Not tainted 4.9.3-sun8i #24
[ 1245.023392] Hardware name: Allwinner sun8i Family
[ 1245.028126] [<c010bc29>] (unwind_backtrace) from [<c0108ea7>] (show_stack+0xb/0xc)
[ 1245.035716] [<c0108ea7>] (show_stack) from [<c04283b7>] (dump_stack+0x67/0x74)
[ 1245.042960] [<c04283b7>] (dump_stack) from [<c0119c45>] (__warn+0xa9/0xbc)
[ 1245.049844] [<c0119c45>] (__warn) from [<c0119cc3>] (warn_slowpath_null+0x13/0x18)
[ 1245.057464] [<c0119cc3>] (warn_slowpath_null) from [<bf904d89>] (xradio_tx_confirm_cb+0x460/0x54c [xradio_wlan])
[ 1245.067727] [<bf904d89>] (xradio_tx_confirm_cb [xradio_wlan]) from [<bf9093fb>] (wsm_tx_confirm+0xde/0xfc [xradio_wlan])
[ 1245.078671] [<bf9093fb>] (wsm_tx_confirm [xradio_wlan]) from [<bf90bda9>] (wsm_handle_rx+0x648/0xc38 [xradio_wlan])
[ 1245.089181] [<bf90bda9>] (wsm_handle_rx [xradio_wlan]) from [<bf90895d>] (xradio_bh_exchange+0x264/0x570 [xradio_wlan])
[ 1245.100036] [<bf90895d>] (xradio_bh_exchange [xradio_wlan]) from [<bf908de1>] (xradio_bh+0x178/0x2f8 [xradio_wlan])
[ 1245.110519] [<bf908de1>] (xradio_bh [xradio_wlan]) from [<c012de79>] (kthread+0x99/0xac)
[ 1245.118628] [<c012de79>] (kthread) from [<c0105f31>] (ret_from_fork+0x11/0x20)
[ 1245.125881] ---[ end trace 3bda58e40008b467 ]---
[ 1247.019292] sched: RT throttling activated

Link to comment
Share on other sites

root@OpenWrt:/# [ 1244.983831] ------------[ cut here ]------------
[ 1244.988569] WARNING: CPU: 0 PID: 626 at drivers/net/wireless/xradio/txrx.c:1526 xradio_tx_confirm_cb+0x460/0x54c [xradio_wlan]
[ 1247.019292] sched: RT throttling activated

First, this is just a warning, it shouldn't crash the kernel

Second, please try to reproduce these issues on stock Armbian images and provide more info (is this AP or client mode, if it's AP then how many client are connected, can it be reproduced reliably with a sequence of actions (i.e. using iperf3 if it is caused during a high load)

Third, as you can see in the description here, driver and firmware are not stable yet and we have no idea whether somebody will try to improve the situation.

Link to comment
Share on other sites

Anyway, 

 

This can be marked as solved...

 

I have two compounded issues,

 

one was:

Rule of thumb: in case you connect both WiFi and Ethernet to the same network expect problems when unplugging Ethernet. There's a huge thread regarding exactly this with explanations and solutions from some weeks ago.

 

Edit: https://forum.armbian.com/index.php/topic/2907-opi-zero-incoming-ssh-cant-connect/page-2#entry20285

two was: 

Board: Orange Pi Zero

  • Onboard wireless chip (XR819) has poor software support so wireless connection issues are expected

Anybody reading this, as above issue with the driver, however i have found that orange pi's debian images for this seems to work better, but it could easily be placibo!

Link to comment
Share on other sites

Same WIFI issue here with OrangePI Zero and Jessie 5.24. long responce, delays in ssh session...

 

 
64 bytes from 192.168.1.111: icmp_seq=65 ttl=128 time=71.5 ms
64 bytes from 192.168.1.111: icmp_seq=66 ttl=128 time=113 ms
64 bytes from 192.168.1.111: icmp_seq=67 ttl=128 time=53.6 ms
64 bytes from 192.168.1.111: icmp_seq=68 ttl=128 time=104 ms
64 bytes from 192.168.1.111: icmp_seq=69 ttl=128 time=103 ms
64 bytes from 192.168.1.111: icmp_seq=70 ttl=128 time=73.2 ms
64 bytes from 192.168.1.111: icmp_seq=71 ttl=128 time=39.5 ms
64 bytes from 192.168.1.111: icmp_seq=72 ttl=128 time=9.71 ms
64 bytes from 192.168.1.111: icmp_seq=73 ttl=128 time=20.5 ms
 
200 Kb/s copy speed through Samba (Signal level=-69 dBm)
 
help.
Link to comment
Share on other sites

ARMBIAN 5.24 stable Ubuntu 16.04.1 LTS 4.9.4-sun8i

 

laptop -> Wifi AP (zero) -> LAN -> internet

# ping -c 10 IotHub1
PING IotHub1 (192.168.88.216) 56(84) bytes of data.
64 bytes from IotHub1 (192.168.88.216): icmp_seq=1 ttl=64 time=3.11 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=2 ttl=64 time=1.77 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=3 ttl=64 time=1.10 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=4 ttl=64 time=1.53 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=5 ttl=64 time=1.14 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=6 ttl=64 time=1.27 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=7 ttl=64 time=1.10 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=8 ttl=64 time=1.30 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=9 ttl=64 time=1.58 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=10 ttl=64 time=1.10 ms

--- IotHub1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 1.102/1.504/3.117/0.583 ms

 

Same WIFI issue here with OrangePI Zero and Jessie 5.24. long responce, delays in ssh session...

 

 
64 bytes from 192.168.1.111: icmp_seq=65 ttl=128 time=71.5 ms
64 bytes from 192.168.1.111: icmp_seq=66 ttl=128 time=113 ms
64 bytes from 192.168.1.111: icmp_seq=67 ttl=128 time=53.6 ms
64 bytes from 192.168.1.111: icmp_seq=68 ttl=128 time=104 ms
64 bytes from 192.168.1.111: icmp_seq=69 ttl=128 time=103 ms
64 bytes from 192.168.1.111: icmp_seq=70 ttl=128 time=73.2 ms
64 bytes from 192.168.1.111: icmp_seq=71 ttl=128 time=39.5 ms
64 bytes from 192.168.1.111: icmp_seq=72 ttl=128 time=9.71 ms
64 bytes from 192.168.1.111: icmp_seq=73 ttl=128 time=20.5 ms
 
200 Kb/s copy speed through Samba (Signal level=-69 dBm)
 
help.

 

Link to comment
Share on other sites

sorry was using wrong interface ip (zero's eth0) this is directly to the hostap gateway address

# ping -c 10 192.168.51.1
PING 192.168.51.1 (192.168.51.1) 56(84) bytes of data.
64 bytes from 192.168.51.1: icmp_seq=1 ttl=64 time=1.20 ms
64 bytes from 192.168.51.1: icmp_seq=2 ttl=64 time=1.84 ms
64 bytes from 192.168.51.1: icmp_seq=3 ttl=64 time=1.18 ms
64 bytes from 192.168.51.1: icmp_seq=4 ttl=64 time=4.35 ms
64 bytes from 192.168.51.1: icmp_seq=5 ttl=64 time=1.06 ms
64 bytes from 192.168.51.1: icmp_seq=6 ttl=64 time=1.47 ms
64 bytes from 192.168.51.1: icmp_seq=7 ttl=64 time=1.16 ms
64 bytes from 192.168.51.1: icmp_seq=8 ttl=64 time=1.62 ms
64 bytes from 192.168.51.1: icmp_seq=9 ttl=64 time=1.14 ms
64 bytes from 192.168.51.1: icmp_seq=10 ttl=64 time=1.87 ms

--- 192.168.51.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 1.069/1.695/4.357/0.931 ms

---

 

ARMBIAN 5.24 stable Ubuntu 16.04.1 LTS 4.9.4-sun8i

 

laptop -> Wifi AP (zero) -> LAN -> internet

# ping -c 10 IotHub1
PING IotHub1 (192.168.88.216) 56(84) bytes of data.
64 bytes from IotHub1 (192.168.88.216): icmp_seq=1 ttl=64 time=3.11 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=2 ttl=64 time=1.77 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=3 ttl=64 time=1.10 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=4 ttl=64 time=1.53 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=5 ttl=64 time=1.14 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=6 ttl=64 time=1.27 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=7 ttl=64 time=1.10 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=8 ttl=64 time=1.30 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=9 ttl=64 time=1.58 ms
64 bytes from IotHub1 (192.168.88.216): icmp_seq=10 ttl=64 time=1.10 ms

--- IotHub1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 1.102/1.504/3.117/0.583 ms

---

root@IotHub1:/home/tiger# ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:13:81:f5:29  
          inet addr:192.168.88.216  Bcast:192.168.88.255  Mask:255.255.255.0
          inet6 addr: fe80::42:13ff:fe81:f529/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1627 errors:0 dropped:0 overruns:0 frame:0
          TX packets:967 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:278121 (278.1 KB)  TX bytes:146387 (146.3 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:78 (78.0   TX bytes:78 (78.0 

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.7.102.6  P-t-P:10.7.102.6  Mask:255.255.255.0
          inet6 addr: fe80::c47:c5a4:43c3:9a66/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0   TX bytes:432 (432.0 

wlan0     Link encap:Ethernet  HWaddr 12:42:13:81:f5:29  
          inet addr:192.168.51.1  Bcast:192.168.51.255  Mask:255.255.255.0
          inet6 addr: fe80::1042:13ff:fe81:f529/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:933 errors:0 dropped:0 overruns:0 frame:0
          TX packets:891 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:142645 (142.6 KB)  TX bytes:255517 (255.5 KB)

root@IotHub1:/home/tiger# 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


Link to comment
Share on other sites

I have been having wifi connection issues with the OPi Zero as well.

But only with the mainline kernel.
With the legacy kernel, I can connect to my various access points and transfer data, SSH etc.
I wanted to try out the mainline kernel, so about a month ago I downloaded one of the nightly builds
I was not surprised that the WiFi didn't work at all.
I waited several days while reading the forums and once folks were reporting a working
mainline, I tried again. THis time I could see access points but could not associate.
After a while I started investigating what could be wrong with my setup.
At this point I had a working jessie 3.4.113 and a non working Xenial 4.9.0
(not working wifi that is). Both stock installs of Armbian 5.24.

I tried several power sources, several usb cables, old slow SD cards, and new fast SD cards.
All results were consistent, jessie 3.4.113 worked, Xenial 4,9.0 then 4.9.1,4.9.2,4.9.3 didn't.

I then thought that maybe I had a bad OPi Zero, so I ordered and waited 3 weeks to get a second.
It arrived the other day and all results with the new board were the same.

Today I saw that there was an actual release of Xenial 4.9.4 for the OPi Zero. Downloaded it and
got the same results.

Ethernet works on both jessie and xenial.
I have tried with the ethernet cable connected and disconnected.
I have tried with power management on and off.
I can do a iwlist scan and see access points on both systems. It almost seems like there is no
data being sent from the OPi with Xenial. I probed the 1.8V and 3.3V power for the Wifi chip and both are
at nominal levels.

Both my boards are 512M and came with the SPI flash soldered on.
This is a stock installation of the Armbian Xenial 4.9.4 I downloaded on 1/26/2017. No other packages
have been loaded, upgraded or configurations changed.

Messages which might be of interest:
iwconfig wlan0 essid MyAP

[ 1408.950945] xradio_wlan mmc1:0001:1: missed interrupt
[ 1449.630902] wlan0: authenticate with 18:a6:f7:02:4d:fa
[ 1449.630999] ieee80211 phy0: ignore IEEE80211_CONF_CHANGE_MONITOR (0)IEEE80211_CONF_CHANGE_IDLE (1)
[ 1449.631309] wlan0: send auth to 18:a6:f7:02:4d:fa (try 1/3)
[ 1449.631713] wlan0: send auth to 18:a6:f7:02:4d:fa (try 2/3)
[ 1449.631858] wlan0: send auth to 18:a6:f7:02:4d:fa (try 3/3)
[ 1449.631964] wlan0: authentication with 18:a6:f7:02:4d:fa timed out

after ifconfig eth0 dowm then iwconfig wlan0 essid MyOtherAP
[ 2237.719983] wlan0: authenticate with f4:f2:6d:a3:0e:5c
[ 2237.720124] ieee80211 phy0: ignore IEEE80211_CONF_CHANGE_MONITOR (0)IEEE80211_CONF_CHANGE_IDLE (1)
[ 2237.720154] ieee80211 phy0: Freq 2412 (wsm ch: 1).
[ 2237.721079] wlan0: send auth to f4:f2:6d:a3:0e:5c (try 1/3)
[ 2237.721619] wlan0: send auth to f4:f2:6d:a3:0e:5c (try 2/3)
[ 2237.721951] wlan0: send auth to f4:f2:6d:a3:0e:5c (try 3/3)
[ 2237.722278] wlan0: authentication with f4:f2:6d:a3:0e:5c timed out
[ 2237.761757] ieee80211 phy0: ignore IEEE80211_CONF_CHANGE_MONITOR (0)IEEE80211_CONF_CHANGE_IDLE (1)


modinfo xradio_wlan
filename:       /lib/modules/4.9.4-sun8i/kernel/drivers/net/wireless/xradio/xradio_wlan.ko
alias:          xradio_core
license:        GPL
description:    XRadioTech WLAN driver core
author:         XRadioTech
alias:          sdio:c*v0020d2281*
depends:        mac80211,cfg80211
intree:         Y
vermagic:       4.9.4-sun8i SMP mod_unload ARMv7 thumb2 p2v8


iw wlan0 info
Interface wlan0
        ifindex 3
        wdev 0x1
        addr 12:42:87:47:5c:af
        type managed
        wiphy 0


lsmod
Module                  Size  Used by
evdev                  10043  0
xradio_wlan            92375  1
mac80211              322651  1 xradio_wlan
cfg80211              191902  2 mac80211,xradio_wlan
rfkill                 10928  3 cfg80211
sun8i_ths               3134  0
gpio_keys               8453  0
cpufreq_dt              3586  0
uio_pdrv_genirq         3354  0
thermal_sys            42239  2 cpufreq_dt,sun8i_ths
uio                     8012  1 uio_pdrv_genirq


ip link show wlan0
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether 12:42:87:47:5c:af brd ff:ff:ff:ff:ff:ff

uname -a
Linux orangepizero 4.9.4-sun8i #3 SMP Fri Jan 20 22:11:20 CET 2017 armv7l armv7l armv7l GNU/Linux

nmcli device show
GENERAL.DEVICE:                         eth0
GENERAL.TYPE:                           ethernet
GENERAL.HWADDR:                         02:42:87:47:5C:AF
GENERAL.MTU:                            1500
GENERAL.STATE:                          30 (disconnected)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
WIRED-PROPERTIES.CARRIER:               on

GENERAL.DEVICE:                         wlan0
GENERAL.TYPE:                           wifi
GENERAL.HWADDR:                         12:42:87:47:5C:AF
GENERAL.MTU:                            0
GENERAL.STATE:                          30 (disconnected)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --

GENERAL.DEVICE:                         lo
GENERAL.TYPE:                           loopback
GENERAL.HWADDR:                         00:00:00:00:00:00
GENERAL.MTU:                            65536
GENERAL.STATE:                          10 (unmanaged)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
IP4.ADDRESS[1]:                         127.0.0.1/8
IP4.GATEWAY:                            
IP6.ADDRESS[1]:                         ::1/128
IP6.GATEWAY:


systemctl status network-manager
��◠NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor p
   Active: active (running) since Sat 2017-01-21 01:39:25 UTC; 31min ago
 Main PID: 543 (NetworkManager)
   CGroup: /system.slice/NetworkManager.service
           ��└��─543 /usr/sbin/NetworkManager --no-daemon

Jan 21 02:06:27 orangepizero NetworkManager[543]: <info>  [1484964387.6761] devi
Jan 21 02:06:27 orangepizero NetworkManager[543]: <info>  [1484964387.6777] poli
Jan 21 02:06:27 orangepizero NetworkManager[543]: <warn>  [1484964387.6790] devi
Jan 21 02:06:27 orangepizero NetworkManager[543]: <info>  [1484964387.6810] devi
Jan 21 02:06:27 orangepizero NetworkManager[543]: <info>  [1484964387.6821] mana
Jan 21 02:06:27 orangepizero NetworkManager[543]: <info>  [1484964387.6829] poli
Jan 21 02:06:27 orangepizero NetworkManager[543]: <warn>  [1484964387.6840] devi
Jan 21 02:06:27 orangepizero NetworkManager[543]: <info>  [1484964387.6871] devi
Jan 21 02:06:27 orangepizero NetworkManager[543]: <info>  [1484964387.6945] devi
Jan 21 02:06:32 orangepizero NetworkManager[543]: <info>  [1484964392.9635] devi

My question is this, where should I go from here to debug this issue, has anyone seen the same or
similar problems. I have been able to rebuild the kernel from sources using the Armbian tools,
but that was a few days ago with 4.9.3 and now that 4.9.4 is in use, I haven't had time to try
building it again. My thoughts were to turn on wifi debugging and see what messages came out.

For my project I could use the legacy kernel, but I'd rather not.

BTW. I AM in a rural area where the only AP's I see are my own, and there is little other traffic on 2.4G (this may
not last forever, but today I can use 2.4G.)

Link to comment
Share on other sites

Your Network manager may be incompatible with AP's setup. I have similar issue with latest Network manager on my desktop (Archlinux) (send auth to, authentication timed out) but at the same time Android phone connects without problems.

 

Play with encryption settings on the AP side or test it on different routers.

Link to comment
Share on other sites

Most of my AP's have no security/encription. And since my jessie legacy kernel can connect to any of them I don't think it is a hardware issue with the OPi.

I'll fiddle with different AP settings and see what happens.

Link to comment
Share on other sites

Problems have been reported with the network manager in Debian Sid on some networks, independent of hardware.  Apparently it does random MAC assignment.  I've always found "apt-get remove --purge" to fix network mangler problems.

Link to comment
Share on other sites

Well the security was the key, I had just assumed that if the network manager of jessie could handle an AP with no security that the one from Xenial could as well. My bad.

When I turned on WPA and gave the AP a password, then tried to activate with nmtui, it immediately asked for a password, then associated and connected to the AP. Which can now ping out to the internet. After about 10 pings of 15ms to google.com I get 2-3 pings of 2000-4500ms then it's back to 15-20ms, then sporadically I'll get another looong ping time.

BUT That's another issue.

 

Thanks for the assistance.

Link to comment
Share on other sites

Irregular ping times and low transfer rates, sometimes is caused by the scaling gobernor.

Setting the scaling gobernor to "performance" makes de cpu more active, an increases wifi performance. ( by defauls is set to "ondemand" )

 

In my case solved the problem. Orange pi may consume more power, but normally this is not an issue.

 

echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

 

 

Edited by copazo
better spec
Link to comment
Share on other sites

Thanks for the tip.

I noticed the same kind of problem for the audio with NanoPi NEO/NEO2. The cpu frequency scaling causes noise.

I have to use the same MIN_SPEED et MAX_SPEED in /etc/default/cpufrequtils. And it works with any governor.

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines