Depressing to see a “reboot every 20 days” hack / workaround for whatever stuff doesn’t work correctly. OTOH the xfinity Arris modem I used to have rebooted almost daily whenever it felt a bit sad (I think if the BER crossed a threshold or something), so I suppose it’s an improvement if that’s your baseline.
This is very often due to upstream vendor issues. In the case of routers, even if you're the one designing the IC's, building all the layer 7 services, industrial design of the plastics, etc; there's likely still a vendor providing your radios and their drivers are almost always a black box for you.
Sometimes, while you go back and forth with the vendor in a hapless effort to repro anomalous bugs, the best thing for the customer is reboot-every-N-days instead of degraded-performance-forever.
It sucks, but its commonplace.
(N.B. I work in this space and its definitely been a pain point that we've had to accept to be able to make progress)
It wouldn't be a huge issue if the user had control on when the reboot would occur. I mean, for many users it would be much better to have a reboot at 4AM say every sunday morning than randomly and possibly in the middle of something important. An external timer power cycling the router at the desired moment before the 20th day can solve the problem as the counter would then restart, but it would have been trivial to implement it in software.
The norm in embedded world, particularly if the component giving you hard-to-debug issues is a "black box" where you have to deal with binary blob firmware - and almost everything dealing with WiFi or BT is closed source.
It is very likely that most Qualcomm customers like Starlink have access to the source code of the Qualcomm proprietary Wifi driver for the QCA wifi Access point SoCs. Some vendors also have access to the source code of the proprietary Wifi firmware running on the Tensilica CPUs inside the Wifi IP core of the SoC. (Linux runs on an ARM CPU in this SoC, the wifi IP cores are an extra realtime FW)
End consumers normally do not have access to some source code or any documentation about these chips, sometimes even the competitors are getting access to source code to integrate their solution better. I do not know whom they protect against, probably all people who did not sign a NDA.
These thinks are only shipped to end customers in binary only version to protect the IP from someone. Often it is pretty easy to tell the system it is now operating in a different country (e.g. setting in Web UI) and then it will not comply to the local radio regulatory requirements any more. From my experience it is not the FCC which really demands it, please blame the chip vendors for binary only driver first.
The worst hacker for a silicon vendor, where they normally protect most against, is some guy like the author of this blog post who analyses his device in much detail and tries to run own software on it which was not verified by the vendor first. Such software modifications could cause worse customer experience because it is performing worse (which is funny if they have to reboot the vendor software every 20 days) or could cause extra support effort.
In my experience, its exceptionally rare to have vendors release code like that, if for no other reason than opsec concerns. Obviously larger clients have much more leverage, but even in those situations its usually because they're getting a bespoke branch of whatever mainline firmware is produced for their other retail products (assuming its not from-scratch for a client that size in the first place).
> It is very likely that most Qualcomm customers like Starlink have access to the source code of the Qualcomm proprietary Wifi driver for the QCA wifi Access point SoCs
No. They are jus that hard to work with.
MTK, Qcom, BCom are all terrible with software support, no matter who you are.
Candela Technologies for example has access to the QCA wifi firmware source code for the QCA Wifi 5 AP chips. They provide custom builds here: https://www.candelatech.com/ath10k.php
I know of one other company.
I do not know if they also have access to the driver source code, but I assume so.
Silicon vendors often do not care about small customers, small is probably less than 250k units per year. If you are a customer which is expected to generate more than 5% of the revenue for the complete product line or the business unit then you get good support from these companies.
The proprietary Broadcom Wifi driver was leaked multiple times by some companies which did not run the script to clean a GPL tar, but did something on their own and forgot to remove the Boardcom wifi driver source code. Last time I saw this was already 8 years ago. The Broadcom proprietary Wifi driver also contained the source code of the firmware running on the ARM chip inside the Wifi IP, at least it did this some time ago.
For the Qualcomm 5G modem and the graphics driver this is probably different.
Unless you're Apple, I'd make an exception there - they absolutely require support from their vendors for all their non-standard stuff: AirPlay WiFi-based screen mirroring, Handoff, Thunderbolt-based Target Display Mode / Target Disk Mode.
Apple always demands to be in control of what is running on their devices, no matter what - even where it's pure software that's concerned, like with the NVidia fallout - and they (usually) insist on quality... there's a reason why Apple hardware feels so painless to interoperate, compared to the Windows or Linux world.
