I know there's effort ongoing, and I'm sure it's a tired question at this point, but I have to ask: what is the deal with (the lack of) 802.11ac wifi in FreeBSD?
FreeBSD isn't really the most suitable choice for a laptop, which should be the only place you need to deal with wi-fi (and I say this as someone that's been using FreeBSD on the desktop and on servers for longer than I care to remember).
Anyway, if you read the release notes this release uses the new/recent linux KPI infrastructure to use the Linux wi-fi drivers and stack via a shim, so presumably this will take care of all your kernel-resident problems (userland support is still a question mark)! See man pages below:
> The iwlwifi(4) driver along with a LinuxKPI 802.11 compatibility layer was added to supplement iwm(4) for newer Intel Wireless chipsets. (Sponsored by The FreeBSD Foundation)
I did read the release notes, but I nonetheless appreciate you re-highlighting that bit.
>FreeBSD isn't really the most suitable choice for a laptop, which should be the only place you need to deal with wi-fi
I don't find this attitude towards the situation productive. It's reasonable to want to have modern wifi speeds in 2022, and being dismissive of this when FreeBSD does in fact have support for running as a desktop OS is just odd to me.
That all said, I'm just gonna take the L and acknowledge that my comment on FreeBSD/802.11ac was badly constructed. If I could go back in time, I'd probably re-word it to be: what needs to happen to speed up 802.11ac support in FreeBSD? Is it simply a money thing to get the right people on it with fewer distractions? Is it testing infrastructure?
I guess I could have phrased that part of my answer in a more directly applicable manner: if the majority of FreeBSD users are on desktop/servers and specifically not on mobile, then the majority of dev attention is also going to be focused in a similar fashion. The shortage for a project of this magnitude and nature isn't going to be lack of hardware, it's going to be lack of time and the opportunity cost for the few that could hack on this to stop hacking away on something else.
Basically, the incentives don't align because you're using FreeBSD in a way that most users/devs aren't. That's not to say that you're in the wrong (not one bit, in fact, you should be commended for your dedication) but just to highlight that there's a fundamental impedance mismatch between the needs of laptop FreeBSD users and the overall priorities of the community. It took an insane amount of time and effort to get Linux KPI going for graphics card support (something that affected both laptop and desktop users), you can infer from that the odds of getting something only for laptop use to become a priority.
That said, you should also look at the current release log as an indication of things to come. The effort to get Linux KPI going is very much a step in the right direction: whatever time/money/effort was going into porting or writing new drivers for wi-fi hardware can now be spent on doing things like improving the crypto and/or protocol support to get things like WPA3 and WiFi 6 going.
But the reason I highlighted the above section of the release notes is strictly because the bulk of the work to get 802.11ac support is purely in writing the drivers since it doesn't fundamentally change the requirements in the rest of the stack (no new crypto required, etc) so I don't see how highlighting that isn't already an answer to your question.
I meant to respond to you yesterday. Though I think we're going to disagree somewhat, I do appreciate the thoughtful responses.
>Basically, the incentives don't align because you're using FreeBSD in a way that most users/devs aren't.
I view this as a chicken/egg issue at this point - there is no reason to use FreeBSD on a laptop (and push/fix the other issues) without modern wifi. This also handicaps more than just laptops - e.g, the Raspberry Pi.
>It took an insane amount of time and effort to get Linux KPI going for graphics card support (something that affected both laptop and desktop users), you can infer from that the odds of getting something only for laptop use to become a priority.
I'm definitely aware of this - the mismatched incentives are why I asked in my last comment if this is just a funding/money issue. I recall that the FreeBSD Foundation has done funding work around wifi updates, but if that's not enough I'd like to know.
e.g
>The shortage for a project of this magnitude and nature isn't going to be lack of hardware, it's going to be lack of time and the opportunity cost for the few that could hack on this to stop hacking away on something else.
When I ask if it's a money issue, I'm not asking if they need money to buy hardware - I'm asking if there's sufficient funding for software engineering time.
Anyway, I've enjoyed the back and forth - here's hoping FreeBSD gets it eventually. I still love the OS to this day, but when it falls behind on stuff like this it can be rough.
I forgot about the RPi train - good point. Fwiw, I hope this gets fixed too, and quickly. Unlike the other commenter, I don't think there's anything wrong with asking for updates all the time and hopefully this will get the attention it needs. Cheers, friend!
I'm not sure that wifi = laptop. FreeBSD is an appealing choice as a firewall for example. I can imagine standardizing on FreeBSD across my networking devices and creating some kind of wifi AP using FreeBSD.
I've been running a FreeBSD-based network at home, at work, and at several other sites - one with hundreds of APs. The software infrastructure isn't (even remotely) there to run the entire WiFi backend off of FreeBSD and lack of 802.11ac or WiFi 6 isn't the biggest problem; the right solution is to deploy separate WiFi infra (sans any dhcp/routing/firewall/etc) hanging off the FreeBSD-powered LAN.
> the right solution is to deploy separate WiFi infra (sans any dhcp/routing/firewall/etc) hanging off the FreeBSD-powered LAN
Just came to say, this is exactly what I do. Firewall/router/dhcp/etc is FreeBSD and it’s great, but for wifi I use purpose built commercial grade hardware at home (Aruba personally, but honestly Ubiquiti, Meraki, Ruckus, etc would all be comparable).
