Why are there widespread WiFi performance issues with LEDE?


#1

Great work with LEDe with what can see so far. Looking forward to trying LEDE soon.

Have used Tomato forever but with Toastman and Shibby giving up on the project Tomato routers still have DNSMasq vulnerabilities and KRACK will never be patched server side among other things.

In looking into LEDE see that although as a router the firmware is great the WiFi performance of LEDE is fairly problematic. For example on the LEDE Asus RT-N66U page the comments state that: “2.4GHz is very weak, 5GHz is unrecognized”

What is the reason for the poor WiFi performance with LEDE? Is a particular driver used by LEDE what causes the issues?

Secondly is LEDE still separate from OpenWRT, remember reading that there was going to possibly be a re-merger.

And finally do LEDE builds come with the Luci GUI by default now? Love SSH but for a router it much easier to configure it through a browser when most do not have an SSH client on their Windows computer and a browser is quicker than downloading a client like PuTTY.


#2

Reason: Broadcom Wifi.

https://forum.lede-project.org/t/announcing-the-openwrt-lede-merge/10217?u=tmomas

All release builds come with LuCI, snapshots without.


#3

There are no “widespread WiFi performance issues with LEDE”, however Broadcom wireless cards (softmac based ones in particular) are lacking wlan driver support for linux.

  • the old proprietary broadcom-wl stuff only covers very old chipsets (of the early n-phy/ BCM432x vintage); don’t expect this to have security support.
  • brcmsmac exclusively covers (BCM4313, BCM43224 and BCM43225), which are not commonly used in routers - and most probably haven’t gotten much testing in this direction.
  • brcmfmac only covers fullmac designs, which are less commonly used in routers; the few routers supported by LEDE shipping these wlan chipsets (e.g. Netgear r8000) tend to work - but their relative rarity doesn’t exactly improve their state of support.
  • and while b43 is pretty good and feature complete for the old (pre lp-phy/ pre n-phy) 802.11b/g cards (e.g. BCM4306/3, BCM4320, BCM4318, BCM4311), the painful reverse engineering efforts have stalled around the time Broadcom released lp-phy and n-phy devices, with active development having ceased shortly after. Only extremely basic support exists for the more current chipsets (no HT support, so they’re limited to 54 MBit/s operations at best).

The general support state for b43 is listed as “Odd Fixes”, so don’t expect tangible improvements there. While it might help you get by on notebooks (on a client devices 54 MBit/s might be ‘good enough’, if the alternative would be 0 MBit/s or messing with USB), it’s not sufficient for using contemporary chipsets in AP mode (due to the lack of HT mode, DFS and limited 5 GHz support alone).

Broadcom themselves only seems to provide linux support for their fullmac chipsets (many of which have been sold to Cypress recently), probably thanks to android and regdom questions handled mostly in firmware there. While they have thrown the brcmsmac code dump over the fence and killed b43 that way, this softmac driver hasn’t gotten any continued support from Broadcom ever since and accordingly doesn’t support any contemporary devices.

Some third party firmware projects do have commercial contracts with Broadcom to gain access to their proprietary drivers (which are used by large router manufacturers) under NDA, but these drivers are neither compatible with more current kernels nor available to the public (or LEDE). As a consequence these projects tend to focus primarily on Broadcom chipsets and are often stuck on relatively ancient vendor kernels, with little hope to update or fix issues like KRACK.

Contrary to Broadcom, basically all other wireless vendors do provide linux drivers of varying quality (e.g. Qualcomm-Atheros, (Intel, not used in or suitable for routers or access points), Marvell and MediaTek; while Realtek generally does provide FOSS vendor drivers, they are only at the start of actually maintaining them mainline - these are usually not suited for router uses yet). Routers using these chipsets tend to have pretty good wlan support on LEDE, they might not always meet quite the performance of their proprietary SDK drivers, but support is generally pretty decent and painless.

If you buy broadcom (softmac based ones in particular) wireless hardware, you basically restrict yourself to using the vendor software or one of the few semi-commercial 3rd party projects with access to proprietary drivers from Broadcom under NDA, respectively those who hack up leaked/ ancient proprietary vendor kernels under questionable licensing terms.

If you want to use LEDE or OpenWrt, you need to check the support state of your preferred device before hitting the ‘buy’ button. In return you tend to get a device with decent wlan support and no ties to a specific and old vendor kernel, a device that usually can be kept updated for many years to come (as long as flash- and RAM size are sufficient and the devices remain popular enough to gain continued attention). There are plenty of these devices supported by LEDE/ OpenWrt matching varying budgetary constraints or use cases.


#4

Great post. Unfortunately am not buying anything. Sticking with RT-N66U’s at home and offices until they fall apart which guess means likely sticky with Tomato and Entware-ng if want to utilize WiFi. Next generation of routers will be sure to pick one’s that do not have Broadcom WiFi hardware.