FYI 18 was last updated 6 months ago.
1 Like
If you like to, you could provide security patches to this branch.
OpenWrt 18.06
Outdated release!
This OpenWrt release is no longer receiving updates. You should switch to a newer release.
Are the packages to upgrade wpad-basic and hostapd-common ?
Kernel (mac80211) and in some cases firmware for wifi devices and probably those packages as well. So you'll need to build a new image, get a new snapshot image or wait for the next release that includes those patches.
DD-WRT had fragattacks fixes in the builds 13 days ago (2021-05-13).
So whenever OpenWrt makes builds or fixes available via update,
similar if not identical patches will have been tested for some time (granted in a slightly different enviroment).
Two weeks later and the fixes still haven't been backported to 19.07. 
They were ported the next day. They just have not kick-started any builds yet for 19.x. You can test it in 21.x, if your device is supported there.
The patches are a 'good faith' implementation. Proving the patches do what they assert to do is not easy, so they're applied currently in the hope that they are effective. Evidently DDWRT and other projects believe in them.
3 Likes
21.02.0-rc2 has more builds today;
2 Likes
I prefer using the newer github, you can select the branch on the top left and see what commits are in:
What's the status of fixes in the 19.07 branch?
Are the mac80211 patches captured via https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ffd4452f8b241d1d5b5ea8a56206f51702bbd6c5
What about specific driver fixes (e.g. ath10k-ct)
Hi lantis1008,
you have to wait or update to 21.x branch.
Or build your own 19.07 from the sources. In that case you have to clone the git repository and compile it, to build your own unstable 19.07 package for your router.
Your linked commit patchset is just a backport for another Kernel and adjust Line numbers and Hashes. Take a look on "diff" in that commit and you see what code will change if the patch got applied.
$ ls openwrt/package/kernel/ath10k-ct/patches/
161-ath10k-add-support-for-configuring-management-packet.patch
162-ath10k-fix-possible-out-of-bound-access-of-ath10k_ra.patch
163-ath10k-fix-incorrect-multicast-broadcast-rate-settin.patch
164-ath10k-commit-rates-from-mac80211.patch
201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
202-ath10k-4.16-use-tpt-trigger-by-default.patch
203-ath10k-Limit-available-channels-via-DT-ieee80211-fre.patch
960-0010-ath10k-limit-htt-rx-ring-size.patch
960-0011-ath10k-limit-pci-buffer-size.patchTake in mind that you do not need a patch if its got upstream in the mainline Kernel, so you have to take a look there too.
So don't be shy, just take a look and observe, and compare code changes.
Appreciate your response. I was really hoping for the kind of response (by the devs) like
" Yeah mate no sweat it's covered in the backport"
Or
"Sorry bud not done yet but we plan to do it in X days/months/years"
Or
"We are not interested in backporting this set of security fixed to the 19.07 branch".
Rather than me try to analyse upstream myself, which I haven't had time to do, because I was hoping for the easy way out (see above).
Any of those would tell me what position and level of effort I have to go to.
You're probably not going to get a respnse, frag attack is a minor security concern for home users, for enterprise marginally moreso. It was fixed upstream in mac80211 and applied to Master and 21.02 over a month ago. They even noted "We currently don't have information about how other drivers are, if at all, affected."
If you're concerned just do a clean install to 21.02-snapshot, it includes a whole slew of other improvements including upstream DSA, kernel 5.4, LuCI overhauls, performance improvements, etc. I'm running it on my WRT32X with a 2 week uptime it's been great so far.
Guys come on.
I've been around here long enough. If i wanted to upgrade to 21.02 i would.
I'm looking at this from a perspective of making sure that builds that i support that are still on 19.07 have the security fixes.
4 Likes
You will recieve some kind of update sooner or later anyway because if you in the other corner was sitting around waiting for some commersial manufacturer to make a update for this problem you will wait for ever for nothing.
I have a TP-Link acces point and they haven’t made any updates to fix this problem either.
19.07 is only a couple of months away from the planned end of life so we will see how long that life is supported until 21.02 becomes the next stable flagship. But I don’t think that many dev actually work on 19.07 any longer. Probably a new mayor catastrophic failure like dnsmasq will be fixed like in 19.07.6 and 19.07.7 that was released to fix this problem. But a local wifi theoretical fault isn’t probably at highest prio.
Even worse problem would be that image builder doesn’t work for some devices in 19.07 but not even that makes a new release.
But on the other hand the current 19.07-snapshot is changed so slow now that it almost looks like a stable release.
1 Like
I can appreciate how you obviously feel on this. But the fact remains that this is a free and open source project that accepts donations but is still maintained and tested by volunteer community. to my knowledge openwrt does not provide any paid SLA support offering.
If you need that kind of support in your environment, perhaps you need to look into other similar wrt projects.
The FragAttacks fixes for ath10k-ct are still needed in 21.02.0 before release.
This commit needs to be merged https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=2e10ed925e1e07c28570731a429efa5e7de3b826 and https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f0f1d68d528402b4d51a1dd08d2e2c9034167f92
Best,
Nick
Wish granted it seems, updated ath10k-ct was ported to 21.02 branch three hours after your post. I'm gonna build my image again, since there's a few interesting mac80211 fixes as well.
Is ath10k (non ct) being patched? it's an essential driver for my Tplink archer c7's to work stable.
Isn't it closed source blob?