Can open source drivers ever be as good as proprietary ones?

Oh, not all of them, only the ones who truly care about security. WPA3 Personal is the only PSK protocol which enables perfect forward secrecy.

Hi is that the one that does not work with most devices, or most routers? yeah I thought so.

That's sidestepping the point. @Regokog asked if an open device driver could have as many features as the manufacturer's closed driver. I'm arguing an open driver could be more featured than a closed one. I mentioned b43 as an example, as far as WPA3 is concerned, but there are others (say, rt2800{pci,usb}).
Anyway, I'll bite. Nothing stops you from having a WPA2/WPA3 mixed-mode network. Even better, create two separate networks, one for WPA2 and another for WPA3.

The only reason it doesn't support WPA3 is that it was manufactured 15 years ago. If it was made today, it would.
I'm glad that rt2800 supports WPA3, but, as I mentioned in my previous post for example, it doesn't support repeater mode on MT7620 chips. Who needs WPA3 if you can have the best security on the planet - a dead network.
Not to mention the repeater functionality in OpenWRT is more of a hack than a feature if you look at the way it's implemented, but that's different story, as it's poor implementation can't be blamed on hardware manufacturers.

isn't WPA3-SAE already broken?
https://wpa3.mathyvanhoef.com/

The Q&A section at the bottom of that very same page answers your question. :wink:

Two things:
a) using feature count as quality measure has issues
b) part of the problem with the proprietary driver development is that is typically is financed by selling chips so development tends to cease once the chips are EOLd.

As an example in Linux ath9k and ath10k have gained airtime fairness features relatively late in their life time, not clear whether proprietary drivers at that part of the cycle would have supported that or whether qualcomm would have restricted that to ath11K (as new features are a great way to sell newer chips).

That is not to say that opensource drivers are perfect and without issues, just that IMHO it is far from clear whether proprietary drivers actually excell in all quality measures.

3 Likes

Exactly. The perfect way for manufacturers to plausibly deny planned obsolescence.

I am not even trying to blame companies for operating that way. If there is no revenue generated and no other utility for the company it is simply economically irrational to keep investing and hence companies from a given size on will be steered by the bean-counters to stop investing the time & effort. It would be nice if companies at least would open up decent documentation for retired chips so that opensource developers could take over, but even that is wishful thinking since it runs counter to current economics ideas about intellectual property.

2 Likes

Having written several device drivers for "ancient" hardware in my youth, I can say, that this was different in the past, although the OS itself was "Closed Source". OK, not 100%, the KGB got the sources, at least :-). There were even (printed) docs, how to write device drivers, and there were detailed docs regarding the interfaces of the vendors hardware, i.g. Device Registers and Status Registers.

1 Like

+1; I blame this partly on the MBA-ization of all industries. Looking at everything under a predominantly revenue-focussed spotlight can lead to the observed change in behavior. From the perspective of someone living from selling new chips giving older already deployed chips a new/longer lease on life seems counter-productive...

1 Like

Maybe if "right to repair" legislation forced the manufacturers to release the complete specifications and development documentation for their chips… but that's probably wishful thinking.

3 Likes

+1; rules and regulations are basically the only thing the will stop the MBA mentality in their tracks. See the concerted efforts by businesses worldwide to reduce/remove laws and regulations. IMHO a right to repair is obviously a thing that overall will be good to society (as it will allow to longer use existing resources) and hence will come into play sooner or later, even though it seems opposite to short-term interests of some important players (who will come around following it, after it becomes effective law).

3 Likes

What I really need from a wifi network is stability and reliability. Even speed isn't very important to me. Airtime fairness, WPA3 and all that stuff is nice, but it doesn't matter if my network can't be configured properly or an AP randomly stops responding. And in this regard it's pretty clear which drivers excel.

Can't speak about your experience, but I had very little (aka zero) unfixable issues with ath9k under OpenWrt. That is, I ran into some power saving issues that made the connection to stations drop under some repeatable circumstances, but managed to help the developers find and fix the bug (by doing extensive testing leg work). Not sure how/if proprietary drivers would have been any better here and if proprietary developers would have spend as much time with a single end-user to debug the issue?
That is not denigrate your experience with a different chipset, and it also does not say that others will have zeros issues with ath9K, but it puts some perspective to the claim proprietary is always "better".
I remember that I only got into this whole run your own OpenWrt on a router because my mac laptop did not get reliable wifi connections with a cheap netgear router (IIRC) with the proprietary software... Not exactly sure who was to blame Netgear, or Apple, but switching to OpenWrt based CeroWrt at the time (on different netgear hardware) made that issue go away. Again that is just a single anecdote, but it illustrates that this is a messy issue with no simple rules like X always better than Y or vice versa, no?

3 Likes

Take a look at MikroTik.com

They e.g. use IPQ4018, but MikroTik doesn´t pay for the vendor´s driver. Their developer don´t use the IPQ4018 or 802.11 linux kernel module. They write everything one their own.
The result:

  • No MU-MIMO
  • No airtime fairness
  • No 802.11k
  • No 802.11r
  • No 802.11v
  • No ...
2 Likes

I guess Mikrotik driver can handle lots of clients under pressure unlike OpenWRT which most likely will run oom on a hAP ac2/cAP ac, speeds surely will be miserable since they're already worse than OpenWRT with a low amount of clients.

Pretty much every user's experience is anecdotal, since most people don't have dozens of routers setup for continous testing at home, therefore from a statistical standpoint it's hard to draw any conclusions. However, we have to work with what we've got.
Out of every router I've tested (and there weren't many of them, ~15 at most) on stock firmware I had issues with two and they clearly were'nt caused by wifi drivers. One of them had the worst firmware I've ever seen and the other had OOM issues due to 16 MB RAM.
When it comes to OpenWRT I've used ath10k (2,4 GHz only AP worked pretty well, had to replace it due to 4/32), rt2800 (I think, this one is confusing; the chip is MT7620, but it's not managed by mt76, so it's rt2800 or rt2x00, not sure - this one I can't setup as a repeater) and mt76 (5 GHz - issues like radio becoming inactive, couldn't change channel, packet loss and ping spikes).
That's 2 out of 3 misses - doesn't make me optimistic. I will pick up an ath9k device in the coming days to see how it works.

@hmpfe
Mikrotik is a weird one. In general, if you're interested in router firmware, you have a dilemma - new kernel + open source iffy drivers or old kernel + solid closed source drivers. And then Mikrotik comes along and offers you old kernel + iffy closed source drivers :wink: Of course consumer routers aren't really their focus (although they're moving more in that direction).

The latest 7.1beta2 firmware uses 5.6 kernel + their sh**** wifi driver

Off course that they use drivers provided by Qualcomm, its not like they write them.
They only do minor customisations so that drivers understand their regulatory databases and caldata compression.

Other features dont have anything to do with the driver, but with the AP daemon that doesnt support them.

2 Likes