pmayer Posted January 13, 2017 Posted January 13, 2017 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
tkaiser Posted January 13, 2017 Posted January 13, 2017 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.
tkaiser Posted January 13, 2017 Posted January 13, 2017 BTW: fiddling around in text files like /etc/network/interfaces is not recommended. Better use nmtui since network-manager re-establishes lost connections to the AP if necessary.
pmayer Posted January 13, 2017 Author Posted January 13, 2017 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
tkaiser Posted January 13, 2017 Posted January 13, 2017 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
pmayer Posted January 13, 2017 Author Posted January 13, 2017 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!
pmayer Posted January 13, 2017 Author Posted January 13, 2017 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!
tkaiser Posted January 13, 2017 Posted January 13, 2017 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)
pmayer Posted January 13, 2017 Author Posted January 13, 2017 ...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!
pmayer Posted January 13, 2017 Author Posted January 13, 2017 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?
tkaiser Posted January 13, 2017 Posted January 13, 2017 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.
pmayer Posted January 13, 2017 Author Posted January 13, 2017 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 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....
Recommended Posts