Is Open Source Wifi Perfomance Bad?

In 2015 I bought an Asus RT-AC56U. Although it wasn't OpenWrt compatible, it was supported by Tomato (and even now FreshTomato) so turned out to be a pretty versatile bit of kit. I didn't know any better as I didn't need anything else and this just worked.

In 2020 I thought it was time to move on. Given the strong but waning support for a five year old router, I resolved to get something that supported OpenWrt, and was lucky to get a GL.iNet GL-B1300 for a decent price and immediately enjoyed the benefits of moving to a more modern and supported router firmware. The only downside was that the wifi sucked - this was not a surprise since the unit was so small etc. I sucked it up and kept the Asus as a dumb AP and am overall satisfied by having the best of both worlds.

Forward to 2023 and I found myself in possession of a Linksys WHW03 v2, and was pleased to see that an OpenWrt build for it is well on its way. Flashing the latest snapshot gave me a pretty decent router that I hope to move on to soon. Except... the wifi isn't as good as with the Asus. It's a sight better than the B1300, but still a few grades below what I apparently have been taking for granted for the past 8 years. It's probably good enough for me to finally retire the Asus and unify my router and AP... but I'm still sad at taking the step backward.

Which leads me to my question: is open source wifi performance inevitably so... underwhelming? Or have I just picked bad routers? I do notice that both the above OpenWrt routers use the same Soc family. I am cheap, but then so was the Asus and that didn't feel like a skimp. Was I just lucky to have lived with an overperforming bit of kit?

I'm looking at wifi6 now, and although routers like the Dynalink DL-WRX36 are said to be great, I have no idea if my expectations and experience match those of the community.

I understand that wifi is magical and depends on "factors" but is there a standard benchmark or scorecard that allows one to compare the wifi performance of OpenWrt routers? Or should I just accept it will never happen and stick to dumb APs that are known to be great?

September 2022:

I quote:

athXX and mt7xxx and others
Firmware regularly regresses stable kernels
Firmware regularly just crashes for things like
WPA3, 5Ghz, if you look at them the wrong way

Yes, Linux support could be better. Yes it depends on the device. There are some good ones out there and there are some that could be better. I guess you were unlucky. I would suggest to check the forum for real world experiences with supported devices and look at measurements, before procuring them, unless you feel like taking a bet.

If you look at the toh for ax devices, which (at least for now) depicts many of the devices, which receive lots of support by manufacturers, you can see all their wifi radios are from two chipset vendors: Mediatek and Qualcomm. Naturally i would expect older devices, which were supported by these two to have received decent support, but I also hear that vendors often use specific proprietary measures in their OEM software to make their devices more efficient.

Many other manufacturers also upstream support to the Linux kernel (with limited features, as you should come to understand if you have had a look at the presentation), instead of also directly to OpenWrt (Upstreaming into the kernel is the right thing to do, because everything that is in the kernel can be backported to multiple downstream distributions. OpenWrt is such a downstream distribution), so there is a timewindow until some of these devices become available here, and since this can take a little while (months/years), OpenWrt developers and users that open pull-requests may instead decide to work on, support and improve devices that are compatible with OpenWrt's current linux kernel.

Take the chipset vendor Realtek for example: For 802.11ac usb devices, they publish out of kernel drivers. Those are not completely compatible with the Linux kernel. The community has started to fix, adapt and upstream some of these drivers to the Linux kernel (rtw88, rtw89) and once OpenWrt will move to kernel 6.1 or something, there is the option for them to become supported here in OpenWrt. Most architectures in the OpenWrt snapshots are currently using kernel 5.15. Here, currently, the community singlehandedly drives the effort to support devices in a future OpenWrt version.

As far as I can see, Mediatek is doing it differently: Their employees upstream lots of their code into the Linux kernel, while at the same time, if you follow mt76 driver development, you will notice that some of their employees support OpenWrt directly by following community issues. Many of their patches are backported and changes are committed to various OpenWrt related repositories directly. Here, both the community and company employees support OpenWrt.

Theoretically, open source does not make wifi bad. If the code works, it works. Open sourced or closed source, the code may be the same. What makes wifi bad is lacking support. If there is no support by chipset vendors and manufacturers, there is only so much the community can do. The community will be able to do LESS, if the code is closed source. If Manufacturers decide to only publish old code, parts of their code, then open source code may not outperform their OEM software.

Your devices were supported by Qualcomm. I personally do not have any experience with their devices, but hear that they have some binary blobs as firmware, so naturally, the community is limited in what it can do.

Anyway. My personal experience is quite good with my mt7915 device (D-Link dap-x1860).

I tend to look at it this way:

  • OEM software provides a specific feature set.
  • Open Source software (OpenWrt) provides a specific feature set.
  • Some/Many of these feature sets overlapp with each other, whereas some do not.

This is, because many OEMs are actually based on OpenWrt (albeit often an older stable versions of it), but they put their own code on top of it or adapt the code. Some features of OpenWrt and fixes will never make it into the OEM (because vendors refrain from updating their drivers/firmware), whereas some features from the OEM will make it into OpenWrt eventually and unfortunately (or fortunately?!), some features may never make it into OpenWrt.

Choose your poison :smiley:


Thank you for the comprehensive response.

For sure this wasn't a complaint against OpenWrt or open source, but more an attempt to understand the barriers wifi and OSS might have.

The reason I mentioned the Asus is because it also runs on Linux - but has closed source wifi drivers. The last time I asked this question, I gathered that the reason the Asus performs so well is because of those closed drivers, although I understood that as breaking features wholesale (for eg Openwrt on the Asus has no 5G), and not poor performance.

Now interestingly with this Linksys, the OpenWrt snapshot seems to perform better than the native firmware. So maybe it is just a lucky dip.

Regarding betting - like I said I'm cheap so tend to look for deals and hope rather than research and get disappointed :wink: . I guess for now I'll stick to the AP route though.

Anecdotally, I had to throw out an AP after converting it to OpenWRT (ath79) because without the closed-source blobs its encryption performance was cut almost in half, making it not worth having. But it was either that or throw it out anyway because the manufacturer had abandoned support for it and was vulnerable to recent exploits.

1 Like

...are a real problem. They are a compromise that....sort of... works. But it adds a black-box layer that is necessarily opaque and that is not good for open source development.

Broadcom was worse - they went the other route and wanted to have closed-source drivers talking to the wi-fi chip directly. This is partially because their wi-fi chips were less capable to begin with - sort of the "winmodem" of the wi-fi world, and releasing their drivers would expose exactly what their hardware is doing and makes it easier to clone.

Mediatek, on the other hand, has a much more capable design. The wi-fi chip itself has an ARM CPU that runs its own little RTOS (which is what the firmware blob is) - this RTOS creates an API layer between the actual RF/WiFi "physical" layer stuff and the outside world. This is good for performance, and for obscuring what the actual hardware side is doing. It's a shame they have to, but we have to be realistic - If they released the source for their firmware, every podunk Chinese clone artist would have replicas out in a heartbeat. Being friendly to open source is one thing. Giving away your engineering R&D is another.

So the blobs are a sort of necessary evil - it's true that the vendors are sometimes uncareful with updates to them. But keep in mind, we are to blame for some of that. We don't have to push bleeding-edge firmwares out as soon as they arrive. It's our rapid development cycle and the "get it out and see what breaks so we can fix it" model we use that is at least equally to blame.

To answer the original question: NO! Open Source WiFi performance is not bad. I have spent a lot of time testing different MediaTek devices and for the most part, they perform better with OpenWrt than with their respective stock.


So what factors do closed sourced blobs affect? The main advantage my Asus has over anything after it is range - it covers a good 5-10 metres more than the Openwrt routers I've tried.

Surely software can't affect that? Why isn't WiFi hardware performance as physically commoditised as, say, ethernet?

Software can affect that. We will never know if OpenWrt would have achieved similar performance, since the Asus was never supported by OpenWrt. You are trying to compare apples with bananas.

Edit: You may want to compare throughput / latency of the Linksys WHW03 v2 running with either OEM or OpenWrt. That should give you a more reliable picture than comparing it with your old Asus.

1 Like

Thanks - it's good to know just how pivotal software can be.

But again, my question isn't "why isn't openwrt good enough" but more if there's structural reasons why closed blobs will likely perform better (at least for the time being). It sounds like there are.

Btw the Asus is in the toh, just with no 5ghz. Which I guess strikingly proves the point.

Is it possible for end users to use closed blobs with openwrt?

There is a big fat warning for your Asus on its device page:

Devices with Broadcom WiFi chipsets have limited OpenWrt supportability (due to limited FLOSS driver availability for Broadcom chips). Consider this when choosing a device to buy, or when deciding to flash OpenWrt on your device because it is listed as supported. See Broadcom WiFi for details.

Once again: Neither closed source, nor open source code may necessarily perform better. It depends on the actual code.

If the code is not published, the community will have a piece of hardware without software. The community than can either choose to a) try to adapt other software to run on that machine, b) to try painstackingly to reverse engineer from closed source binary code or c) to not support this piece of hardware. Options a and b are prone to failure.

Advantages of keeping code closed source are:

  • keeps "things" secret
  • Can hide vulnerabilities → security through obscurity
  • avoid costs accrued by publishing code (public server infrastructure; upstreaming code)
  • avoid costs accrued by interacting with a community (time; personell)
  • Gain a competitive advantage by hiding research and newest features
  • Have a possibility to add backdoors without anybody knowing
  • Possibly keeps customers in vendor-lockin / technology-lockin
  • company owners retain their power to have explicit control over a fixed team of developers
  • often entails having a dedicated team for customer support → for customers/users this can be great
  • hides potentially planned obsolence: Increase sales by offering new "better" devices by decreasing lifespan of existing devices. Software can be a trigger for obsolence.
  • Eases the enforcement of regulatory frameworks, as users are forced to comply
  • ...

Some of these points are great for the (chipset) vendor but can be very disadvantageous to customers/end-users and may even be illegal under some jurisdictions (planned obsolence; vendor lockin). is a nice read too.

Advantages of open source (and a community that revolves around that code):

  • Bad code can be fixed by anybody.
  • Community involvement
    1. more bugs are reported (and therefore likely to be fixed)
    2. bugs can and are also fixed by non-employees.
    3. Allows the art of "social coding"
  • Open Standards → if companies adhere to these standards, it prevents vendor locking. Open Standards ensure compatibilty across various vendors and devices.
    Advanced (automated) testing software can detect (in-) compatibilities between various hardware and software originating from multiple vendors that the initial (closed source) chipset manufacturer may have failed to include in their tests. Good and lots of testing ensures good code quality, if found bugs are fixed.
  • More innovation, because customers/users/developers that have specific use cases will be able to adapt the code freely
  • Possibly more secure, because more eyes scan the code for vulnerabilities, hence more vulnerabilities are detected, hence hopefully fixed.
  • old hardware can continue to be supported when manufacturers have already given up on support.
  • Allows the "open source as development platform" model: Keep development (mostly?) open source and give paying business customers priority support ticked queues and/or closed source stable versions in addition to that. Non-paying customers can be "beta-testers".
  • Allows businesses to increase their market share by attempting to improve their software quality via community input.
  • Allows businesses to increase their market share by selling devices to customers that prefer open source
  • Allows vendors / chipset manufacturers to find and recruit expert staff by interacting with the community
  • avoids cost by reducing communication upkeep (paradoxically) → "When project activities and conversations are publicly available and searchable, project maintainers are freed from having to repeatedly answer the same questions. Instead, users can search for answers to their questions before they ask the maintainers for guidance."
  • avoids costs by businesses becoming more agile: "Being able to fix someone else's defect helps to resolve blockers in minutes instead of days [months, years or never]"
  • ...

I am sure you will find more reasons for both modes of operandi.

Obviously, both closed and open source code also have disadvantages, which are not be mentioned here. Thus this was just a writeup of the "advantages", not the disadvantages.


That really helpful, thanks.

Are there any examples of off the shelf routers running open sourced sw that managed to surpass their closed versions?

I looked for openwrt install stats but see there are none available (for reasons). It might be handy to see where the mindshare at a point in time.

we have a little bit of statistics on the attendes sysupgrades done.

But of course there you only see which profiles are build/updates most ..

You are welcome.


Please note that the OpenWrt project itself does not endorse any hardware or manufacturer unless there's a public statement

I would first check the table of hardware. If you find something to your liking, i would check that device's forum thread for real world experiences and what other users write about that device. Then you look where you can buy it. (Or you first check what is available in your regional market, then check toh, then forum). It strongly depends on your hardware requirements and what you want to do with the router. You can also create a new forum topic, explain what you look for and maybe somebody can recommend you some great devices that would fit your needs.

Did you set the appropriate country code on your OpenWrt devices? IIRC, the default is a WORK country code which may limit your TX power.

1 Like

Can someone in the forum put this in the Wiki?

This will give a good warning to the newcomers. :slightly_smiling_face:

This can serve as a disclaimer to any newbies, like me, about to experience OpenWRT for the first time.

In summary, don't expect OpenWRT firmware to be perfect. It is far from it.

It is not something you download, flash, and be done with.

It is not a smooth sailing experience. You are bound to experience some rough seas,
because there are some parts bound not to work well or show any improvement compared to the old OEM firmware.

I see OpenWRT firmware as a way to prolong your device's life-span when other manufacturers have stopped giving security updates.

Given that MediaTek employees are more willing to support OpenWRT than Qualcomm employees at this time, do you advise the OpenWRT community to stick with MediaTek-based routers since they seem to be more promising than Qualcomm-based routers?

May I ask which MediaTek AX routers you recommend buying?

It is because of how commoditized Ethernet became that WiFi manufacturers are so careful with their tech. National Semiconductor's 8390 ethernet chip got put into the Novell NE2000 Ethernet card with a well published set of interfaces and functions. It was quickly duplicated and the NE2000 clones saturated the market for a decade. No one makes money off of a design that gets cloned and commoditized. That's why in business the number one consideration is barrier to entry. If there is no barrier to entry for rivals, no one will invest in it any more.

Depends on the architecture. Anything from simply configuration data for DSPs, radios, and other hardware to a full operating system for the CPU that acts as a hypervisor for the device.

I touched on Broadcom - their devices are like the old Winmodem - which are modems that came around that moved the digital signal processing from hardware on the modem to the computer's CPU. The driver on the computer did the actual signal processing for the connection. The modem was basically just a telephone-to-computer audio adapter. Broadcom's chipsets are like that. Their closed-source blobs are actually computer-side drivers that are needed to do actual WiFi signal processing. Broadcom is extremely protective of them because Broadcom's hardware doesn't do all that much, all the magic is in the driver. They don't let anyone touch them without a stiff NDA.

1 Like
  • Linksys E8450 (a.k.a Belkin RT3200)
    Mediatek mt7622 SoC (1.35GHz dual core ARM64), 128MB flash, 512MB RAM, 4T4T 2.4GHz and 4T4R 5GHz radios
    Plusses: SoC is fast enough to route gigabit, newly supports hardware flow offload, and the 5GHz supports Wireless Ethernet Dispatch (WED)
    Drawback: The 2.4 GHz radio is only Wifi 5 and does not support WED, name brand is a bit costlier than more powerful options below

  • Redmi AX6000
    Mediatek Filogic 830 (mt7986) SoC (2GHz four core ARM64), 128MB Flash, 512MB RAM, 4T4R 2.4GHz and 4T4R 5GHz
    Plusses: SoC is very beefy with lots of spare horsepower for other things, both radios are WiFi 6 and support WED
    Drawback: SoC has far more power than the RAM supports while the cost is about 2/3rds of the BPI-R3

  • Banana Pi BPI-R3
    Mediatek Filogic 830 (mt7986) SoC (2GHz four core ARM64), 8GB emmc storage, 2GB RAM, 4T4R 2.4GHz and 4T4R 5GHz, m.2 slot (5G, wi-fi, or SSD), mPCIe (4G-only), SIMM slot, micro SD card slot, 2 x 2.5gbit SFP slots in addition to the standard 5 x 1gbit ethernet ports
    Plusses: Same SoC and plusses as the Redmi AX6000, but also with all the storage space and RAM you need to do other things, very future proof with lots of expansion options
    Drawback: Comes as a kit with a certain amount of assembly to do yourself.

Note: The latter two have a pretty new SoC that hasn't made it into a release version of OpenWrt yet. They are, however, both supported in snapshot and will be in the next release (in a couple months).


Thanks for sharing. :slightly_smiling_face:
I am real noob when you mentioned: WED:

This router caught my attention: Redmi AX6000 (MediaTek SOC based router)

I saw it is supported by OpenWRT firmware under snapshot firmware:

However, since I am not a Linux pro here, the rooting procedure really looks intimidating.
I guess, it is a matter of me...whether I am willing to take the challenge or not.

I wonder is there any teething issue so far encounter using the Redmi AX6000 router with OpenWRT snapshot installed.

It's hard to generalize such a statement. It depends on the device and how much support chipset manufacterers, vendors and the community have invested into a device. It depends on how often you intend to upgrade the device to a newer version of OpenWrt. It depends on what you intend to do with the device. It depends on you understanding how to configure your device with OpenWrt. It depends on not running into a bug, etc.

My personal experience: When I flashed OpenWrt to my D-Link Dap-x1860, it all worked great for its intended use-case: for it to be a wifi repeater. I set it up following OpenWrt documentation with relayd and it's all fine. There are zero problems. Did the device work with OEM firmware as well? Yes it did. Was the OEM less complicated than OpenWrt? Yes! Did OpenWrt offer features that were unattainable with the original OEM? Yes! - For example, original OEM kept 2.4 and the 5 GHz bands on the same SSID. With OpenWrt I am now able to have my wifi on two separate SSID's, which avoids having my client devices (mobile phone) needlessly roaming and jumping between the 2.4/5 GHz bands in a certain distance range, which triggered massive amounts of reconnects and lagg. Original OEM software for this device was unconfigurable and OpenWrt brought a lifetime of quality improvements. Through good configuration, it effectively increased my devices wifi distance operation range. I beg to differ: OpenWrt is NOT just for old devices.

Yes. OpenWrt is not always perfect, but so are OEMs..