[erikarn]

Hi! FreeBSD wifi person here!

* ath(4)'s 11n support is much, much better now. All the AR93xx/AR95xx PCIe devices are supported and STA/AP 11n should work great. * iwn(4)'s 11n is much, much better. It still has some warts, and I'd love some help in chasing them down. * urtwn(4) in -HEAD does 11n now. * rsu(4) in -HEAD does 11n now. * iwm(4) (intel 7260, etc) is getting better every day in freebsd and dragonflybsd. Thanks to another developer for that !I think we're almost ready for starting the 11n bits? once the 11n bits are done and working, we can start on the 11ac bits. * Another developer is working on urtwn/rtwn unification and support for 11ac USB devices from realtek. * I'm working on an ath10k port from Linux to FreeBSD - I have association working now and I'm about to start on normal data TX. Once that's done, I'll get crypto and 11n station mode operation working.

now, where's 11ac? It's mostly waiting for some stable like 11ac devices to appear in the tree with 11n support. 11ac is partially revolution and partially evolution - if 11n doesn't work, 11ac definitely won't work. So, between iwm 11n work, the rtwn/urtwn 11n/11ac USB work going on and my ath10k work, I think we're heading in the right direction.

I'm hoping that once I get ath10k up in monitor, STA and AP mode, with crypto, QoS and 11n working, the 11ac bits will be trivial - at which point I can start on the 11ac stack pieces. I know what those stack pieces are and I've started writing them down - https://wiki.freebsd.org/WiFi/80211ac .

All of this is non-commercial btw - no-one is sponsoring any work on BSD wireless at the present moment. If you'd like to help or contribute, please consider talking and donating to the FreeBSD foundation, or consider funding someone to help in these efforts.

Thanks!

[e-mail]

[crudbug]

Thanks Adrian. I am not a device drivers person. But, quick query - do you reuse the current Linux drivers work [0].

Looking at the current client device deployment, Intel owns around 80% of the Wi-Fi modem market. Is anybody from Intel working on BSD wireless drivers as well.

[0] https://wireless.wiki.kernel.org/en/users/Drivers

[kev009]

There is reuse, for example iwm(4) is based on the Linux driver and pulls from it. But the process is manual, not like the Linux-KPI graphics and OFED stuff.

It would be great if Intel stepped up to the plate and helped.

[crudbug]

I was thinking about a common driver interface similar to POSIX standard would solve the problem of multiple OS device support on a single hardware platform.

There was an effort for Uniform Driver Interface (UDI)[0], looks like it is dormant.

[0] http://wiki.osdev.org/Uniform_Driver_Interface

[kev009]

People will probably wrinkle their forehead :) but NDIS is that and a lot of operating systems support it https://www.freebsd.org/cgi/man.cgi?query=ndis&sektion=4&man...

[loeg]

> Is anybody from Intel working on BSD wireless drivers as well?

No.

[gonzo]

Hey Adrian,

thanks for the shout-out in the release notes. And thanks for all you do for FreeBSD.

[doozy]

> Chipsets I won't be working on: USB chipsets, in particular the AR7010+AR9280, AR9271 or the AR9170 chipset

Any plans to support these in the future?

[erikarn]

maaaaaaaybe.

[drvdevd]

Thank you for your efforts! This is great. I personally don't know a ton about wireless but am not opposed to digging in and contributing or testing when/if I have time/hardware. Which leads me to a question: what about 11ac is revolutionary if it's just a few bits away from a completed 11n codebase? Just curious.

[erikarn]

11ac adds to 11n. you have new channel widths, instead of just 20 and 40. It's 20, 40, 80, 80+80, 160.

You have MCS0->9, and then you have 1->n spatial streams. It's like 11n, but they didn't make the MCS numbers just keep going up above MCS15, MCS23, etc. Negotiation is easier - you have to do MCS0..7, then you can say whether you also do 8 and 9.

Everything is block-acked when you negotatiate it - even individual frames. It still negotiates AMPDU and AMSDU like 11n, but then everything is BA'ed versus 11n where some frames are and some frames aren't. The 11ac AMPDU is almost the same as 11n, but it adjusts the maximum AMPDU sizes to be much bigger.

It's still MIMO, and you can implement multi-user MIMO when you're ready. You don't have to out of the gate. This makes it easier to do basic 11ac bringup before you have to do more useful optional bits. There are some extra IEs to handle in beacons, probe request/resp, etc, which isn't all that scary.

The trouble(!) is it kinda forces one to tidy up their 11n codebase first. The way we represent channels in net80211, for example. We have one channel for each PHY type and frequency - so, say channel 36. There's 36/a, 36/ht20, 36/ht40. For 1, it's 1/b, 1/g, 1/ht20, 1/ht40. For 11ac we're going to have to add say, 36/vht20, 36/vht40, 36/vht80. Now, 80+80 becomes painful because the other 80MHz slice can be anywhere and that's not easily represented without a massive explosion in the number of channels. So, how channels are fetched/accessed/etc needs to be changed.

There's also the situation where we currently support a "global" channel for a device, rather than one channel per vap, separate scanning state per VAP for full offload devices, etc. That has to change for full offload devices (iwn, iwm, ath10k, rsu, etc) which can do scans in firmware without the stack being involved.

Linux mac80211/cfg80211 solved this with the concept of "channel contexts" - they used to do exactly what we did in net80211 (one channel struct entry per PHY type + channel combo) but fixed it when 11ac came along. Every driver needed modification, so that's going to take some time to plan out and implement.

There's also some tidying up to do with notifying the upper layers about frames. Eg - NICs does AMSDU offload now in the 11ac world. AMSDU is multiple MSDUs in one frame - ie, multiple ethernet frames in a single 802.11 frame. So, you have to tag received frames with some information that states it's a de-cap'ed AMSDU frame with the sequence number, crypto info, etc of the single big 802.11 frame you received. This is problematic because the stack right now expects each frame to have its own sequence number, crypto IV, etc and does duplication detection. I just started committing some newer pieces to the net80211 RX path so we can handle cases like this when AMSDU offload happens - which is very soon now.

So yeah, it's "a few bits away", but since the four of us actively doing wifi stuff in FreeBSD are unpaid volunteers, things happen at the rate of spare time. If you're interested in learning about this stuff and aren't afraid of a C compiler than hit me up ([e-mail]) and let's hack on this.