dgp

I'm not seeing anything after the probe request in either capture which suggests you aren't getting everything. I don't have anything to setup a test access point with right at this moment but I will test this myself at some point. Again, if it works for me I can't really do much without more raw data to go from.

Ok, so we can see probe requests going out from the xr819 (as long as this is not captured on the orange pi zero) and no probe response. I think you said this works with the legacy kernel driver. Can you capture the packets there so we can compare?

So it's missing the auth responses or not sending the packets at all. Do you have a laptop or something you can run wireshark on and dump what is happening on the air? Also what does /proc/interrupts look like?

There is a line in the Makefile for the module to enable debugging. You should see messages in dmesg about association even without that.

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.

You really couldn't make this shit up could you. As far as I know connecting to open aps and being an open ap with hostapd works. The main issues with the driver is that performance is awful because of all the frames it drops and that it's not structured very well and can lock up the kernel if it gets into a bad state. These things are also true if you compile the code dump from allwinner on their hotchpotch prehistorical kernel. FYI - A weekend of work on stuff like this will cost you more than $5000. The source for the kernel may be "free" but getting people to do work on stuff you want costs money and lots of it. You might want to think of all the free work people here have put into putting together something useful before writing any more of your bizarre posts.

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.

I suspect that's where most of the problem is. When I get time I'll setup my sniffing stuff and true to capture what is going on.

Are you able to get data like the number of retries etc from the AP to the orangepi? In iw wlan0 station dump on my hostapd based access point (totally different hardware) I can see a lot of TX retries for the orange pi client. A lot more than an of the other connected clients.

It was mostly cleaning stuff up like I have been trying to do. For example it took out the ITP thing which is apparently some hardware testing framework that requires tools only ST has access to to make use of. I'm not sure where the performance bottleneck with the current driver is. $iw dev wlan0 station dump; says it thinks the throughput should be ~13-20mbps and that's what I seem to get when scp'ing a file but it also does start out twice as fast before settling at that speed. So I wonder if we are actually failing to transmit frames at the higher rates and the rates are being adjusted down correctly or if what the driver is reporting to mac80211 isn't right and the rates are being lowered incorrectly. That said it's doing what I need at the moment. It's been running as a station and ap for a week or so now and has't crashed the firmware like the original driver did .

I had the issue with it crashing when I was trying to take the XR819 driver and backfill it into a new driver. There certainly does seem to be some things that have to happen in a certain order or the firmware crashes. If you define DEBUG in the makefile for my version of the driver it'll output the messages going to and from the chip and print out the types etc which might help. On the CW1200 driver: Someone tried to submit patches to make it work better in the past. It seems almost none of those patches got applied so the mainline driver is still roughly a source dump from ST. From what I can tell it has the same issues as the XR819 driver (locking up the kernel if things start go wrong etc). Apparently no one uses it as no one replied to my mail on the linux-wireless mailing list about it and the only patches it's seen recently are low hanging fruit from static code analysis tools. I think the original versions of the cw1200 went to market and ST still apparently sells it as part of a STM32 wifi module. The XR819 seems to be the 1160 which wasn't released according to a comment from the guy that sent patches to improve the cw1200 driver. IMHO we should try to improve the XR819 driver for now. Get it down to as little code as possible. I think there are places that can be replaced with stuff that's already in the kernel like the queue for TX packets.

I have the electrical datasheet which is useless. The chip and firmware is/is based on an ST/Ericsson design. The cw1200 driver in the mainline kernel source is basically the same as the xr819 driver and that driver (the in-kernel one) came from a code dump from ST/Ericsso so there probably isn't anyone that still has the technical documentation for the firmware (because ST/Ericsson no longer exists) and all winner have probably done a bunch of undocumented hacks in the firmware anyhow.

The driver relies on the host to do almost all of the MAC operation so it's actually limited a lot by the host and SDIO bus too. Also it only supports the bare minimum of N it needs to function.

For anyone expecting the wifi performance to be as good as their laptop or smart phone please adjust your expectations. This is a chip for super cheap applications. It's basically a G device that supports enough of N to avoid hurting the performance of network it's on too much. Even if the chip could handle high rates etc the SDIO bus it's on isn't amazingly fast either.

I added that. It breaks the driver at the moment. Should be N.

Most of those options will probably be removed at some point. The non power of 2 block size option for example has to be enabled or the firmware crashes. I'm slowly taking the useless stuff that allwinner/xradio have bolted on so that it's closer to the cw1200 driver in the kernel that it's based on.

Are you building the module externally to the kernel or have you integrated it back into the kernel source? If the later what are the kconfig options you have selected?

Can you post the full dmesg up to where the mmc errors start happening. Also the contents of /proc/interrupts

Interesting. Anyhow I have hostapd (wpa_supplicant in ap mode) working with WPA etc in dual role (station and ap) now in my version of the mainline driver so once the mainline version of the armbian image integrates it you shouldn't need to do tricks to get it working.

Sorry there was meant to be a "not" in there. I was trying to convey that I don't do anything that requires lots of bandwidth. I wouldn't bother buying SD cards from aliexpress. They are cheap enough on Amazon etc already.

Try it. I use the cheapest SD cards I can get and haven't had any issues but I'm also not trying to playback 4K movies.

1. yes, SPI NOR will only be used to load u-boot. Normal rules apply once the kernel is running. 2. U-boot already inserts fixed MAC addresses based on the unique chip ID from the processor if you kernel device tree is setup correctly. Works for both wired and wireless on mainline with my xradio driver 3. no idea 4. u-boot on SPI NOR is enough for booting a kernel over the wired interface with TFTP etc. You can then use an NFS rootfs to have a diskless setup. SPI NOR should be cheaper and more mechanically reliable (soldered on instead of a connector) than an SD card.... and if you get a chip that supports it you can write protect the blocks with the SPL/u-boot and make it pretty hard to break. Main con is that 100mbit isn't all that fast.. but if you run everything out of RAM it doesn't matter once booted.

Does it work if you disable WPA in hostapd? I'm working on fixing hostapd with WPA for my mainline version of the xradio driver and what I can see is that clients authenticate and associate but the handshake for WPA never happens and the client disconnects. There seems to be some disconnection between hostapd and the driver because the driver doesn't get anything to transmit between the association completing and the client sending it's deauth on disconnect. It might be hostapd expecting the chip to offload (do it itself) that part. :/

https://github.com/fifteenhex/u-boot/commit/56160c82d5f273bee8fdf1045eb415f9ae0c002c

Apparently no one uses it because even if you boot the current u-boot from SPI it will try to store the environment on MMC.