Search the Community

OK, somewhat obvious: forgot to set CONFIG_WLAN_VENDOR_XRADIO in the kernel config-file. This time compiling the kernel failed, partly due to the face, that the current "add-xradio-wireless-driver"-patch has not been updated to the 4.11 version. Nope, I do not think it is ... (e.g. missing parameter for ieee80211_cqm_rssi_notify function etc.)

Like the thread-starter I was happy with the xradio-implementation in 4.10 and would like wifi-support in 4.11. Taking the advice of jhpadjustable and tkaiser and attempted to built a 4.11 kernel enabling the xradio-related patch. The kernel works alright but there still is no wlan0. Syslog shows a failed attempt to modprobe xradio-wlan during boot and there is no xradio-module in /lib/modules/4.11.1-sun8i/net/wireless/. I am probably missing something ultra-obvious here ... can anyone help?

AP mode works (with OpenWRT and with Armbian since if OpenWRT uses Armbian's legacy kernel and firmware then functionality is the same): https://translate.google.com/translate?sl=pt&tl=en&js=y&prev=_t&ie=UTF-8&u=https%3A%2F%2Fwww.zonamaker.com.br%2Ftransformando-orange-pi-zero-em-um-roteador-wi-fi%2F It's just not worth the efforts since performance sucks (even if OpenWRT users seem not be able to either take notice or measure) and the manufacturer of this chip is not able to provide any technical documentation. So from our point of view this device has no Wi-Fi capabilities and we won't further waste time on this. Further readings: https://forum.armbian.com/index.php?/topic/3243-orange-pi-zero-wireless-module-status-xradio-st-cw1200/ (technical discussion) http://www.cnx-software.com/2017/05/09/allwinner-g202-dual-core-processor-is-designed-for-smart-wifi-speakers/#comment-542287 (intercultural problem)

The syntax was wrong, and it worked with KERNELBRANCH='branch:orange-pi-4.11' , is it the same syntax for all orange pi boards ( i use Opi lite)? The u-boot package build was successful, but problems appear with kernel, so about the patches, what you mentioned above is exactly what happened, but it is not as disastrous as i expected, only few failed (if you except my userpatches) : [ .... ] Patching kernel for compiler support [ o.k. ] Started patching process for [ kernel sun8i-dev ] [ o.k. ] Looking for user patches in [ userpatches/kernel/sun8i-dev ] [ o.k. ] ... [u][c] 9700-1.patch [ succeeded ] [ o.k. ] ... [u][c] 9700-2.patch [ succeeded ] [ o.k. ] ... [u][c] 9700-3.patch [ succeeded ] [ o.k. ] ... [l][c] add-BergMicro-SPI-flashes.patch [ succeeded ] [ o.k. ] ... [l][c] add-ad9834-dt-bindings.patch [ succeeded ] [ warn ] ... [l][c] add-beelink-x2.patch [ failed ] [ o.k. ] ... [l][c] add-configfs-overlay-for-v4.10.x.patch [ succeeded ] [ o.k. ] ... [l][c] add-emac-pwr-en-orangepi-plus2e.patch [ succeeded ] [ warn ] ... [l][c] add-h3-aliases.patch [ failed ] [ o.k. ] ... [l][c] add-h3-overlays.patch [ succeeded ] [ warn ] ... [l][c] add-h3-simplefb.patch [ failed ] [ warn ] ... [l][c] add-opi-zero-dts-with-wireless.patch [ failed ] [ o.k. ] ... [l][c] add-overlay-compilation-support.patch [ succeeded ] [ o.k. ] ... [l][c] add-realtek-8189fs-driver.patch [ succeeded ] [ warn ] ... [l][c] add-thermal-otg-wireless-opi-lite.patch [ failed ] [ warn ] ... [l][c] add-uart-rts-cts-pins.patch [ failed ] [ o.k. ] ... [l][c] add-wifi-pwrseq-opi-pc-plus.patch [ succeeded ] [ o.k. ] ... [l][c] add-xradio-wireless-driver.patch [ succeeded ] [ o.k. ] ... [u][c] dm9601-bug.patch [ succeeded ] [ o.k. ] ... [l][c] enable-codec-orange-pi-2.patch [ succeeded ] [ o.k. ] ... [l][c] enable-codec-orange-pi-pc.patch [ succeeded ] [ o.k. ] ... [l][c] nanopi-neo-air-wireless-and-dvfs.patch [ succeeded ] [ o.k. ] ... [l][c] packaging-4.x-DEV-with-postinstall-scripts.patch [ succeeded ] [ warn ] ... [u][c] patch01.patch [ failed ] [ o.k. ] ... [u][c] patch02.patch [ succeeded ] [ o.k. ] ... [u][c] patch03.patch [ succeeded ] [ o.k. ] ... [u][c] patch04.patch [ succeeded ] [ o.k. ] ... [u][c] patch05.patch [ succeeded ] [ o.k. ] ... [u][c] patch06.patch [ succeeded ] [ o.k. ] ... [u][c] patch07.patch [ succeeded ] [ warn ] ... [u][c] patch1.patch [ failed ] [ warn ] ... [u][c] patch17.patch [ failed ] [ o.k. ] ... [u][c] patch18.patch [ succeeded ] [ warn ] ... [u][c] patch2.patch [ failed ] [ warn ] ... [l][c] scripts-dtc-Update-to-version-with-overlays.patch [ failed ] [ o.k. ] ... [l][c] spi-sun6i-allow-large-transfers.patch [ succeeded ] [ o.k. ] ... [l][c] spidev-remove-warnings.patch [ succeeded ] [ o.k. ] Compiling dev kernel [ 4.11.0-rc7 ] [ o.k. ] Compiler version [ arm-linux-gnueabihf-gcc 6.3.1 ] [ o.k. ] Using kernel config file [ lib/config/kernel/linux-sun8i-dev.config ] After kernel configuration, it seems that the /sources/linux-sun8i/sun8i/scripts/dtc/livetree.c file is problematic. for now, i have no idea what this file is and what to adjust in source code. *** End of the configuration. *** Execute 'make' to start the build or try 'make help'. Compiling kernel... ---------------------------------------------------------------------------------------------------------------------- scripts/dtc/livetree.c:1008:6: warning: no previous prototype for ‘generate_label_node’ [-Wmissing-prototypes] │ │ void generate_label_node(struct node *node, struct node *dt) │ │ ^ │ │ scripts/dtc/livetree.c: In function ‘generate_label_node’: │ │ scripts/dtc/livetree.c:1058:7: error: ‘symbol_fixup_support’ undeclared (first use in this function) │ │ if (symbol_fixup_support) │ │ ^ │ │ scripts/dtc/livetree.c:1058:7: note: each undeclared identifier is reported only once for each function it appears in │ │ scripts/dtc/livetree.c: At top level: │ │ scripts/dtc/livetree.c:1066:13: error: conflicting types for ‘add_fixup_entry’ │ │ static void add_fixup_entry(struct node *dt, struct node *node, │ │ ^ │ │ scripts/dtc/livetree.c:862:13: note: previous definition of ‘add_fixup_entry’ was here │ │ static void add_fixup_entry(struct dt_info *dti, struct node *fn, │ │ ^ │ │ scripts/dtc/livetree.c:1098:13: error: conflicting types for ‘add_local_fixup_entry’ │ │ static void add_local_fixup_entry(struct node *dt, struct node *node, │ │ ^ │ │ scripts/dtc/livetree.c:925:13: note: previous definition of ‘add_local_fixup_entry’ was here │ │ static void add_local_fixup_entry(struct dt_info *dti, │ │ ^ │ │ scripts/dtc/livetree.c:1159:6: warning: no previous prototype for ‘generate_fixups_node’ [-Wmissing-prototypes] │ │ void generate_fixups_node(struct node *node, struct node *dt) │ │ ^ │ │ make[2]: *** [scripts/dtc/livetree.o] Erreur 1 │ │ HOSTLD scripts/mod/modpost │ │ make[1]: *** [scripts/dtc] Erreur 2 │ │ make: *** [scripts] Erreur 2 As you can see, it's not all the patches that are concerned , but may be i'm going to face other errors if this one is solved. i realize now what amount of work for each kernel change the community have to provide to make things easier for us.

With mainline kernel and its xradio module i cant connect to any open wifi networks. I tried wpa_supplicant network-manager and networking but this device just refuse to connect ap's that doesnt have encryption. This problem not related to performance nor coverage so please not say just crappy sources, dont have datasheet etc. and please try to fix this major problem. Thanks..

The amount of retries needed to get a frame in/out of the wifi interface affects more than just throughput. It can break association, DHCP etc. Of course you know all of this because you know better than everyone else right? It works for me from what I remember. I actually broke WPA/WPA2 support at some point trying to get the chip to pass encrypted frames directly to the kernel and connecting to open aps was the only thing that worked. As far as I can tell you haven't actually posted anything to show what happens when you try to connect to an open AP let alone anything that shows your issue is an issue with the xradio driver. And... it could be an issue that is unsolvable without more details on the firmware running on the chip. The xr819 doesn't just take frames off of the air and pass them to the host. Maybe it thinks it should be decrypting frames it shouldn't? Who knows. Maybe it is easy to fix but where are the logs and packet dumps? I'm not sure what your idea of reporting a bug is but it's not "This doesn't work for me, fix it now!". I don't think you have ever said where it fails to connect.. not associating outright is different to no passing any IP traffic etc.

My words of is for that anyone who writes about xradio drivers are ignored irrespective of what is written so i want to clarify that im not be annoyed of low throughput and i just want to connect my dorms wifi.. So as long as this open wifi connection bug is not introduced and developers doesnt know about that im here to do bug reporting that maybe can easily solved which i'm believing to.. Sorry for my bad and long english sentences kudos for developers who are still into it

Seriously? You do not even realize that @dgp is the person behind https://github.com/fifteenhex/xradio (one of the guys making this driver working in the first place). Please continue with your great contributions. I will from now on stop reading the H2/H3 subforum.

Sigh. I thought I'd spend the weekend working on the xradio driver again to see if I could work out why it drops so many frames and then I see this in the google search results while trying to find some more info on the cw1200 (if there is a register to query the state of the buffers). I find it really crazy that someone can come along and make a stink about people choosing not to do work for free and while providing almost no information to help debug their issue make out that it's an easy fix. I guess I'll read a book or something instead.

If nothing changes regarding firmware/drivers, official (supported) mainline releases should be provided without the XRadio driver and with explicit notice like "Onboard wireless is not supported". For now we should just link one of Xradio status threads/posts in the "Known issues" notice (or further expand on "connection issues", but not more than 2-3 lines), since the driver more or less works on legacy.

Like any other kernel module - either compile it out of tree or add it as a patch to the build system. In the first case you may need to remove or blacklist existing driver and you may need to change DT according to what that driver needs for initialization, in the second case you may need to disable or replace existing XRadio patch. This may not be a simple task for a beginner since it requires some skills and knowledge. Feel free to test and report. For now Orange Pi Zero wireless will remain in this state unless more information is provided. https://www.armbian.com/orange-pi-zero/ -> "Known issues" tab

I have posted a git repo that merges cw1200 driver with xradio support and asked how can i compile but i gave no answer. I think its like pull request with little support request for a beginner. I dont know if you tried to build that but it sounds more stable for me if got it working. Also i cant find any declaration of this open ap connection problem as known issue.

What kind of answers do you want? I believe everything was already answered in this sticky post: So I'll answer again: XRadio support package is a pile of crap This fact is listed as a known issue for the Orange Pi Zero In addition to the driver quality there are also firmware problems or possible incompatibility between the firmware and the driver Currently nobody is willing to waste time with this hardware unless vendors provide documentation, fixed firmware and driver (which most likely will never happen) Open source community is not obliged to fix every issue given to it by the vendor choice of the wireless chip In addition: Mainline (dev branch) images currently are provided "as is" without any end user support. We are accepting build failure reports, Device Tree overlay requests, kernel configuration change requests and reports not related to the possible kernel issues (Edit: and obviously we are accepting pull requests with kernel fixes). Just the fact that we provide mainline based configuration and images does not mean that we are obliged to improve it and fix every existing issue - we are trying to do what we can, but at the current state it is mostly waiting for the improvements and integrations upstream. Edit 2: So currently there is not enough information to fix this right away. It is unknown what exactly is causing inability to connect to open networks and what exactly needs to be changed to make it work, and unless more information is provided it will be this way.

You're saying that mainline is recommended in any case but with legacy kernel i can connect to my open AP .Also in this thread you mentioned it as best driver but this problem only occurs on mainline.. If its lack of hw it cant be connected with legacy am i wrong? I appreciate your effort and i thank you for it but developers just given up with this xr819 driver and cant accept any discussion. I even tried to compile driver from sources and changed some flags but cant get it worked. I found a xradio to cw1200 port in git but cant compile it https://github.com/plaes/xradio. little help ? thanks again

Besides the reset button which is manual, Has anyone resolved the watchdog issue solution I get this crash when oprangepi zero is on for a few days. My feeling is that the xradio drivers are messing the kernel up. I am trying to enable watchdog and build a process that resets watch if the kernel/filesystem is healthy. If not than watchdog should reboot orangepi z and start it fresh. [ 456.070016] ------------[ cut here ]------------ [ 456.080003] WARNING: at kernel/watchdog.c:255 watchdog_timer_fn+0xf8/0x2a8() [ 456.080003] Watchdog detected hard LOCKUP on cpu 3 [ 456.080003] Modules linked in: ir_lirc_codec lirc_dev ir_mce_kbd_decoder ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder sunxi_cir rc_core bnep xt_conntrack iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables btusb bluetooth bmp085 pcf8591 xradio_wlan g_serial mac80211 btrfs [last unloaded: scsi_wait_scan] [ 456.080003] [<c0016a20>] (unwind_backtrace+0x0/0xe8) from [<c0617a00>] (dump_stack+0x20/0x24) [ 456.080003] [<c0617a00>] (dump_stack+0x20/0x24) from [<c0029750>] (warn_slowpath_common+0x5c/0x74) [ 456.080003] [<c0029750>] (warn_slowpath_common+0x5c/0x74) from [<c00297a8>] (warn_slowpath_fmt+0x40/0x48) [ 456.080003] [<c00297a8>] (warn_slowpath_fmt+0x40/0x48) from [<c00a2e2c>] (watchdog_timer_fn+0xf8/0x2a8) [ 456.080003] [<c00a2e2c>] (watchdog_timer_fn+0xf8/0x2a8) from [<c004deb4>] (__run_hrtimer+0xe4/0x260) [ 456.080003] [<c004deb4>] (__run_hrtimer+0xe4/0x260) from [<c004ea24>] (hrtimer_interrupt+0x14c/0x2a0) [ 456.080003] [<c004ea24>] (hrtimer_interrupt+0x14c/0x2a0) from [<c0014a14>] (arch_timer_handler+0x38/0x48) [ 456.080003] [<c0014a14>] (arch_timer_handler+0x38/0x48) from [<c00a6c80>] (handle_percpu_devid_irq+0xb4/0x180) [ 456.080003] [<c00a6c80>] (handle_percpu_devid_irq+0xb4/0x180) from [<c00a3220>] (generic_handle_irq+0x30/0x40) [ 456.080003] [<c00a3220>] (generic_handle_irq+0x30/0x40) from [<c000ef54>] (handle_IRQ+0x8c/0xbc) [ 456.080003] [<c000ef54>] (handle_IRQ+0x8c/0xbc) from [<c000853c>] (gic_handle_irq+0x4c/0x6c) [ 456.080003] [<c000853c>] (gic_handle_irq+0x4c/0x6c) from [<c000dd20>] (__irq_usr+0x40/0x60) [ 456.080003] Exception stack(0xd71f5fb0 to 0xd71f5ff8) [ 456.080003] 5fa0: b6b633a0 b6b68a20 00000027 0000009c [ 456.080003] 5fc0: 0209cc6c 5d4c9a2d 0000001f 0209cbd0 b6b68a20 be8d0928 5d4c9a2d 0000000d [ 456.080003] 5fe0: 002b0b34 be8d08f8 5d4c9a2d 00051740 000f0030 ffffffff [ 456.080003] ---[ end trace f89dfaaa2af67e81 ]---

There are no better drivers (than those on nightly development kernel 4.10.x, if you don't already use it) . Read this: https://forum.armbian.com/index.php?/topic/3243-orange-pi-zero-wireless-module-status-xradio-st-cw1200/

We don't tell users they shouldn't use mainline, it's just that users shouldn't bombard us with questions and private messages about things that don't work at all, don't work as intended or not enabled by default. People complain about OPi Zero and OPi PC2 (close enough to H3), but the former is about to reach mainline in u-boot 2017.03 (~1 week from now) and kernel 4.11 (~2 months from now), and the latter is still WIP, 8th version of the support patches was posted yesterday and it may be not the final one yet. Regarding wireless drivers (8189es, 8189fs, XRadio) - they were poked just enough to make them work and it's not clear if anybody is interested in mainlining or just improving them, so unless they require some trivial fixes, they will probably stay as is for now.

thanks, the line worked, I see the compile now pulling orange-pi-4.9. Unfortunately, the compiled failed. Have anyone tried to 4.9? │ LD drivers/staging/built-in.o │ │ Makefile:988: recipe for target 'drivers' failed │ │ make: *** [drivers] Error 2 Problem is here, any quick thoughts how to proceed? Is this just me, or the current branch shouldn't compile with 4.9? result [-Wunused-result] devm_request_irq(dev, irq, sdio_irq_handler, 0, "xradio", func); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC [M] drivers/media/usb/stkwebcam/stk-webcam.o CC [M] drivers/net/wireless/realtek/rtl8189fs/core/rtw_recv.o CC [M] drivers/scsi/iscsi_tcp.o CC [M] drivers/net/wireless/realtek/rtl8189fs/core/rtw_sta_mgt.o drivers/spi/spi-sun6i.c: In function ‘sun6i_spi_fill_fifo’: drivers/spi/spi-sun6i.c:160:12: error: ‘struct sun6i_spi’ has no member named ‘fifo_depth’ cnt = sspi->fifo_depth - sun6i_spi_get_tx_fifo_count(sspi); ^~ drivers/spi/spi-sun6i.c: In function ‘sun6i_spi_transfer_one’: drivers/spi/spi-sun6i.c:304:19: error: ‘struct sun6i_spi’ has no member named ‘fifo_depth’ if (tx_len > sspi->fifo_depth) ^~ drivers/spi/spi-sun6i.c: In function ‘sun6i_spi_handler’: drivers/spi/spi-sun6i.c:345:34: error: ‘struct sun6i_spi’ has no member named ‘fifo_depth’ sun6i_spi_drain_fifo(sspi, sspi->fifo_depth); ^~ drivers/spi/spi-sun6i.c:352:34: error: ‘struct sun6i_spi’ has no member named ‘fifo_depth’ sun6i_spi_drain_fifo(sspi, sspi->fifo_depth); ^~ drivers/spi/spi-sun6i.c:360:33: error: ‘struct sun6i_spi’ has no member named ‘fifo_depth’ sun6i_spi_fill_fifo(sspi, sspi->fifo_depth); ^~ LD [M] drivers/media/usb/gspca/gspca_sq905c.o

I don't think you chose the correct word for the translation "Lobster" or "crayfish" would be more correct It can't be "not compatible" with OpenWRT, it's just requires additional kernel modules and firmware. And it's probably a better option than built-in Xradio wireless on the Zero. Again, Image Builder does not support unofficial kernels, so you need to have hostapd (which is included by default), kernel driver and firmware.

Hmm... the people who looked already in depth at the problem came to different conclusions: https://forum.armbian.com/index.php/topic/3243-orange-pi-zero-wireless-module-status-xradio-st-cw1200/ I also wonder why you think everyone would be using channel 1? Most people complaining try to use OPi Zero as client and I really doubt every AP on this planet is stupidly hardwired to use channel 1. Please also note that most people here use legacy kernel (as recommended) but the driver included there is just the original code drop we got from Allwinner without any changes made by community (the above discussion and all the work done happened with the mainline variant of the driver -- based on Allwinner's legacy driver though). Strange, so you're not experiencing high count of TX retransmissions that ruin throughput in TX direction if you get stable 5.5Mbits/s in both directions? Or is this just in one direction? If so why and are you then talking about RX or TX? And since we're at it: are you talking about legacy or mainline kernel? Edit: Would be interesting to look at a screenshot from your MBP when you option click on the WiFi symbol in the menubar (you could also enable 'Wi-Fi monitoring' there which would be interesting regarding long term reliability)

... I am not not sure what you mean...? I removed xradio from the /etc/modules #gpio_sunxi #w1-sunxi #w1-gpio #w1-therm #sunxi-cir xradio_wlan xradio_wlan Is that make the trick? I also see that there have been two lines with xradio... I wonder why. /R

If you use Mainline, then simply remove the whole xradio paragraph in DT.

Hi everyone, First of all I'd like to express my appreciation for the folks working on Armbian. I recently discovered the OPI0 and see many applications that could use an inexpensive yet full fledged embedded linux system. I'm not too concerned about the wireless throughput of the OPI0 but I do need stability, which I have not been able to achieve so far. I'm using the OPI0 as an AP with it's wireless interface bridged to the LAN interface. DHCP, DNS, gateway etc all provided for by another node on the network. A wireless device associates successfully, get's a bit of network access but as soon as I play a Youtube video it all starts failing. Here are some parts of dmesg and syslog although I guess most of you have already seen the message related to XRADIO (I've removed the bits that are likely not relevant). Has anyone been able to get the wireless to work reliably? [ 6.601429] [XRADIO] Driver Label:L34M.01.08.0002 Nov 14 2016 08:41:12 [ 6.601543] [XRADIO] Allocated hw_priv @ d5bf1240 [ 6.602314] [sBUS] XRadio Device:sdio clk=50000000 [ 6.602643] xradio wlan power on [ 6.754844] [XRADIO] Detect SDIO card 1 [ 7.101435] [XRADIO_ERR] xradio_load_firmware: can't read config register, err=-110. [ 7.101473] [XRADIO_ERR] xradio_load_firmware failed(-110). [ 7.437706] xradio wlan power off [ 7.437753] gpio wl_reg_on set val 0, act val 0 [ 7.487840] [XRADIO] Remove SDIO card 1 [ 7.488148] mmc1: card 0001 removed [ 7.488590] [mmc]: sdc1 power_supply is null [ 7.500494] systemd[1]: Started Journal Service. [ 7.540998] [XRADIO_ERR] xradio_host_dbg_init failed=2599 [ 7.541040] [XRADIO] Driver Label:L34M.01.08.0002 Nov 14 2016 08:41:12 [ 7.541148] [XRADIO] Allocated hw_priv @ d5bf1240 [ 7.541741] xradio wlan power on [ 7.541774] gpio wl_reg_on set val 1, act val 1 [ 7.591834] gpio wl_reg_on set val 0, act val 0 [ 7.593888] gpio wl_reg_on set val 1, act val 1 [ 7.694070] [XRADIO] Detect SDIO card 1 [ 7.695583] [mmc]: sdc1 power_supply is null [ 7.749447] mmc1: new high speed SDIO card at address 0001 [ 7.750272] [sBUS] XRadio Device:sdio clk=50000000 [ 7.751341] [XRADIO] XRADIO_HW_REV 1.0 detected. [ 7.947908] [XRADIO] Bootloader complete [ 8.185099] [XRADIO] Firmware completed. [ 8.187818] [WSM] Firmware Label:XR_C01.08.0043 Jun 6 2016 20:41:04 [ 8.196411] [XRADIO] Firmware Startup Done. [ 8.198911] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' [ 8.313819] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x48) [ 8.315067] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x48, dev addr: 0x48) [ 8.318255] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x77) [ 8.318316] bmp085: probe of 0-0077 failed with error -70 [ 8.966173] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro [ 9.344995] Adding 131068k swap on /var/swap. Priority:-1 extents:1 across:131068k SS [ 10.927838] systemd-journald[173]: Received request to flush runtime journal from PID 1 [ 11.372011] Bridge firewalling registered [ 14.440409] PHY: gmac0-0:00 - Link is Up - 100/Full [ 14.441407] br0: port 1(eth0) entered forwarding state [ 77.913076] device wlan0 entered promiscuous mode [ 77.913240] br0: port 2(wlan0) entered forwarding state [ 78.040468] [AP_WRN] ap restarting! [ 78.092772] [AP_WRN] vif0, AP/GO mode THROTTLE=35 [ 92.960132] br0: port 2(wlan0) entered forwarding state root@opi55:/lib/firmware/xr819# tail -f /var/log/syslog Feb 1 18:18:14 localhost systemd[1]: Started Session 3 of user root. Feb 1 18:18:18 localhost kernel: [ 92.960132] br0: port 2(wlan0) entered forwarding state Feb 1 18:21:06 localhost kernel: [ 261.050133] [AP_WRN] Multicast delivery timeout. ...snap... Feb 1 18:21:39 localhost kernel: [ 293.860293] [WSM_ERR] wsm_flush_tx:No pengding, but hw_bufs_used=1 ...snap... Feb 1 18:21:59 localhost kernel: [ 314.740116] [AP_WRN] Multicast delivery timeout. Feb 1 18:22:30 localhost kernel: [ 345.220307] [bH_WRN] miss interrupt! Feb 1 18:22:42 localhost kernel: [ 357.570241] [AP_WRN] Multicast delivery timeout. Feb 1 18:23:35 localhost kernel: [ 409.991567] [WSM_WRN] Too many attempts to requeue a frame. Frame is dropped, fctl=0x4208. Feb 1 18:23:35 localhost kernel: [ 410.350102] [AP_WRN] Multicast delivery timeout. Feb 1 18:23:41 localhost kernel: [ 415.997716] [WSM_WRN] Too many attempts to requeue a frame. Frame is dropped, fctl=0x4208. Feb 1 18:24:56 localhost kernel: [ 491.690269] [bH_WRN] miss interrupt! Feb 1 18:24:57 localhost kernel: [ 491.850202] [AP_WRN] Multicast delivery timeout. Feb 1 18:25:12 localhost kernel: [ 507.073815] [WSM_WRN] Too many attempts to requeue a frame. Frame is dropped, fctl=0x4208. Feb 1 18:25:38 localhost kernel: [ 533.210214] [AP_WRN] Multicast delivery timeout. Feb 1 18:25:54 localhost kernel: [ 549.137943] [WSM_ERR] wsm_flush_tx:No pengding, but hw_bufs_used=1 Feb 1 18:26:14 localhost kernel: [ 569.650088] [AP_WRN] Multicast delivery timeout. Feb 1 18:26:15 localhost kernel: [ 570.162082] [WSM_WRN] Too many attempts to requeue a frame. Frame is dropped, fctl=0x4208. Feb 1 18:26:23 localhost kernel: [ 578.290174] [AP_WRN] Multicast delivery timeout. ^C root@opi55:/lib/firmware/xr819# ls -al total 144 drwxr-xr-x 2 root root 4096 Nov 14 21:14 . drwxr-xr-x 12 root root 4096 Nov 14 21:14 .. -rw-r--r-- 1 root root 2308 Nov 11 00:14 boot_xr819.bin -rw-r--r-- 1 root root 975 Nov 11 00:14 device-xradio.mk -rw-r--r-- 1 root root 126416 Nov 11 00:14 fw_xr819.bin -rw-r--r-- 1 root root 744 Nov 11 00:14 sdd_xr819.bin root@opi55:/lib/firmware/xr819# uname -a Linux opi55 3.4.113-sun8i #50 SMP PREEMPT Mon Nov 14 08:41:55 CET 2016 armv7l GNU/Linux [ENDS]

Yes, the XRADIO driver is crap. This has been known for quite some time. If you want good WiFi performance, don't use an Orange Pi Zero. See here for further discussion of WiFi performance: https://forum.armbian.com/index.php/topic/3243-orange-pi-zero-xradio-st-cw1200/?p=22863 Summary:

There was one guy around who constantly spread huge amounts of insane BS regarding this 'driver'. He got now a final warning and I hope he'll never start again to spread BS and destroy threads. At least here. Regarding XR819: The driver has issues but that's not the main problem since you can't expect from 'cheapest hardware possible' superior performance/reliability. Ever heard of 'you get what you pay for'? Regarding state of driver (this is not a distro but a kernel/driver thing) please read here: https://forum.armbian.com/index.php/topic/3243-orange-pi-zero-xradio-st-cw1200/ (we as Armbian community are in a lucky position having those guys really working on the mainline variant of this driver communicating here in the forum. But immanent hardware problems can not be solved in software so while driver improvements might eliminate the TX retransmits currently most likely being responsible for very low throughput you still shouldn't expect anything regarding performance from the cheapest Wi-Fi solution currently available. No wonders possible) TL;DR: That's not a distro issue and simply forget about anything Wi-Fi related that's beyond IoT use cases. You get what you pay for! It's really easy to understand this relationship.