|
| ▲ | bcm4702 3 days ago | parent | next [-] |
| The amusing thing about that is that broadcom, not Cisco, was the culprit in the original WRT54G GPL violation. Cisco, of course, were legally liable and should have checked that the code they obtained was not encumbered - although the usual way to do that is to specify contractually that your vendor will do the checking. It was a huge issue for them that they had tripped a customer who provided a significant fraction of their revenue into legal difficulties. I suspect that to this day, a big reason that parts of broadcom are reluctant to open-source stuff is because certain executives are still angry about the experience. |
|
| ▲ | haukem 3 days ago | parent | prev | next [-] |
| MediaTek chips are well supported by OpenWrt. Broadcom is not good supported.
Mainline Linux kernel supports recent MediaTek Wifi chips quite well [1]. MediaTek is also working on these upstream Linux drivers, but they still have a proprietary Linux driver in addition. Also the rest of the recent MediaTek SoC is supported quite well by upstream Linux and OpenWrt. You can run OpenWrt on recent MediaTek SoCs with all code running on the main CPU being open source, no closed source code needed inside the Linux kernel address space or in user space. The chips need firmware running directly on the IP cores. It needs a firmware running on the wifi core itself, there are probably one or more CPUs inside the wifi cores doing real time stuff. The Ethernet PHYs also need a firmware which is running on the PHY. [1]: https://elixir.bootlin.com/linux/v6.17-rc5/source/drivers/ne... |
|
| ▲ | pbasista 3 days ago | parent | prev | next [-] |
| Ok, but this should not be a major limiting factor. From my experience, there is sufficient amount of routers based on well-supported chips which work okay with OpenWRT. When I consider to buy a new router, I go to the OpenWRT device support page, filter for features I would like to get and choose one of the supported routers listed there. |
| |
| ▲ | fiddlerwoaroof 3 days ago | parent [-] | | I gave up on openwrt when I realized that a lot of the recent WiFi standards seem to be badly supported. I think 802.11ac was significantly faster with vendor firmware than openwrt, for example. | | |
| ▲ | pbasista 2 days ago | parent | next [-] | | > 802.11ac was significantly faster with vendor firmware Yes, I also remember similar issues with TP-Link Archer C7 running earlier versions of OpenWRT. It got better with later versions when they started supporting some kind of flow off-loading. I am unsure if at the moment the recent OpenWRT WiFi performance of this router is on par with the vendor firmware's WiFi performance. But yes, your point is valid. However, I do not consider this kind of issues to be deal-breaking. If I remember correctly, a fair amount of devices can achieve the same performance with OpenWRT as with vendor firmware. I would just check for these potential issues in advance and buy only the devices which are confirmed to be working as fast as with the vendor firmware. The point here is that I rarely have any preferences as to which brand of a router to buy. Many of the marketed features they offer, like proprietary software or mobile apps to control the router, are mostly irrelevant for me. So I choose primarily based on the OpenWRT support level. Edit: clarification | |
| ▲ | rubatuga 3 days ago | parent | prev [-] | | 160mhz ax 6ghz working here with a mediatek chipset |
|
|
|
| ▲ | 3 days ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | echelon 3 days ago | parent | prev [-] |
| Can we accept a pragmatic world where we have OSS + binary blobs? That's better than a fully commercial world or a fully "pure" world with no functionality. |
| |
| ▲ | haukem 3 days ago | parent | next [-] | | OpenWrt accepts binary only firmware running outside of the Linux kernel address space on the wifi chip itself. This matches what upstream Linux also accepts. This works well with most recent Wifi drivers. OpenWrt does not accapt binary only kernel modules or binary only userspace applications, they are very hard to maintain if you do not have the source code. This works well with Mediatek and also Qualcomm and most other vendors. | |
| ▲ | wtallis 3 days ago | parent | prev | next [-] | | GPU vendors have come to the realization that the in-kernel driver needs to be open-source, but the userspace portion can be closed-source. There's just really no good reason to accept a design where outdated closed-source drivers could keep you from running a current kernel. WiFi NIC vendors have for generations been moving more complexity into the closed-source firmware blob that runs on the NIC's own processor core(s), so there's no good reason for the kernel driver to remain closed-source. | | |
| ▲ | zokier 3 days ago | parent [-] | | Broadcom has been doing FullMAC designs for over a decade now, and that is exactly what you describe: moving all the functionality into firmware and having thin opensource kernel driver |
| |
| ▲ | mifydev 3 days ago | parent | prev | next [-] | | I would love that, but it seems like they are not doing that either | |
| ▲ | trelane 3 days ago | parent | prev | next [-] | | > That's better than a fully commercial world or a fully "pure" world with no functionality. I would prefer a fully open world with full functionality. | |
| ▲ | opan 3 days ago | parent | prev [-] | | Give them an inch and they'll take a mile. Things would be even worse if people didn't care about blobs. |
|
