May as well just sign the petition. I have not bothered as I lack the requisite headgear for engaging in a contact sport with a hard, immovable object.
Sure why not. This petition can happen on top of what I’m discussing certainly makes chances of success better if we dovetail.
In my vet humble opinion... you are being very naive here. However, I would really love to be proven wrong!
@eduperez, Lol ... ok
Anyway, will leave this forum post for anyone who has a good idea on how we can fix and rightly maximize our beloved Linksys routers.
I found this document ... may point us to the right direction.
I guess we will need donor routers as tinkering with this can brick the router.
Signed and chipped in £10 to help spread the word!
Just as a further update, I have also reached out to EFF since they offer legal services. Someone responded and gave a ticket number for tracking.
I really doubt this will go to the courts but it's nice if our request has some legal backing.
Just in case this qualifies for their legal assistance who among us is best contact to provide the best historical and technical context regarding this issue?
I think it cannot be Kaloz as he still works for NXP.
I did some scrounging and looks like it's NXP that needs to opensource the firmware. The weird thing about it, then seemed to have released the code for other firmwares except the ones running the more powerful routers. Hopefully this is just a case of "just overlooked" and not a corporate decision to screw us.
Not sure about what you expect from the EFF: we obviously have the right to ask them to open-source the firmware, but (unless we can prove there is GNU code in their firmware) they also have the right to refuse our request.
Yes, Marvell produced the chipsets, then NXP bought Marvell.
Have they released the code for the router's firmware (the equivalent of OpenWrt)? Or the chipsets' firmware (what we really need)? This can be a bit confusing, since the word firmware has two different meanings here.
Yes I did. I know it's not much but every little helps right?
Hmmm ... sorry I don’t know. All I can say, I am using “firmware” in the context of what @hnyman said here below:
Apologies, if this sounds like I am doing things haphazardly ... I am just throwing everything and just seeing what sticks. I am (hopefully not alone) just quite desperate to see if we can have a way forward.
My main intent is that we (OpenWRT) could organize and make a structured team and strategize how we could move forward or at least make one final push to solve this “firmware” issue before we give up and surrender all hope. That’s the reason why I wanted some kickstarter (or something similar) and funding setup as I’m sure we will need money from we will go from here. Also why we I approach EFF too and as responded in this thread there’s a change.org petition ongoing who seem to be in a similar situation and like minded as me
if you can demonstrate that the stock device( and firmware ) does not deliver what it states on the box... most countries have specific laws to prevent false claims by the manufacturer... which in AU entitles you to;
- a no questions asked refund ( short - medium term )
- liason via bureaucratic body with said manufacturer / distributor to resolve said issues
- hefy fines and sanctions for companies who fail to abide by said legislation
so... does the stock firmware do what it says it will do?
Thanks for taking time to reply
Well, if you go to the Linksys website it is stated there “Open Source Ready” this in my limited legal knowledge this sounds like they are falsely advertising as the firmware isn’t working properly even as a basic/advanced wireless router. Given that this is a wireless router it suffers from poor WiFi performance and reliability. This is actually what I said in my mail to EFF seeking their assistance.
I don’t know if that statement actually means they “should” support. As you can see the Linksys page doesn’t state a specific WRT flavor. I haven’t really tried other WRT flavors but I am assuming that same issues happen and that OpenWRT has the “best” support and most features implemented to maximize both WRT1900ACS and WRT3200ACM.
yup... that's pretty misleading...
reminds me of the playstation class action by people who purchased the PS3 when they alleged linux boot support ( yellowdog )... there even was basic / pretty good support...
then they removed that support...
10+ years down the track they had to give everyone globally... $50-100 back, in the previsor that they 'purchased / used the device with that intent in mind.... '
I'm no where near an expert by any mean but I'll try to summarize (the best I can) what I think that needs to be done in order to develop an open source driver for the 88W8964. First of all it will be needed to develop an emulator of the hardware itself (because of the lack of datasheet/user manual), so it is a must to read the content of the EEPROM (the chip with the blue dot in the picture). You can find the datasheet online by typing m24m01-r in the browser in order to create a program or a tool to get it's content. This is required as it probably contains the operating system of the SoC (probably a Real-Time Operating System and I bet it is a stripped-down VxWorks, albeit I'm probably wrong and it's not using any comercial Operating System and it is an in house one) and some fuses (preprogrammed values like DFS). Once we have the content of the EEPROM we have to manage a way to get the content of the internal bootROM (if we want a 100% supported emulator to completely understand the logic of the processor because of the lack of the Datasheet/Technical Reference Manual) which contains the vector table and some initialization logic (it would contain a CRC logic to avoid tampering the driver but I'm just speculating at this point) . I would like to remark to that in the picture you can see some pads (those copper points under the SoC) that could be possible some JTAG access (if the fuses aren't blown). Normally this kind of pads expose signals to test the system like voltage levels, but they are very close toghether so it could correspond to related signals, like the JTAG interface. If that is the case (and they still work) it should provide a lot of help for the task.
Once we understand the internal logic we can upload to our emulator the driver and see how this works by interacting with the functions present in mwlwifi (which loads the driver to the SoC and communicates with it). After all of that (I'm over simplificating at this point) once we understand the full logic of the driver, the new driver (not mwlwifi, I'm refering here to the actual code that runs in the SoC which for us is 88W8964) must be developed with clean room design in mind (it means rewrite it without infringing any copyright). Developing this kind of driver from 0 won't be an easy task (which means you need a lot of expertise in this area) and it might require special equipment.
I'm an advocate that it's not impossible to reverse engineer this SoC without a datasheet and debugging symbols (there's enough documentation about Cortex-A9 which means information about the core internals and normally the Intellectual Property designs, which represent the rest of the logic that is not the core per se, which are usually user peripherals, are made by another company like Synopsys, CEVA, Tensilica to name a few) but by the time you achieve that maybe WIFI6 has fully depleted the interest on this device (if this hasn't happened yet). If the peripherals are made in house then it should be possible to reverse it partially with the information present at the EEPROM binary (take in mind that understanding the peripherals logic would allow us to improve the driver but if we just want to make an open source version of it, it should be "fine" just to reproduce the present logic and build upon that). If they are not built in house it would be possible to scrap the peripherals mapping and register from another datasheet (only if we discover who is the IP designer by looking at the binaries).
There have been previous instances where a group has achieved a partial reverse engineer of a product without datasheet (for example PS4 and the most succesful one the PS VITA where they achieved it almost fully), althought those are more popular devices and they have a stronger community than this one. This kind of projects could attract "developers" if there is a plan in motion and things are happening. Until now I've never seen in the forum a serious proposal or anything like that so the expectancy is very low and I can understand why one could claim that it is impossible.
Sorry for this wall of text (I have never posted before). I hope this helps in stablishing a conceptual map of what it's needed and why it is actually that hard to have a firmware fix.
I haven't finished reading your post but this early I wanna say ... Wow ... in my eyes you're an expert looks like you know enough about this.
The 3200 doesn't even utilize dual core:
"The hardware queue scheduling is apparently configured with fixed
priorities, which creates a nasty fairness issue where traffic from one
CPU can starve traffic from all other CPUs.
Work around this issue by forcing all tx packets to go through one CPU,
until this issue is fixed properly."
Here's a muscle car that's broken in many ways OOTB.
Thanks for your response Yikes! I actually own a 3200 so it’s disconcerting to know this issue. Hahaha.
Seriously though, this strengthens our case hope EFF can help us with some free legal assistance.
Or may be a class action suit can help.
I seriously thought this closed source chipset would ever be disclosed because the vulnerabilities would be open to prodding.
PS4 and I think xbox x uses this chipset...if they open source it...and some enterprising hacker finds a buffer overflow to gain root access...piracy becomes that much easier. sony and ms and third party publishers would not be happy.
So NXP isn't evil per se but they have their reasons to placate their legacy major clients inherited from marvell
I think those are the 88W8797 and 88W8897 (https://github.com/x0rloser/ps4_wifi_bt) which have bluetooth integrated.
Althought it would be possible that the 88W8897 would be using recycled IP modules that we can scrap for the 88W8964 (which is the one in WRT3200/WRT32X). That could lead to a potential collaboration between two different communities (but I highly doubt so).