Posted: Sat Nov 27, 2021 13:47 Post subject: reason to upgrade
The reason is dnsmasq 2.82 has a whole bunch of vulnerabilities that were patched since January sometime. (google and you will find them easily)
I too was running 44048 for a year with no issues and good wifi speed.
I updated to 47581 > 2 weeks ago. It has been OK but I must admit wifi speeds are a bit slower and some devices in my house drop from time to time. Overall, it is not bad, I just need to deal with vs. being vulnerable.
Now I do wish that somehow 44048 base code could be simply updated with dnsmasq 2.86. However, I do not think that is even possible.
Posted: Sat Nov 27, 2021 20:33 Post subject: Reply to kernel-panic69
I want to be clear that I was not saying that 47581 build is all bad. All functions i use, including dnscrypt work well. I was just stating facts. I did speed tests on every device before and after and every one is a bit slower. Not terribly but like 10-15%. BTW, I upgraded with a full nvram erase and manually inputted all my settings, using the same ones for wifi as I had used in 44048. I upgraded to the same partition as I always keep stock on the other one. Now you mentioned to upgrade to both partitions. I thought they were independent of each other but i can try that if you are suggesting it.
In summary, thanks for a great product and all you and brainslayer do ! It is way better than stock IMO. I will stay on latest builds because using dnsmasq 2.82 seems too risky to me.
Not 100% applicable to DD-WRT, but from OpenWRT wiki:
The WRT AC series of routers uses a dual firmware flash layout. This means that two separate firmware partitions are included on the device and are flashed in an alternating fashion.
If booting from the primary partition, the secondary (or alternate) partition will be flashed on next sysupgrade, and booting is toggled to happen from that partition. The same logic applies to secondary–>primary. Note that this means there is no permanent “OEM partition” and “OpenWrt partition”. Both firmwares follow the same round-robin logic, where partition usage changes at each sysupgrade. The current firmware always remains as the fallback, and the new firmware is flashed to the other partition.
See the Flash Layout section on each device page for more details, or options to switch between partitions below.
I am asking those who have experienced issues with recent builds also because no one reported r47665
I have no Apple devices but . . .
Upgraded WRT1200AC v1's from r47656 to r47665 using Brave 1.10.97 (64-bit) running on Linux Mint 20.2 OS hardwired via Cat6.
Ran r47665 from release date till yesterday when I reverted to r47656 which was working for me without issues since release.
Reason for reverting was Roku/FireTV/FireTV Stick devices would not see internet even though devices show wireless connection was strong. This would occur later in the day when we would start evening streaming. Only the Roku/FireTV/FireTV Stick devices were affected as phones, tablets, TV, Pendoo devices and Sony devices connected as usual.
After disconnecting/reloading the devices they still would not connect. Rebooting the router would cause the devices to resume their normal behavior until several hours after use they would again not see the connection when opened on R47665. Rebooting the router again fixed problem. Odd since every other wireless device worked as expected without any fails.
May be my setup only as this is the first odd behavior I've seen in a long while. All devices working as expected since revert to r47656. All devices worked well on r47692. Update: Also on r47695 as of this morning no issues.
In short, only r47665 failed to work properly for me.
I don't understand the notes around 47711 and 47712, but you've got me excited! Prior to seeing this, I was going to nominate 47692 for "release of the year" and certainly the best release since 44048 for me. I'll wait and test the next release with these fixes.
"problem is triggered by tearing down and re-establishing a-mpdu sessions. This depends on traffic patterns
and client behavior. The first agg session is likely to work, since it will have a low seq number and the driver's
seqno will be mostly in sync with mac80211's seqno. Subsequent sessions will trigger this more severely."-nbd
47711 is the patch, 47712 fixes possible driver crash due to invalid rates and mesh fwd_skb->dev TX handling.