I have found the same and not only with this device but also on WRT1900ac. I think WPA3 is not very well implemented in many client drivers because it is not commonly used and therefore, not well tested. I have several devices that act up with WPA3 enabled at all whether roaming or not and I don't think it has to do with ath11k. It is notable that WPA3-SAE requires 802.11w with 802.11r whereas WPA2-PSK with 802.11r, 802.11w is optional.
The old WRT1900ac has a known driver bug with 802.11w so I always though that was the problem with WPA3, but the same devices act up connected to the AX3600 with WPA3-SAE and 802.11r enabled.
When I enable WPA3 on AX3600 the WPA3 clients basically refuse to roam with some error noted in the logs. All works reliably on WPA2-PSK, 802.11r, and 802.11w. I have not tried again since switching to qca-full-htt which has some roaming fixes in it.
Quite a few 'smart' devices (including phones) don't like WPA2PSK/ WPA3SAE mixed mode nor 802.11r, they tend to be better with WPA3SAE-only and 802.11r disabled. This is a client issue, sadly not fixable on the AP side (apart from setting up distinct networks for WPA2PSK and WPA3SAE, at least with the later switching 802.11r off).
This has been my experience as well. Sweet spot seems to be 27dBm on AX3600. It will still connect, but at lower data rate up to 29dBm. At 30dBm I start getting weird errors and crashy drivers. I am in a very high noise environment. AP placed on second floor of the building can pick up over 100 networks on each band.
This is my kconfig from the robimarko tree that includes SQM. It is working. It also has strongswan, dawn, collectd, adblock, ddns, dashboard, led config, and some extra cli utils like iperf3, tcpdump, and iftop. All working except strongswan will crash if you roam off network and bounce the router.
Yes. You are probably missing the board-2.bin. You can find the working file and copy it to the appropriate directory on the device and reboot.
Its been a couple weeks since I made a build, but the last time around it looked like it supposed to pull it from some qit repo and for whatever reason wasn't even though the file is there. You can copy it into the build tree or copy it straight on the device after installing a build.
Exactly the opposite here. I have to say that I'm forcing WPA3 only. Roaming is working basically. But most clients are lazy and not going back to 5G after they switched to 2G (but in rare cases this happens). I've played around so far with usteer but that is bugged (init script needs a fix in OWT) and is (my observation after reading the configs; no docs available) doing nothing because it is treating both bands equally. Next I will try dawn.
I think its all still in development. E. g. If I enable roaming on Xiaomi AX3200 (MTK based). I have to disable "Generate PMK locally" and set R0 and R1 manually to make roaming work. For the AX3600 I don't need to do this.
On the other hand if I enable roaming and WPA3 on AX3600 my Arch Linux client with Intel AC Wifi needs ages (30s+) to get a connection. I found out that DHCP is playing ping pong as soon roaming and WPA3 is enabled (this does not happen on AX3200/WP3/roaming enabled). Without roaming and WPA2 its all fine.
I don't know the root cause. But I found out that if I change the dhcp client for NetworkManager everything is fine. NM has a built in DHCP client based on nettoools. If I use dhclient or dhcpcd declared within NM config everything is working within seconds as usual. I don't know what here are the differences in terms of DHCP server/client. I thought that this is a very strict protocol.
Working roaming is an own problem and the forum is full of it.
But as mentioned there seem to be an specific issue when you combine roaming plus sae-mixed so some clients cant connect. But also nothing specific to AX3600.
I didn't try usteer although I read about it. Dawn does seem to work, but requires umDNS (might be an issue if you need to repeat mDNS on multiple subnets as it fights with Avahi) and also needed some tweaking the settings to get the behavior I wanted. It also has a Luci plugin so you can at least see what its trying to do (but you can't configure it).
I've read about this being necessary when one platform is big endian and the other is little endian, setting the PMK to 0000 to make it work both ways. There's no standardization of the byte order in the spec, apparently. I've seen these features work well in enterprise stuff like Cisco Meraki , but the environment is homogeneous.
Interesting. It almost sounds like the traffic is looping on the backplane until the interface comes up. I could see NetworkManager resolving that because NetworkManager will also try to manage the state of the interface. DHCP is pretty simple on the wire and its also plaintext if you capture it.
If I were to start looking anywhere, I'd be curious if that repeating traffic is broadcast or unicast (can be either) and if the headers are identical. I'm pretty sure DHCP sends a transaction ID that should be incrementing on every set of requests.
In terms of delay, I know I was seeing some delay connecting Wifi clients on AX3600. The delay seemed to be cause by STP re-converging on the 1st client that reconnects to an empty AP. Turning off STP in the UI config doesn't actually turn it off, but I wrote a short script the uses, I believe swctl to turn it off, which seemed to work. I would think that STP would not be desirable on a WiFi. I wonder if the packet hits the buffer while STP re-converges and just keeps looping there until everything come up.
Thx for the hints for dawn and about the PMK "issue". STP is a good point for the delay too. I've enabled it by default (usually). Might be I've made I mistake in my crosslink setup. I didn't look into it further after I've switched my dhcp client and it was/is working on other devices.
I wonder if someone could start a "comment chat" over commits to tell them that their drivers needs to be improved instead of commented with "end of list".
My impression about this is that most companies just throw things to the community when there is a need/demand for their own business. To avoid publishing patented stuff or stuff which would help their competitors they are feeding us with fragments (maybe even disguised) working for their needs. I doubt that they have a quality check in place. For that they "have" the "community". I would be interested in a statistic about code quality (if viable) contributed by companies according to this: https://lwn.net/Articles/839772/
One upon a time, I worked for an open source company that went commercial. The insight that I can give you on the process, at least with that company, was to address issues for paying customers as a priority. However, bugs that were submitted by OSS users typically did get addressed, eventually, and may have even received high priority if the issue uncovered was urgent enough. Any bug that was submitted and fixed became a test case for regression that was added to the QA workload later on.
Now, I'm not bashing QCA but it does seem that they've had a policy over the years of doing only what was necessary to appease open source customers and even in some cases ignoring them entirely. So, I'm not really surprised. I would like to see companies like QCA devote more time to OSS users, and I'm not defending QCA's lack of transparency, but at the same time, I do understand that they need to ultimately cover their expenses in patching bugs.
I'm not sure if there are any companies out there at present that really use OpenWRT as a significant part of the product. It seems a lot of the builds you see like AX3600 are built on some very old release of OpenWRT, so even if the changes they're making are reported and fix that version, the fixes don't necessarily port to future versions.
If you consider the target market of AX3600 - home use - one can probably see that even if the firmware they release is... buggy.... it may well meet the needs of the target deployment environment. I think that in many cases that what users of OpenWRT are doing with this product is well above and beyond the scope for which they were designed. I'm not really defending QCA and think it would be better, in general, for companies to cooperate more openly with OSS, but there is a reality that if a large enough customer does not pickup using OpenWRT on said hardware its unlikely for QCA to devote much engineering time to improve a product they do not sell. It would be great to see a company like QCA pick up the torch, like was started with the original WRT routers and Linksys, and make an effort to produce an OSS product that is well supported by the chipset manufacturer and not abandoned.
I first started using OpenWRT as a transplant from LEDE. I think there is a market for a well supported OSS product, but it will likely take significant investment by an outside entity with a marketable platform to get their attention. The whole history of Linux is riddled with unnecessary hackish workarounds to problems the vendor doesn't see as important, but can be addressed if there is an open dialogue. Don't give up. The Linux community has always been this way.
With QCA the core issue is that they clearly put most of the effort into their fairly old custom kernel and connecting infrastructure, and there is very little upstreaming going on. And their paying customers are using that. SO they dont give a.... This is why it is so important what Robi and Ansuel are trying to do: if the 807x gets OWRT support with reasonable number of devices, there will be a large enough customer base they can't ignore anymore... Hopefully.
I'm on board. I think QCA can give us a little more to figure this out. Robi and Ansuel have done a beautiful job here.
This is why I asked many back if they post the code...maybe I can port it. I am by no means a crack coder but I will take a crack at it if given the chance. I think Robimarko and Ansuel have gone well above and beyond here. These people deserve our salute.
As far as Ax3600 and others close to it go... we are VERY close to a completely working build. Its too bad QCA will not help us to complete it.
Now, I believe that maybe wanna see what we can do. Can we get this fully going? I say YES. Lets keep going and maybe QCA will see what we can do.
AX3600 is, in my opinion the closest we had to fully working code since AC1900. This is so close we want to scream and I can see why Robi and others are frustrated. Thats what I'm pointing out. These guys(maybe girls) definitely deserve our respect as, in my opinion, have taken the project much further than anyone else in recent years, and I thank them for that.
I understand, we need QCA to fill in the gaps, otherwise, we will always be shooting in the dark. I would like to implore upon QCA to please, even if they are leaving us fragments to work on, to get this going.
I will put it right out there now. If QCA can help us get to full functionality, I will spend the money myself then I will buy their product. Many of us have been waiting since wrt1900 to get this done.
Are you hearing us Qualcomm? We want an open source router to solve mid-band needs. QCA has a lot of SOHO and SMB users that will pay to get it all working.
I think OpenWRT has proven that there are amazing untapped skills here that fill a void in the market. Lets address it. I'd like to see a proper vendor stand behind the skills of this open source community to get working setups that maybe require a little bit of work, but are not their corporate customers and not OSS "freeloaders". There is an in-between here and a market to be addressed, IMHO... we need a vendor who will address those needs. There is money to be made here.
