Jump to content
  • 0

Nano Pi Neo Air unstable Wi-Fi

pmayer

Asked by pmayer,

 Share

Question

pmayer

pmayer

Posted
Posted

Hi guys,

 

first I want to thank you for your marvelous work. I've learned much...

 

I've ordered a Nano Pi Neo Air and two Nano Pi Neo from Friendly Arm which arrived last week to build some squeezelite clients and drop them around the house. At the moment I'm just using some cheap USB-C-Media Soundcards but plan to invest in better ones, if the multi-room solution I have in mind is used enough.

 

The Nano Pi Neo (not Air) does exactly what it should using the Ubnuntu Xenial Image from the download page. Cheers!

 

For the Air's I've used the Debian release, don't know really why ;-)

 

At first I've bootet it from a SD-Card after a direct eMMC-Flash using https://github.com/ThomasKaiser/sunxi-armbian-flasher-osxfailed. Etcher always mouns about not finding diskutil (tried 1.0.0beta15 and 1.0.0beta17 - OSx 10.12.2) on the first run. After restarting Etcher it shows the "drive" and I can flash, but after that mmc1 could not be found as stated on the serial console - that seems like another problem and I did not copy the message, sorry.

 

I've installed Debian from the SD-Card to the eMMC with /usr/lib/nand-sata-install/nand-sata-install.sh  which worked fine. Cheers again!

 

After that I've configured Wifi by editing /etc/network/interfaces and adding an auto wlan0. After restarting networking - online!

Everything seems to work fine, installing Squeezelite, configuring it and listening to music from the Logitech-Media-Server in sync with the other Nano Pi's. WOW!

 

I'm using a dedicated power supply (5V, 2A) and attached the usb-sound-dongle via an OTG-Y-Cable together with the 5V.

http://imgur.com/a/Ta3iB

 

But something seems quirky. I can't get a stable ssh connection via Wi-Fi - Serial works fine meanwhile. After some time listening to music from the device, it drops from the player list in the media server and won't come back again while it is still pingable. The load of the board is somewhere around 0.02-0.16 the whole time.

 

This is a ping to the device:

PING nanopiair.fritz.box (192.168.42.165): 56 data bytes
64 bytes from 192.168.42.165: icmp_seq=0 ttl=64 time=149.826 ms
64 bytes from 192.168.42.165: icmp_seq=1 ttl=64 time=64.753 ms
64 bytes from 192.168.42.165: icmp_seq=2 ttl=64 time=85.062 ms
64 bytes from 192.168.42.165: icmp_seq=3 ttl=64 time=104.953 ms
64 bytes from 192.168.42.165: icmp_seq=4 ttl=64 time=27.079 ms
64 bytes from 192.168.42.165: icmp_seq=5 ttl=64 time=4.260 ms
64 bytes from 192.168.42.165: icmp_seq=6 ttl=64 time=4.676 ms
64 bytes from 192.168.42.165: icmp_seq=7 ttl=64 time=3.576 ms
64 bytes from 192.168.42.165: icmp_seq=8 ttl=64 time=5.415 ms
64 bytes from 192.168.42.165: icmp_seq=9 ttl=64 time=4.240 ms
64 bytes from 192.168.42.165: icmp_seq=10 ttl=64 time=4.242 ms
[...]
64 bytes from 192.168.42.165: icmp_seq=1990 ttl=64 time=4.391 ms
64 bytes from 192.168.42.165: icmp_seq=1991 ttl=64 time=4.363 ms
64 bytes from 192.168.42.165: icmp_seq=1992 ttl=64 time=4.313 ms
64 bytes from 192.168.42.165: icmp_seq=1993 ttl=64 time=31.534 ms
64 bytes from 192.168.42.165: icmp_seq=1994 ttl=64 time=52.714 ms
64 bytes from 192.168.42.165: icmp_seq=1995 ttl=64 time=72.956 ms
64 bytes from 192.168.42.165: icmp_seq=1996 ttl=64 time=94.694 ms
64 bytes from 192.168.42.165: icmp_seq=1997 ttl=64 time=13.832 ms
64 bytes from 192.168.42.165: icmp_seq=1998 ttl=64 time=37.470 ms
64 bytes from 192.168.42.165: icmp_seq=1999 ttl=64 time=60.732 ms
64 bytes from 192.168.42.165: icmp_seq=2000 ttl=64 time=80.521 ms
64 bytes from 192.168.42.165: icmp_seq=2001 ttl=64 time=100.608 ms
64 bytes from 192.168.42.165: icmp_seq=2002 ttl=64 time=18.236 ms
64 bytes from 192.168.42.165: icmp_seq=2003 ttl=64 time=38.494 ms
64 bytes from 192.168.42.165: icmp_seq=2004 ttl=64 time=57.605 ms
64 bytes from 192.168.42.165: icmp_seq=2005 ttl=64 time=77.558 ms
64 bytes from 192.168.42.165: icmp_seq=2006 ttl=64 time=97.405 ms
64 bytes from 192.168.42.165: icmp_seq=2007 ttl=64 time=14.296 ms
64 bytes from 192.168.42.165: icmp_seq=2008 ttl=64 time=37.039 ms
64 bytes from 192.168.42.165: icmp_seq=2009 ttl=64 time=61.979 ms
64 bytes from 192.168.42.165: icmp_seq=2010 ttl=64 time=79.827 ms
64 bytes from 192.168.42.165: icmp_seq=2011 ttl=64 time=104.190 ms
64 bytes from 192.168.42.165: icmp_seq=2012 ttl=64 time=5.220 ms
64 bytes from 192.168.42.165: icmp_seq=2013 ttl=64 time=8.095 ms
64 bytes from 192.168.42.165: icmp_seq=2014 ttl=64 time=6.569 ms
64 bytes from 192.168.42.165: icmp_seq=2015 ttl=64 time=5.788 ms
64 bytes from 192.168.42.165: icmp_seq=2016 ttl=64 time=6.476 ms

So, no packet drops - only very varying packet round trip times.

 

Here's my iwconfig (WPA2):

wlan0     IEEE 802.11  ESSID:"myssid"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: XX:XX:XX:XX:XX:XX   
          Bit Rate=72 Mb/s   Tx-Power:32 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Managementmode:All packets received
          Link Quality=5/5  Signal level=-34 dBm  Noise level=-91 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:77  Invalid misc:0   Missed beacon:0

Maybe the excessive retries are a hint?

 

On the shell I have to wait for 10 or more seconds to type in another command or character. Serial, as already said, responds quick as usual.

 

Maybe I've choosed the wrong antenna? But then the iwconfig should tell other values. I bought these: https://www.amazon.de/gp/product/B01FZ47URG/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1

 

Hopefully you can point me out what I could do to have reliable Wi-Fi on the otherweise fine Nano Pi Neo Air board. Though I'm not using them to do heavy lifting.

 

Regards,

Patrik

 

 

 

Link to comment
Share on other sites

11 answers to this question

Recommended Posts

  • 0
tkaiser

tkaiser

Posted
Posted

You can try to disable WiFi power management. Apart from that if you're not living in the woods, on a mountain or somewhere else in a rural area you shouldn't expect anything from this cheap 2.4 GHz WiFi stuff. It's a shared media and even USB3 devices and microwave ovens 'use' these frequencies.

 

In case you live in a city simply forget about using 2.4 GHz WiFi for anything else than transmitting a few bytes from time to time.

Link to comment
Share on other sites

Donate your old hardware to community. Start a giveaway Raffle!

  • 0
pmayer

pmayer

Posted
  • Author
Posted

Hi tkaiser,

 

thanks for you answer. Indeed the 2.4GHz band is very populated here. No Problem with a Pi3 on the same networrk though. But as you've said, I don't have to expect much from the Nano Pi Neo Air.

I will investigate further on disabling the power management... read this somewhere but did not get it work last night.

 

I've tried nmtui, but the stable release does not come with it and without network I can't install it. Maybe I should manually download the .deb's and install them via dpkg. Kind of a chicken/egg problem ;-)

Last night I also tried the nightly - there bcmdhd could not be found on modprobe. Is this the right module for the NeoAir?

 

I'm also running a 5GHz network but of course the NeoAir can't handle it. Could you give me an advice which is the best (better) way to go?

Maybe get a Wifi-Dongle and connect it over an usbhub to the NeoAir to use 5GHz? Or just ditch the whole NeoPi thing for WiFi?

 

Cheers,

Patrik

Link to comment
Share on other sites
  • 0
tkaiser

tkaiser

Posted
Posted

I don't understand why the download pages for boards where images are considered 'beta' link to outdated images but here you go: https://img.armbian.com/nanopiair/archive/

 

Nightly builds with 4.9 should be avoided by end users. I personally tested WiFi with the Air in an area where 2.4 Ghz band is close to unusable and after disabling PM (use google search link in my signature for 'h3consumption wifi') it was at least multiple times better compared to the usual USB Realtek crap (8192 and marketed as 300 Mbit capable). But as already said: if you run in trouble with 2.4 GHz and live in a city the 'environment' is most likely to blame and of course the try to use el cheapo WiFi crap that is on all these cheap SBC these days.

1
Link to comment
Share on other sites
  • 0
pmayer

pmayer

Posted
  • Author
Posted

I'v installed Armbian_5.24_Nanopiair_Ubuntu_xenial_3.4.113 and was up and running with nmtui in something about 20 seconds - great! Sadly a stable ssh connection to the NanoAir is still not possible.

 

Whilst if I ping (eg) google from the NanoAir over the serial console all looks good - well, better as from the outside.

root@nanopiair:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=48 time=139 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=48 time=30.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=48 time=35.2 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=48 time=30.9 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=48 time=25.5 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=48 time=39.7 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=48 time=40.7 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=48 time=34.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=48 time=42.3 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=48 time=32.0 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=48 time=31.5 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=48 time=33.8 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=48 time=38.1 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=48 time=34.1 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=48 time=70.6 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=48 time=31.7 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=48 time=30.5 ms

I will try to disable the power managed as advised and will get back to you.

 

Thanks!

Link to comment
Share on other sites
  • 0
pmayer

pmayer

Posted
  • Author
Posted

Testing with iwconfig wlan0 power off looks very promising:

wlan0     IEEE 802.11  ESSID:"myssid"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: XX:XX:XX:XX:XX:XX   
          Bit Rate=19.5 Mb/s   Tx-Power:32 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=5/5  Signal level=-28 dBm  Noise level=-91 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:87  Invalid misc:0   Missed beacon:0

PING nanopiair.fritz.box (192.168.42.165): 56 data bytes
64 bytes from 192.168.42.165: icmp_seq=0 ttl=64 time=4.723 ms
64 bytes from 192.168.42.165: icmp_seq=1 ttl=64 time=5.024 ms
64 bytes from 192.168.42.165: icmp_seq=2 ttl=64 time=3.540 ms
64 bytes from 192.168.42.165: icmp_seq=3 ttl=64 time=3.715 ms
64 bytes from 192.168.42.165: icmp_seq=4 ttl=64 time=6.022 ms
64 bytes from 192.168.42.165: icmp_seq=5 ttl=64 time=4.323 ms
64 bytes from 192.168.42.165: icmp_seq=6 ttl=64 time=6.277 ms
64 bytes from 192.168.42.165: icmp_seq=7 ttl=64 time=4.520 ms
64 bytes from 192.168.42.165: icmp_seq=8 ttl=64 time=3.529 ms
64 bytes from 192.168.42.165: icmp_seq=9 ttl=64 time=3.363 ms
64 bytes from 192.168.42.165: icmp_seq=10 ttl=64 time=10.152 ms
64 bytes from 192.168.42.165: icmp_seq=11 ttl=64 time=6.779 ms
64 bytes from 192.168.42.165: icmp_seq=12 ttl=64 time=4.317 ms
64 bytes from 192.168.42.165: icmp_seq=13 ttl=64 time=5.317 ms
64 bytes from 192.168.42.165: icmp_seq=14 ttl=64 time=6.257 ms
64 bytes from 192.168.42.165: icmp_seq=15 ttl=64 time=4.003 ms

But my ssh connection is still unusable. The password prompt comes up imediately but after the motd nothing more for many minutes:

pm@nanopiair.fritz.box's password: 
 _   _                   ____  _      _    _      
| \ | | __ _ _ __   ___ |  _ \(_)    / \  (_)_ __ 
|  \| |/ _` | '_ \ / _ \| |_) | |   / _ \ | | '__|
| |\  | (_| | | | | (_) |  __/| |  / ___ \| | |   
|_| \_|\__,_|_| |_|\___/|_|   |_| /_/   \_\_|_|   
                                                  

Welcome to ARMBIAN Ubuntu 16.04.1 LTS 3.4.113-sun8i 
System load:   0.03            	Up time:       32 min		
Memory usage:  6 % of 494Mb  	IP:            192.168.42.165
CPU temp:      37°C           	
Usage of /:    8% of 15G    	

Last login: Fri Jan 13 12:51:00 2017 from 192.168.42.145

Any more ideas?

 

Oh, and here's the armbianmonitor output: http://sprunge.us/OJhY - booted from eMMC meanwhile.

 

Thank you!

Link to comment
Share on other sites
  • 0
tkaiser

tkaiser

Posted
Posted

Any more ideas?

Nope. Just that it looks like it's not related to network. On the Air you can use a serial console over the Micro USB connection so it would be interesting what happens when you log in this way and if that works you could observe using eg 'ps auxww' what's happening while logging in through SSH.

 

BTW: Since you mentioned Etcher or our flash tool: It should be noted that FriendlyARM saved the necessary FEL button on this board so you would've to burn a pretty small SD card image to turn the Air into FEL mode after booting from SD card (the image is contained inside the application bundle as Zador explained)

Link to comment
Share on other sites
  • 0
pmayer

pmayer

Posted
  • Author
Posted

...it would be interesting what happens when you log in this way and if that works you could observe using eg 'ps auxww' what's happening while logging in through SSH.

 

I'm having a serial console over the provided rx/tx-Pins with an FTDI over /dev/tty.usbserial-AL01R2TJ  (id of the ftdi board) - this is the way I can work with the NanoAir. Also I've tried the suggestes method over /dev/cu.usbmodem.14111 and reached a login prompt which - also - works flawlessly. Fast, responsive and without any wait times.

 

I think I see the the USB connection in ps auxwww:

hciattach /dev/ttyS3 bcm43xx 115200 flow bdaddr 43:29:B1:55:01:01

Nothing special I can spot when connecting via SSH... This is the output of w, the ssh connection simply seems idle:

root@nanopiair:~# w
 14:49:57 up 6 min,  3 users,  load average: 0.05, 0.11, 0.06
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
pm       ttyS0                     14:44    2:22   0.67s  0.38s -bash
pm       ttyGS0                    14:44    4.00s  1.39s  0.36s -bash
pm       pts/0    192.168.42.145   14:48   52.00s  0.37s  0.37s -bash

Console via rx/tx-pins, via USB and via SSH.

 

Sadly my CM109 card wont work on 113 - alsamixer just hangs und the usb-card wont get active and is not recognized in lsusb anymore.

 

Regarding Etcher: I thought that's what sunxi-armbian-flasher-osx is for? I was just referencing to a error I get when using this tool.

 

Thank you!

Link to comment
Share on other sites
  • 0
pmayer

pmayer

Posted
  • Author
Posted

Just to rule out hardware issues I've installed the current DietPi-Image for the NeoAir and SSH (dropbear) works right away.

 

Is it a good idea to check the differences in some config files? And when yes, how can I do it?

Link to comment
Share on other sites
  • 0
tkaiser

tkaiser

Posted
Posted

Just to rule out hardware issues I've installed the current DietPi-Image for the NeoAir and SSH (dropbear) works right away.

 

To me the problem seems not related to network/SSH. What if you move all of the motd stuff (IIRC /etc/motd/) away and try again? BTW: bcm43xx is bluetooth.

Link to comment
Share on other sites
  • 0
pmayer

pmayer

Posted
  • Author
Posted

Thanks for clarification regarding the bluetooth module.

 

I've touched $HOME/.hushlogin as suggested here: http://superuser.com/questions/704590/can-i-disable-ssh-last-login-and-motd-on-a-per-user-basis and motd is gone.

SSH is smooth now even with powersaving on. I don't understand this... obviously :mellow:

I totally hate not to know why this is the case.

 

Maybe something cause I don't use USB-OTG anymore?

USB-OTG won't work in 113 - USB itself, via the header pins, works...

 

//edit:

ssh in as root shows the motd and is also smooth after some seconds...

 

//edit2:

after using the sound-dongle via sqeezelite the problem is there again. Must be something with usb....

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to question listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept