I see that V2.06 has just been released. Could you please tell us how it differs from the V2.05?
Specifically, I am interested in the following items:
I don't actually know, I am not a core kernel developer, I do not know the DMA framework enough to do something about it. Only testing can prove this point, sorry about that. The kernel patch version changed from 81 to 82, and I cleaned the build tree, hopefully it will fix any sparse error that may be due to miscompilation.
No, the Candela firmware is an opt-in feature that you will need to install by yourself if you are willing to try it.
It has been disabled from versions v2.04 and onwards. This means that from that version, hostapd will be the one that will kick-out the clients, not the firmware itself anymore. This is different from the default firmware kick-out, which will kick-out clients (regardless of hostapd opinion) when they drop 20*16 frames. Also, it differs from previous versions of this build because they were configured to kick-out clients more aggressively, at 5*1 frames dropped. Now, it is the total responsibility of hostapd.
OK, so if I load V2.06, I will then need to add the hotfix from V2.04 in order to have the Candela beta FW?
Yes you flash that file. Even if I am not going to include it by default at this moment (in the future, we can see), I do really recommend it because Candela was actually informed about the problems with this device (don't ask me who did it, but thanks to him/her) and it looks like they are working on fixing it. Only time will tell, and we really want to provide them with good and quality feedback.
When I extracted the V2.06.tar.zst, I only found the EA8300 bin. Will the EA6350v3 bin file be coming at a later time?
I have a copy of that file, and I see the file for all supported devices, including the EA6350v3. Can you check, carefully, again? If not, try downloading and extracting again.
I downloaded the V2.06 tar.zst again using a different computer this time, but the result was no different. After unzip with Peazip the only file in the .bin folder was a single EA8300.bin file. I have previously unzipped V.2.05, V2.04,V2.03, etc with no problems. I am not sure what the problem is.
I understand. I am using Keka on macOS and also using ARK on Linux. Both can uncompress the file cleanly. Anyway, I uploaded a .zip version if, for some reason, PeaZip can't uncompress the other one. it is way bigger, by the way.
Thank you for providing the .zip file for us windows users. I was able to easily extract and load V2.06 + the hotfix from V2.04. My EA6350v3 is now running V2.06 + HF with 7 wired devices attached plus 6 more 2.4 Ghz wireless devices attached and 1 Iphone connected at 5 Ghz. I anticipate that the number of active connections to the router will range between 11 to 16 over the next several days.
Wonderful, let's hope everything works flawlessly now.
Side note: I upload the .zst version because my internet is really, really slow (500kbps upload), and it will take forever to upload a .zip file that weights 150 MiB, but the .zst file should work. I don't understand why this time it decided to fail.
is possible to make build for ezviz w3 ? is qca4018 with only 128mb ram
The random reboots continue with V2.06. After first bringing the router up with V2.06 it rebooted after 13 hours uptime, then it rebooted again 8 hours later, and then 3 hours later another reboot. I have removed the EA6350v3 and the internet is now running with my Netgear router as my wife needs to get some important work done and needs a reliable network.
I will add that during this trial period for V2.06 the wireless worked very well with excellent range and stability.
I am experiencing the same with my two IPQ40xx devices, but it is not just that. I am trying to get fixed another set of bugs. From like 15 or 21 days, the master branch has become very unreliable. I do not recommend updating anything beyond v2.03 until we can figure out why the kernel is crashing without apparent reason.
(These two bugs are only one particular package of a series of broken packages due to the same reason)
@M10 yes, it is doable. We will need to port some of the changes that I made to OpenWrt, to make it work with your device. If you are willing to beta-test it, we can work on that. However, OpenWrt is broken at this moment, and I am going to hold my breath until it gets fixed.
OK, I will wait until I hear from you that the kernel has been fixed. I want to repeat that I am very pleased with the performance of the Candela beta FW based on my limited use of it so far.
As I recall V1.12 did not suffer from the random reboots of later versions, but the downside of that version, if I remember correctly, was that wireless performance was not very good.
Now, I am wondering if it would be possible to load V1.12 and use the Candela beta FW with it by loading the the hotfix from V2.04. So, would it be possible to load V1.12 and then add in the V2.04 hotfix?
fantastic news, so i'll wait for news, thanks
I was doing my weekly commit inspection and I found this:
What if we have a problem similar to it?
If the problems are with signal strength (relative to comparable APs), that would be quite possible - if there are also problems in close proximity, you're probably dealing with a different issue. The map-ac2200 has always been working reliably for me, just its range was severely disappointing before that commit.
Yes, the device performs well nearby and fails completely when you get far away enough. Sensibility is also affected, so it is a both-way problem (RX and TX).
When the clients are near, it performs as expected but it is severely impaired at a distance. Devices like my Convexa-S does not show a similar behaviour and also it only happens in the 2.4 GHz band.
That sounds pretty familiar, and https://wikidevi.wi-cat.ru/Linksys_EA8300 --> "5GHz Power Amplifier IC;Skyworks;SKY85408-11;85408-11, 53999, 1632 MX;4;" would fit into the picture as well. It's quite likely that these external amps need to be enabled (via GPIO settings) as well - in case of the map-ac2200 the comments about DPDT suggest proper configuration for the DPDT rf switch, so the signal gets routed to the correct antennas.