AFAIK, Cisco sell Linksys to Belkin, so i think they have serious organisational problems inside.
is there a way to force the web gui to use https instead of http? and also to change the default port the web gui is accessed on? (say https://insert.ip.address.here:8080)
The problem might be that I'm trying this too late, but I just noticed my statistics where not working either. Running r8289, I replaced the distribution for the ones above, but when I then try to install luci-app-statistics git-19.038.66435-4e5111e-1 I still get /usr/bin/lua: /usr/bin/stat-genconfig:20: module 'luci.sys.iptparser' not found:. When I used the original David distribution feeds, I get the same error, its always in loading iptparser (required in stat-genconfig). Do I need to install/reinstall something else?
Have you restarted the router after uninstalling/installing?
Not to mention Belkin has been bought out by some Taiwanese company Foxconn. Who knows what happens next.
I hadn't but just rebooted it now, and although statistics luca\Statistics shows (and inside you see graph and configuration, (and configurations seem to work), the Graph part never shows any modules at the top. When I run service luci_statistics restart I get the errors /usr/bin/lua: /usr/bin/stat-genconfig:20: module 'luci.sys.iptparser' not found:
this looks very scary. However patches are apparently available, so I hope the devs will be able to roll these out..
Looks like yuhhaurlin (contributor to mwlwifi) closed the GitHub issue and said the following:
Firmware of 88W8897 and 88W8997 are different code base. There should be no these issues.
"Should" be no issues. I mean he might be right, but that doesn't really sound like a concrete answer or that anyone has tried a proof-of-concept to see if it is indeed vulnerable or not.
The OP of the GitHub issue states the following by user jow-:
Is the firmware bundled with the mwlwifi driver affected? The linked report specifically mentions
88W8897chips and this repo contains abin/firmware/88W8897.bin.
I'm not sure how this .bin file is generated, if that comes from Marvell, or what the deal is. But it would be nice to get a second independent confirmation that things are all good / clear here. If there was a proof of concept exploit to test against so that we could get confirmation that things are fine that would probably be best case.
I know it's a tad off-topic to go a bit further than that in a thread about Davidc502's builds, but I think it is at least worth mentioning.
No error just goes back to LuCi and does nothing. I’ll try your fix when I get a chance and report on what happens.
Thanks
I'm trying to compile a list of information in one place to determine affected chipsets.
- https://www.scribd.com/document/398350818/WiFi-CVE-2019-6496-Marvell-s-Statement (Only mentions 88W8897)
- https://embedi.org/blog/remotely-compromise-devices-by-using-bugs-in-marvell-avastar-wi-fi-from-zero-knowledge-to-zero-click-rce/ (Only mentions 88W8897)
- https://2018.zeronights.ru/wp-content/uploads/materials/19-Researching-Marvell-Avastar-Wi-Fi.pdf (Mentions 88W8897 and 88W8997)
- https://kb.cert.org/vuls/id/730261/ (Mentions 88W8787, 88W8797, 88W8801, 88W8897, and 88W8997)
Other links regarding the vuln that didn't specifically call out chipsets but are worth mentioning:
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6496
- https://vuldb.com/?id.129973
- https://nvd.nist.gov/vuln/detail/CVE-2019-6496
There's definitely more links that could be added with other sources discussing the information, but I felt like this was enough worth mentioning. Taking this information, It looks like CERT actually has the most complete list of affect chipsets with 88W8787, 88W8797, 88W8801, 88W8897, and 88W8997.
Now looking at our supported list of routers by Davidc502, the Linksys WRT AC series here's what we've got:
WRT1200AC - Marvell 88W8864 (Not listed by CERT)
WRT1900ACX (Marvell 88W8864 for v1 and v2, not listed by CERT)
- https://openwrt.org/toh/hwdata/linksys/linksys_wrt1900ac_v1
- https://openwrt.org/toh/hwdata/linksys/linksys_wrt1900ac_v2
WRT3200ACM - Marvell 88W8964 (Same hardware as WRT32X, Not listed by CERT)
WRT32X - Marvell 88W8964 (Same hardware as WRT3200ACM, Not listed by CERT)
So now my question is, some of the articles list this as an issue with the "Marvell Avastar series" of WLAN chipsets. Is it possible that the chipsets listed above by CERT and others are only the known affected chipsets, or does it affect the entire line of Marvell Avastar series? If it's only the list of chipsets that are outlined by CERT, then Davidc502 builds aren't affected by this. If it's a problem at the hardware level for all Marvell Avastar series chips and they didn't test every chipset known to man, it could be possible this is affected from my understanding.
If anyone has any additional information to provide on this let me know, or if anything I said was incorrect. I tried to provide sources for reference for all of the information I provided and why I came to such conclusions.
I messaged Will Dormann from CERT (he is listed as document writer on https://kb.cert.org/vuls/id/730261/ and I was already following him on Twitter) and he replied with this:
This is what he is referring to on the Broadcom vulnerability
I think for now, I will stop posting this to this topic. Apologies on derailing, I may move some of this conversation over to the GitHub Issue https://github.com/kaloz/mwlwifi/issues/344
I am trying to install nodogsplash but it is not available on your repo.
Any chance you include this package? (not in the build, just the repo)
Thank you
Will take a look tonight to see if it is available. Almost everything is checked to compile. Sometimes packages fail from build to build.
1 Like
Also David, i would like to ask why you have different packages repo for each build, which also cannot be upgraded (at least not automatically) and you don't point us to the official openwrt repos
Official repos (stable or daily) are out (not used), and there are 2 reasons. The daily snapshots change every day and that includes any kernel changes. So, if the davidc502 build is 10 days old, the daily snapshot repo likely has had 1 or 2 kernel bumps since that time making the repo invalid.
The different repos are for convenience of the user and the ability to go backwards to another build if needed. So, we may have some folks here on a build from a year ago, and they don't want to upgrade. Their specific build will be pointed to the repo that specific build was "built" on. With that said if that user with a build 1 year old wants to install more packages the repo will be out there... meaning they don't have to upgrade to the latest build to get they packages he or she wants 
The caveat being if a new package was created and is available in newer repos then the user would need to upgrade.
Also, if we need to, all the images are still in each repo, so if something is screwy with a new build, we can always either go back to the last partition or flash to whatever previous build you want.
Hope that makes sense.
3 Likes
nodogsplash was marked not to compile... Probably due to a previous issue. It has been added back to be compiled, so it will be in the repo for the next build providing there are no issues.
1 Like
Please take a look at uHTTPd under Services.
Ohh... In fact, it's not so bad news for me - i work with Foxconn for some of my projects.
I'll ask them about plans... And maybe give some suggestions.
PS: I'm admiring about 802.11ax - it's really cool stuff. Hope it will be possible to add it by firmware for our hardware.
got it, thanks.
WRT32X's driver is buggy.
It doesn't accept custom mac address (option macaddr) for both 2.4 and 5ghz.
Also the issues with ESP8266 - ESP8285 (eg Sonoff Devices).
Linksys' driver works flawlessly. Any way to extract the driver from the Linksys firmware?
I can extract their .img and see the filesystem (Which also has a lot of trash inside from previous versions)