Search the Community

Hi, Recently I upgraded /sudo apt-upgrade/ my armbian and my wlan is now gone /it worked perfectly before/. Looks like xradio module is missing from the new kernel? I am trying to download driver from http://linux-sunxi.org/Wifi, especially from http://kaiser-edv.de/tmp/lGtv38/patch-add-support-xr819.tar.gz .... but the site is not working.

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.

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

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..

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.

We would all like better WiFi drivers. Unfortunately, all we have right now is what we got from ST-E/Allwinner and it's not very good. 52MBit/s is the PHY data rate, not the download speed. I'm getting at most 10MBit/s in testing (less than 1m from AP). The driver in use is xradio and can be built against the kernel sources (e.g. 4.9) so you have WiFi. Get it here: https://github.com/fifteenhex/xradio My modifications to the mainline cw1200 driver are enough to initialize the hardware, but the WiFi chip crashes when you try to scan or join a network. Since the cw1200 module in the kernel is almost identical to the driver from the Allwinner SDK, this means even if it worked with the XR819 (which it doesn't) the performance would be just as bad. Honestly not sure why a driver for pre-production silicon with crap performance ever made it into mainline, but whatever... We are working to improve the driver, but please realize: We have no datasheet from Allwinner on how it's supposed to work None of us are paid to do this We all have normal lives with jobs and shit that take up lots of time So please be patient, and don't ask us when it will be finished. If you need a board with good WiFi, then that is not the Orange Pi Zero. If you want to help, get Allwinner to release the datasheet so we don't have to guess how this thing works.

I have been having wifi connection issues with the OPi Zero as well. But only with the mainline kernel. With the legacy kernel, I can connect to my various access points and transfer data, SSH etc. I wanted to try out the mainline kernel, so about a month ago I downloaded one of the nightly builds I was not surprised that the WiFi didn't work at all. I waited several days while reading the forums and once folks were reporting a working mainline, I tried again. THis time I could see access points but could not associate. After a while I started investigating what could be wrong with my setup. At this point I had a working jessie 3.4.113 and a non working Xenial 4.9.0 (not working wifi that is). Both stock installs of Armbian 5.24. I tried several power sources, several usb cables, old slow SD cards, and new fast SD cards. All results were consistent, jessie 3.4.113 worked, Xenial 4,9.0 then 4.9.1,4.9.2,4.9.3 didn't. I then thought that maybe I had a bad OPi Zero, so I ordered and waited 3 weeks to get a second. It arrived the other day and all results with the new board were the same. Today I saw that there was an actual release of Xenial 4.9.4 for the OPi Zero. Downloaded it and got the same results. Ethernet works on both jessie and xenial. I have tried with the ethernet cable connected and disconnected. I have tried with power management on and off. I can do a iwlist scan and see access points on both systems. It almost seems like there is no data being sent from the OPi with Xenial. I probed the 1.8V and 3.3V power for the Wifi chip and both are at nominal levels. Both my boards are 512M and came with the SPI flash soldered on. This is a stock installation of the Armbian Xenial 4.9.4 I downloaded on 1/26/2017. No other packages have been loaded, upgraded or configurations changed. Messages which might be of interest: iwconfig wlan0 essid MyAP [ 1408.950945] xradio_wlan mmc1:0001:1: missed interrupt [ 1449.630902] wlan0: authenticate with 18:a6:f7:02:4d:fa [ 1449.630999] ieee80211 phy0: ignore IEEE80211_CONF_CHANGE_MONITOR (0)IEEE80211_CONF_CHANGE_IDLE (1) [ 1449.631309] wlan0: send auth to 18:a6:f7:02:4d:fa (try 1/3) [ 1449.631713] wlan0: send auth to 18:a6:f7:02:4d:fa (try 2/3) [ 1449.631858] wlan0: send auth to 18:a6:f7:02:4d:fa (try 3/3) [ 1449.631964] wlan0: authentication with 18:a6:f7:02:4d:fa timed out after ifconfig eth0 dowm then iwconfig wlan0 essid MyOtherAP [ 2237.719983] wlan0: authenticate with f4:f2:6d:a3:0e:5c [ 2237.720124] ieee80211 phy0: ignore IEEE80211_CONF_CHANGE_MONITOR (0)IEEE80211_CONF_CHANGE_IDLE (1) [ 2237.720154] ieee80211 phy0: Freq 2412 (wsm ch: 1). [ 2237.721079] wlan0: send auth to f4:f2:6d:a3:0e:5c (try 1/3) [ 2237.721619] wlan0: send auth to f4:f2:6d:a3:0e:5c (try 2/3) [ 2237.721951] wlan0: send auth to f4:f2:6d:a3:0e:5c (try 3/3) [ 2237.722278] wlan0: authentication with f4:f2:6d:a3:0e:5c timed out [ 2237.761757] ieee80211 phy0: ignore IEEE80211_CONF_CHANGE_MONITOR (0)IEEE80211_CONF_CHANGE_IDLE (1) modinfo xradio_wlan filename: /lib/modules/4.9.4-sun8i/kernel/drivers/net/wireless/xradio/xradio_wlan.ko alias: xradio_core license: GPL description: XRadioTech WLAN driver core author: XRadioTech alias: sdio:c*v0020d2281* depends: mac80211,cfg80211 intree: Y vermagic: 4.9.4-sun8i SMP mod_unload ARMv7 thumb2 p2v8 iw wlan0 info Interface wlan0 ifindex 3 wdev 0x1 addr 12:42:87:47:5c:af type managed wiphy 0 lsmod Module Size Used by evdev 10043 0 xradio_wlan 92375 1 mac80211 322651 1 xradio_wlan cfg80211 191902 2 mac80211,xradio_wlan rfkill 10928 3 cfg80211 sun8i_ths 3134 0 gpio_keys 8453 0 cpufreq_dt 3586 0 uio_pdrv_genirq 3354 0 thermal_sys 42239 2 cpufreq_dt,sun8i_ths uio 8012 1 uio_pdrv_genirq ip link show wlan0 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000 link/ether 12:42:87:47:5c:af brd ff:ff:ff:ff:ff:ff uname -a Linux orangepizero 4.9.4-sun8i #3 SMP Fri Jan 20 22:11:20 CET 2017 armv7l armv7l armv7l GNU/Linux nmcli device show GENERAL.DEVICE: eth0 GENERAL.TYPE: ethernet GENERAL.HWADDR: 02:42:87:47:5C:AF GENERAL.MTU: 1500 GENERAL.STATE: 30 (disconnected) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- WIRED-PROPERTIES.CARRIER: on GENERAL.DEVICE: wlan0 GENERAL.TYPE: wifi GENERAL.HWADDR: 12:42:87:47:5C:AF GENERAL.MTU: 0 GENERAL.STATE: 30 (disconnected) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- GENERAL.DEVICE: lo GENERAL.TYPE: loopback GENERAL.HWADDR: 00:00:00:00:00:00 GENERAL.MTU: 65536 GENERAL.STATE: 10 (unmanaged) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- IP4.ADDRESS[1]: 127.0.0.1/8 IP4.GATEWAY: IP6.ADDRESS[1]: ::1/128 IP6.GATEWAY: systemctl status network-manager ��◠NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor p Active: active (running) since Sat 2017-01-21 01:39:25 UTC; 31min ago Main PID: 543 (NetworkManager) CGroup: /system.slice/NetworkManager.service ��└��─543 /usr/sbin/NetworkManager --no-daemon Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6761] devi Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6777] poli Jan 21 02:06:27 orangepizero NetworkManager[543]: <warn> [1484964387.6790] devi Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6810] devi Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6821] mana Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6829] poli Jan 21 02:06:27 orangepizero NetworkManager[543]: <warn> [1484964387.6840] devi Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6871] devi Jan 21 02:06:27 orangepizero NetworkManager[543]: <info> [1484964387.6945] devi Jan 21 02:06:32 orangepizero NetworkManager[543]: <info> [1484964392.9635] devi My question is this, where should I go from here to debug this issue, has anyone seen the same or similar problems. I have been able to rebuild the kernel from sources using the Armbian tools, but that was a few days ago with 4.9.3 and now that 4.9.4 is in use, I haven't had time to try building it again. My thoughts were to turn on wifi debugging and see what messages came out. For my project I could use the legacy kernel, but I'd rather not. BTW. I AM in a rural area where the only AP's I see are my own, and there is little other traffic on 2.4G (this may not last forever, but today I can use 2.4G.)