rjbrown99

I have a CHIP, it lacks an SD card slot which I also would like for storage of music. I'm really going for the one-device-to-do-it-all approach and the NPN Air is the closest one so far that meets the needs. OPi Zero has a USB slot so I could add an external BT adapter that is still pretty small, although it's bigger than the NPN Air.

I stopped with the 3.x kernel as I'm 1) fairly sure AP mode will work with op_mode=2, and 2) I really want 2 virtual NICs so I can simultaneously do one client interface and one AP interface at the same time. @tkaiser describes the 4.x issue, basically the kernel works but USB OTG patches are not included. If you solder the console pins to the board you can get console that way but I have not done that yet. My next move is likely to be to solder the console pins, try to boot the 4.x kernel, see if I can get wifi working, and if so I'll rebuild a new 4.x image with the OTG patches manually merged. But the Bluetooth audio thing is another hurdle, I was expecting to also use this as a 'traveling Amazon Echo' and I'd need working Bluetooth mic+speakers to do that. My backup plan is to try all of this with an Orange Pi Zero which is currently on order.

@StuxNet I'm trying to do something similar but using a different approach. What I really want to do is this: https://wiki.archlinux.org/index.php/software_access_point See the "Wireless client and software AP with a single Wi-Fi device" section. The challenge is the 3.x kernel driver in Armbian requires that op_mode=2 setting and from everything I see that setting is driver-wide. I am working under the assumption that the 4.x kernel driver is not limited like that, so it could run both client+AP from the same wifi device - except I have not yet been successful in booting a 4.x kernel as it lacks OTG support now for console access. For me it's for use as a pocket travel router, for you it might make it easier to switch modes by just bringing up and down client or AP virtual interfaces.

Thanks for the reply. Quoting StuxNet above: "I've been talking with Yuefi over at FriendlyArm and he has informed me that audio over bluetooth lacks hardware, and as result, software support on the NanoPi Neo Air. The only thing you can do with the bluetooth is transfer files. " If I understand that statement, the actual Bluetooth hardware itself on the NPN Air is not wired in such a way to have any BT audio support. Even if bluez supported HFP/HSP it still would not work on this particular device, correct?

One of my use cases, and why I'm interested in the 4.x kernel, is virtualizing the wifi NIC so it supports 2 virtual interfaces - one that acts as an AP and one that acts as a client. That way I could use an NPN Air as a portable travel router/firewall (my devices connect to the AP interface, the client interface connects to a hotel wifi for example). From my reading, the 3.x kernel with op_mode=2 is a 'driver-wide' setting, meaning everything is either in AP mode or it's not. Correct me if I'm off here. One of my Bluetooth use cases was as a portable Amazon Echo, which would require Bluetooth audio to pair to an external speaker/mic. But if that's not supported in hardware I'm out of luck with that idea as well.

Is there anything special about soldering on the 4 pin connector for serial console? I soldered on the 4 pin connector, plugged in my serial cable ground (black), 5v (red), TX (green), RX (white) according to the FriendlyArm web page, and see no signal at all. Tested with both Linux and MacOS hosts using screen. I can see the running agetty process tied to tty1 but can't interact with it. I did not solder on any of the other connections, just the 4 pin debug UART. Currently trying with the 3.4 kernel to make sure I can see console before testing out any of the 4.x/mainline stuff. The USB OTG/gadget console is still working so I can get in and see what's going on. My cable is this one.

Thanks @tkaiser, that's helpful feedback. Are there plans for OTG support in the near future in the 4.9 branch? Between that and thermal, I see OTG as the more important of the two to make it usable. Anything I can help with? If it's merging some code and creating a pull request I might be able to assist as I have a local compile environment in place already. I just need some pointers to the correct source repos and related area of the OTG code.

I'd be interested to know if anyone has successfully booted a Nano Pi Neo Air with the 4.9/dev kernel. I have tried a few times now, including building my own image from source. I don't have the debug pins soldered so I'm limited to interacting with just the USB OTG serial console which does not show up at all. Makes it challenging to troubleshoot with no debug messages to know why it's failing to boot. After trying to boot a few times I re-attached in FEL mode and mounted the root partition on my Mac using Paragon. I checked /var/log and saw no messages whatsoever, so this is telling me the kernel probably isn't getting past uboot or is hanging somewhere before mounting the filesystem.

I wasn't able to get the 4.x kernel booted (either Ubuntu or Debian) so make sure you are trying with 3.x. I also have not tried directly booting from sdcard but I have found that the images work very well when written to the internal 8gb storage. Both Ubuntu and Debian. Look earlier in the thread where tkaiser explains how to write the image to the internal storage and give that a try. https://forum.armbian.com/index.php/topic/1580-nanopi-neo-air/page-9#entry17707

One small note that may help others - after reading up a bit on the wifi chip in the NanoPi Neo Air, it is the same Ampak AP6212 that is present in the Raspberry Pi 3. This was helpful as it answered a lot of questions on capabilities, such as an ability to support simultaneous wireless client and AP functionality. Assuming the following can be ported, it would also likely support monitor mode with frame injection. https://github.com/seemoo-lab/bcm-rpi3 Another post worth reviewing related to AP-mode operation: http://tech.scargill.net/size-matters-neo-air/#comment-27039

In my experience to date, the wifi power setting is quite important. "Stock" armbian defaults to "Power managementmode: All packets received" when doing an iwconfig wlan0. Here's a ping on my local LAN: --- 192.168.1.100 ping statistics --- 112 packets transmitted, 109 packets received, 2.7% packet loss round-trip min/avg/max/stddev = 1.874/223.454/1289.673/234.571 ms Now run iwconfig wlan0 power off and retry the ping. --- 192.168.1.100 ping statistics --- 112 packets transmitted, 112 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.796/3.639/35.839/4.276 ms That's a tremendous difference. My $0.02 - power management should be disabled by default on the wireless interface. It's borderline unusable otherwise. I *thought* running "/usr/bin/h3consumption -w off" would flip off power management upon boot. In reality it does flip it off (when I add debug statements to the /etc/NetworkManager/dispatcher.d/99disable-power-management script, I see that it is turned off.) But something kicks in down the line and turns it back on such that after booting power management is enabled again. I'll troubleshoot and open an issue.

Again answering my own question. NetworkManager is a confusing animal. My connection name is 'Home'. When opening /etc/NetworkManager/system-connections/Home, I see the following (abbreviated) section: [connection] autoconnect=yes Cool, seems like autoconnect is turned on, right? How about if we look at nmcli directly now: # nmcli c show Home connection.autoconnect no Wait, whaaat? Okaaaaay.... so let's fix that using nmcli. # nmcli c modify Home connection.autoconnect yes And now it shows it properly, and the interface is automatically started on boot. # nmcli c show Home connection.autoconnect yes *shrug*

Not sure if anyone else is finding the same issue but I'm not seeing the wireless interface come up on boot. I have a saved NetworkManager profile, the NetworkManager service is starting, but no wifi. If I do an 'nmcli c up NetworkName' it does come up and start the interface. In process of researching it but if someone else has an idea I'm all ears. Thanks!

Answering my own question... git clone https://github.com/zador-blood-stained/fel-mass-storage Write fel-sdboot.img to an sdcard Power on the NanoPi Neo, boom FEL mode is back. Run 'start.sh' from that repo to enable the ability to see the emmc partition on the Mac. sudo dd bs=1M if=Armbian_5.24.161101_Nanopiair_Ubuntu_xenial_3.4.113.img of=/dev/disk2 unmount/reboot Reverting back to the 3.x kernel worked. After reboot it was just a matter of using screen to connect to the device. Nice!

I was doing fine trying an install using a variant of the instructions from here: http://forum.armbian.com/index.php/topic/1580-nanopi-neo-air/page-9#entry17707 Started the flasher, connected the Pi to USB, detected! Downloaded and uncompressed Armbian_5.24.161101_Nanopiair_Ubuntu_xenial_4.9.0.img. I confirmed the sdcard showed up on my Mac as /dev/disk2 in Disk Utility. I proceeded to write the image to that drive with sudo dd bs=1M if=Armbian_5.24.161101_Nanopiair_Ubuntu_xenial_4.9.0.img of=/dev/disk2 Write completed successfully, and since I have ExtFS installed on my Mac it mounted the filesystem successfully and I could see it. Unplug the Neo from USB, plug it back in, and wait.... Nothing. No new /dev/cu.* or /dev/tty.* devices show up. The sunxi-armbian-flasher-osx also does not detect the device any longer. The Mac does not see it show up as a disk in any way. Thoughts or input would be helpful, thank you.