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.