tkaiser

After doing some research I came to the conclusion that blindly trusting in MAC address randomization working as expected isn't a good idea, that I lack time and will to test whether Pinebook really does it correctly and that we can't 'prevent' predictable network device names anyway (eg. Debian declares the old scheme deprecated in version 9 and not available any more in 10). So I'm fine with the proposed fix.

Except of the two R boards all Bananas use the same AP6212/AP6212A which can be considered ultra low end especially for an AP. I second Igor's suggestion but recommend to read it closely and again: a board that will run mainline kernel or at least 4.9LTS with the 8812AU driver included is important (just noting since it seems your last buying decision was a bit precipitously -- if you would've done some research before you would've been warned wrt horrible vendor software support for some of the SBC brands out there, eg. Orange and Banana Pis most probably being the worst)

AP6212 or AP6212A so you need to instruct the driver to switch between normal and AP mode as Igor explained. You should be able to use any of the countless scripts around to deal with these Ampak modules (eg from FriendlyELEC or armbian-config)

Huh? There is no USB hub on the Expansion board, there's just some logic to route USB ports to either host or SATA ports. It seems you missed another option to use this Expansion board: without an OPi Zero connected to the GPIO header. IMO it's better to collect all we know at a single location: https://forum.armbian.com/index.php?/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/&do=findComment&comment=39250

Ok, that's the expected output so there's OTG on the NanoPi Duo Micro USB port. On the more recent Allwinner SoCs this port can be routed to both OTG and an own EHCI/OHCI controller pair which is done in software later (for legacy kernel -- in case you want to ever try this -- you'd search for 'g_ether h3' in this forum, for mainline kernel search for 'missing usb nano pi plus 2' or something like that, there was a discussion recently since on the NEO Plus 2 FriendlyELEC chose to expose usb0 as USB-A receptacle). In other words: It will work to turn the Micro USB port into a full USB host port but please don't ask how with FriendlyELEC's image The sunxi-tools package can be built from github easily and if you choose an Armbian image for the NEO2 most recent version is included on all images (possibly containing a bug). But SID isn't that important to know, I was just curious.

I don't think the FriendlyELEC powering conventions (to allow powering external devices on the Micro USB port also) is related to the USB port switching role between OTG and host. It would be great if you could do the following quick test and provide results: remove SD card (I hope you did not flashed anything to the SPI NOR right now) use a Micro USB cable to connect your Duo to the USB port of any other Linux host (eg the NEO2 in the background) Run there 'lsusb', 'sunxi-fel ver' and 'sunxi-fel sid' please (see here) My hope is the Duo then being in 'FEL mode' (connecting the SoC's OTG controller to the Micro USB port). To switch between host and OTG role different steps are needed with legacy and mainline kernel and I've not the slightest idea which patches and DT settings FriendlyELEC uses on their mainline kernel OS images currently.

There is no SATA port on this board, just the most crappy USB-to-SATA bridge currently known (called GL830 and even being broken since eating your last two sectors of any disk). When you forget about this 'SATA port' the best you could get are ~40MB/s with an external USB disk enclosure that makes use of UAS (see link). Onboard eMMC should be fast (40/80MB/s sequential write/read). Please see http://linux-sunxi.org/Sunxi_devices_as_NAS#Benchmarking_.2F_Identifying_bottlenecks and use iozone and iperf3 to test storage/network locally. No idea which OS image you use but at least 12MB/s write should be possible writing to a 'SATA attached' disk, +30MB/s with an USB2 attached disk and maybe +50MB/s when writing to the eMMC (SD card has it's own limits, explained here)

Everything you need to know is explained here: https://github.com/longsleep/build-pine64-image/pull/3

Where do they claim this?

Neither/nor. Banana Pi M3 is a total fail, neither board vendor (!) nor community interested in improving the horrible software situation with this board. The vendor's software offerings are a joke (3.4.39 kernel -- they're even too lazy to patch it up to latest 3.4.113 LTS kernel and also too lazy to fix common single line errors like http://igor2.repo.hu/tmp/opi_usb_gadget.txt that affect all their various code drops for all their various Allwinner boards) And linux-sunxi community who usually works on doing mainline kernel support more ore less ignores the SoC and the only (!) device based on it. I would believe your only hope is wens but I read recently in IRC he's not that active on A83T anyway (for example with mainline kernel this is still a single CPU SoC running at 1008 MHz or something like that) Once 2. changes and there's reasonable upstream software support by linux-sunxi community we can rely on there will be an Armbian release for this board (since we wasted already insane amounts of time dealing with this hardware). Time estimate: maybe 2019 if things progress that 'fast' as they currently do.

It is part of the still only recommended Armbian images for any H2+ and H3 devices and works there flawlessly. You're using mainline kernel which is marked as experimental and not supported. And unless someone else is porting h3consumption functionality to mainline kernel I doubt it will ever work there (fex files with legacy kernel vs. device tree with mainline). Though what you're trying to do is easy since only added/adjusted stuff in two simple text files (simply study what h3consumption is doing). I already dealt with blog posts mentioning even weirder stuff

Sounds like the better approach to me than choosing the first ugly workaround 'recommended' by Ubuntu/Debian community members. What are the possible downsides of switching back to the old naming scheme (long time Armbian users want to keep anyway)?

Yeah, I agree that XR819 could possibly be defined as 'worst case scenario' when focussing on most probably totally irrelevant iperf bandwidth measurements -- at least for the use cases these devices are bought for by people not trying to misuse them. But still... I've the same RT5572 thing as you, I've a different 8812AU dongle and a little 2x2 MIMO RTL8192 dongle (I would've never bought since myself being biased and thinking 'no real antennas --> no buy'). And when testing in totally overcrowded 2.4GHz band against a 802.11n AP (emphasis: crowded, 2.4GHz and 802.11n) I came to the conclusion to simply stop collecting numbers without meaning since the only obvious testing results were if you've at least 802.11n available and can make use of MIMO then try to USE IT (802.11b/g don't support MIMO). In crowded areas 1T1R vs 2T2R can make the difference between 'too slow for anything' and 'works just fine' with short distances and in a setup with 2 walls in between and some reflections provocated funny stuff happened (the small USB dongle performing better than the 8812AU thingie with huge antennas) over longer distances numbers changed and antennas became more important And then (as usual) I had to realize that 'benchmarking gone wrong' happened since repeating the same set of tests few hours later or when telling the AP to switch the channel from 'crowded' to 'reported as not so crowded' I got totally different numbers often in the other direction than expected. My personal learning was: MIMO is important, antennas are important if distance increases, switching from 2.4GHz to 5GHz is important when you live where other people live since for whatever reasons 2.4GHz is overcrowded while 5GHz is still mostly fine. And all collected benchmark numbers in such a situation are BS anyway. Unfortunately most people out there prefer data over information, love numbers even if wrong, love charts even if misleading and prefer easy answers over complex ones even if the easy answers are wrong. I think instead of providing another set of numbers without meaning we (as Armbian project) should focus on what's important: educating our users to make the right decisions.

But what exactly? I really don't understand why iperf numbers with same hardware (OPi Zero -- which PCB rev?) and 3.4.113 vs. 4.13.4 differs by 4 times. Wrt the Atheros 9271 the 'antenna diversity' note might be important. And do you also have a RTL8192 with 2T2R config available to test against the RTL8188 (since the latter being the crippled single antenna sibling of the former)? BTW: When I did some Wi-Fi 'performance' tests here in my area (in my flat I was able to 'collect' 140 different wireless networks on my Laptop when scanning for 48 hours) the time of day was way more important than anything else. After midnight I got magnitudes better results compared to the time between 6PM and midnight (when obviously numerous neighbours around used streaming services and trashed the performance). Also a simple channel switch could make a difference of +5 times different performance. My personal conclusion: measuring Wi-Fi with single antenna setups in 2.4GHz band in crowded areas is stupidly fooling yourself.

They used the small Xunlong antenna that's part of the package (just check the link to heise.de above for the picture -- I would say one can read PCB rev 1.4 there) and no idea about their Wi-Fi test setup.

Funny, today's german c't magazine issue features Orange Pi Zero: https://www.heise.de/ct/ausgabe/2017-21-Guenstige-Raspi-Alternative-3840980.html Wi-Fi performance measured with Armbian (only recommended OS): 32 Mbits/sec over a 20 meter (!) distance: So what do we do wrong all the time only measuring below ~15 Mbits/sec?

IMO no, especially not with this AP (being the bottleneck already for a 8812AU). We should maintain a database with recommended (since tested) external adapters and better try to educate users as we tried to do it in the past always. Helping users being able to interpret numbers they find here and there and understanding the importance of some other numbers, eg. that a 2T2R antenna setup compared to 1T1R will make a huge difference in a crowded area since with a single antenna setup there's almost nothing at a 15m distance while with a two antenna setup everything's still fine. Same with 2.4GHz (potentially overcrowded band but better to bridge long distances) vs. 5GHz (potentially higher performance but not over long distances)

This is wrong, yes. Not expected to work since customize-image.sh has to be run as part of the build process. If you want to install OMV later you would today download softy, execute it and choose 'Install OMV': wget https://raw.githubusercontent.com/armbian/config/dev/softy /bin/bash softy In a few weeks this is all part of next major Armbian release, then it's simply: armbian-config --> software --> Install OMV (works today also but installation is not optimized so today better use the wget workaround above)

Hehe... this is your setup with 40 Wi-Fi USB devices connected? Yeah, setting connection-mac-randomization to random doesn't make much sense. And still not knowing with which device to test first (since trying to keep it simple first with only one available Wi-Fi device connected, preferrable onboard)

Hmm... by looking around I came accross this (which doesn't seem to make sense to me but is reported to work) [device-mac-randomization] wifi.scan-rand-mac-address=no [connection-mac-randomization] ethernet.cloned-mac-address=random wifi.cloned-mac-address=random And then when reading about NM doing a Wi-Fi background scan every 120 seconds by default (can be disabled by locking the BSSID to the profile) and problems with some Wi-Fi driver this reminded me of the reported Wi-Fi reliability issues we had (only when connecting with NM/nmtui/nmcli and not happening when establishing Wi-Fi 'the traditional way'). Since I can't remember whether this occured with all sorts of drivers or only with one (eg. 8189fs for example?) may I ask whether someone else remembers? Just to decide with which board to further test...

And then reverting the additional NM defaults change back? Also individually for the Pinebook? As far as I understood the 'problems' are nmtui connect problem reported by Igor (most probably since NM changing MAC address in between call of nmtui and trying to establish connection?) According to the github issue syslog spamming (which I consider not being a problem since 'attaching to a network seems to have stopped the noise as well') According to the same github issue 'NetworkManager is keeping the CPU busy'. Does this change after stopping MAC address randomization? Is NM silent now or is it still busy bot now with the same MAC address? Adding to the above I wonder what's the state of affairs wrt Wi-Fi powermanagement and NM in Stretch (since dmesg output on Github seems to indicate it's not working as on Jessie or Xenial). I haven't looked into this myself but to me the issues that should been looked at a little bit closer wrt Stretch are powermanagement settings constant try to search for networks (how to disable this would be my first question) nmtui-connect problems (if we can stop NM from permanently searching for open Wi-Fis on its own is this still an issue then?) Adopting a workaround that's 'recommended' by countless Debian/Ubuntu users reminds of the 'UAS is evil' stupidity mess we have to deal with in the Linux world.

I'm really not sure since MAC address randomization should be considered an essential feature these days especially when we think about supporting devices like PineBook. At least I would suggest to first check whether stopping device renaming isn't the better option as described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839605#25 Does this apply to Stretch too?

Just check the SoCs: RK3288 does, RK3399 does (you'll find even some performance information here in the forum), Exynos 5422 does. They have Mali Midgard GPUs which is the basic requirement to be able to use OpenCL. Whether performance is sufficient, whether those outdated OpenCL versions are sufficient, whether your skills to write stuff in a way it can benefit from running as OpenCL kernels on GPU cores is sufficient are different questions though (never dealt with this stuff myself but one of my friends got mad over this few years ago)

Has anyone with access to the Shield and a SSD connected to the mSATA slot looked into how the JMS567 is powered on the board? I had a short look into Shield schematic and to me (noob!) it seems that PG11 is used to provide power the chip? If that's the case we would need the following set in u-boot to allow moving the rootfs to the mSATA slot, true? CONFIG_SATAPWR="PG11" Just asking since @Peter Scargill was asking over at CNX how to transfer the rootfs to an mSATA SSD. A possible way to test would be (with a SATA device connected): sunxi-pio -m PG11'<default><default<default><0>' lsusb sunxi-pio -m PG11'<default><default<default><1>' sleep 3 lsusb

Having both I would always prefer the HC1 over XU4 for heat dissipation reasons alone. And I would combine the HC1 with a fast SSD for such workloads. One of the two guys behind my link above shares some insights: https://www.cnx-software.com/2017/08/10/hardkernel-to-launch-stackable-49-odroid-hc1-home-cloud-200-odroid-mc1-cluster-solutions/#comment-545018