Akula Posted January 13, 2017 Posted January 13, 2017 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.
pmayer Posted January 13, 2017 Posted January 13, 2017 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
Akula Posted January 13, 2017 Author Posted January 13, 2017 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
tkaiser Posted January 13, 2017 Posted January 13, 2017 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
bzfrp Posted January 13, 2017 Posted January 13, 2017 I have an opi zero (not using armbian image) and the same problem.Edit. The wifi works (but unstable) if compile sun8i-emac as module and unload it to disable Ethernet.
hyphop Posted January 16, 2017 Posted January 16, 2017 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
zador.blood.stained Posted January 16, 2017 Posted January 16, 2017 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.
Akula Posted January 18, 2017 Author Posted January 18, 2017 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!
borombo Posted January 25, 2017 Posted January 25, 2017 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.
jkajolin Posted January 25, 2017 Posted January 25, 2017 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.
jkajolin Posted January 25, 2017 Posted January 25, 2017 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
borombo Posted January 26, 2017 Posted January 26, 2017 With 4.9.4 Linux it is much better. Thank you!
cynfab Posted January 26, 2017 Posted January 26, 2017 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 buildsI 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 workingmainline, 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 andgot 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 nodata being sent from the OPi with Xenial. I probed the 1.8V and 3.3V power for the Wifi chip and both areat 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 packageshave 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 outafter 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_wlanfilename: /lib/modules/4.9.4-sun8i/kernel/drivers/net/wireless/xradio/xradio_wlan.koalias: xradio_corelicense: GPLdescription: XRadioTech WLAN driver coreauthor: XRadioTechalias: sdio:c*v0020d2281*depends: mac80211,cfg80211intree: Yvermagic: 4.9.4-sun8i SMP mod_unload ARMv7 thumb2 p2v8iw wlan0 infoInterface wlan0 ifindex 3 wdev 0x1 addr 12:42:87:47:5c:af type managed wiphy 0lsmodModule Size Used byevdev 10043 0xradio_wlan 92375 1mac80211 322651 1 xradio_wlancfg80211 191902 2 mac80211,xradio_wlanrfkill 10928 3 cfg80211sun8i_ths 3134 0gpio_keys 8453 0cpufreq_dt 3586 0uio_pdrv_genirq 3354 0thermal_sys 42239 2 cpufreq_dt,sun8i_thsuio 8012 1 uio_pdrv_genirqip link show wlan03: 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:ffuname -aLinux orangepizero 4.9.4-sun8i #3 SMP Fri Jan 20 22:11:20 CET 2017 armv7l armv7l armv7l GNU/Linuxnmcli device showGENERAL.DEVICE: eth0GENERAL.TYPE: ethernetGENERAL.HWADDR: 02:42:87:47:5C:AFGENERAL.MTU: 1500GENERAL.STATE: 30 (disconnected)GENERAL.CONNECTION: --GENERAL.CON-PATH: --WIRED-PROPERTIES.CARRIER: onGENERAL.DEVICE: wlan0GENERAL.TYPE: wifiGENERAL.HWADDR: 12:42:87:47:5C:AFGENERAL.MTU: 0GENERAL.STATE: 30 (disconnected)GENERAL.CONNECTION: --GENERAL.CON-PATH: --GENERAL.DEVICE: loGENERAL.TYPE: loopbackGENERAL.HWADDR: 00:00:00:00:00:00GENERAL.MTU: 65536GENERAL.STATE: 10 (unmanaged)GENERAL.CONNECTION: --GENERAL.CON-PATH: --IP4.ADDRESS[1]: 127.0.0.1/8IP4.GATEWAY: IP6.ADDRESS[1]: ::1/128IP6.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-daemonJan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6761] deviJan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6777] poliJan 21 02:06:27 orangepizero NetworkManager[543]: <warn> [1484964387.6790] deviJan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6810] deviJan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6821] manaJan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6829] poliJan 21 02:06:27 orangepizero NetworkManager[543]: <warn> [1484964387.6840] deviJan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6871] deviJan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6945] deviJan 21 02:06:32 orangepizero NetworkManager[543]: <info> [1484964392.9635] deviMy question is this, where should I go from here to debug this issue, has anyone seen the same orsimilar 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 trybuilding 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 maynot last forever, but today I can use 2.4G.)
borombo Posted January 27, 2017 Posted January 27, 2017 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.
cynfab Posted January 27, 2017 Posted January 27, 2017 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.
Blars Posted January 27, 2017 Posted January 27, 2017 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.
cynfab Posted January 27, 2017 Posted January 27, 2017 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.
copazo Posted April 9, 2018 Posted April 9, 2018 (edited) 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 April 9, 2018 by copazo better spec
bzfrp Posted April 9, 2018 Posted April 9, 2018 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.
Recommended Posts