This talk is all me and nothing to do with anyone who currently pays me any money. So what's been happening? I'll go through a bunch of different things, so this is just the only thing. I spent some time dumping some documentation into the wiki because we are sorely lacking

802.11 documentation. I would like some help documenting things from a user perspective. I'm quite happy to document how net 802.11 works and what the features are, but things like tutorials and whatnot, I would like to come up with. I've also started documenting the Ethereum and the HAL driver.

Due to popular demand, I've listed all the hardware that's currently supported and there's a long list of it, and based on the existing driver and nothing to do with the actual internal data sheets, I've been documenting what the hardware does. There are plenty of questions from people about how the Ethereum hardware works. So I've been going through the driver and the HAL and reverse writing documentation based

on that. The plus from doing it this way is all the arrival that's not in any data sheets gets covered by what I'm dumping into the wiki pages. So there's only a few things there at the moment to do with calibration. As I find spare time, I'm doing that.

We've done a bunch of work in net 802.11. So Bernard and I upgraded the 802.11n negotiation code from an early draft up to what the specification was. It wasn't all that much work, but that goes to show how long our 11n code sat there doing nothing. I went through and found a bunch of weird blocking issues that I went and fixed, went

and updated some of the 11n stuff, including channel width change and aggregation. We've got a new committer who's been working on updating 802.11s mesh support from the earlier drafts work that Rui did up to what's actually made it in 802.11.2012. He's also worked on a wifi simulator, which he uses to test this out.

So he doesn't need to use real hardware to do protocol updates. And I've been working on radar station and access point radar support. So FreeBSD 9, I think, should correctly support being told by the access point. In station mode, we'll correctly support being told by an access point, change channel,

and then correctly handle all the weird corner cases that occur there, such as you change to a DFS. It tells you to change to a channel, which also runs DFS. And so the access point has to stay quiet for a minute. The corner case there was, if it doesn't hear an initial beacon, it never actually

determines that there's nothing on the channel. And it sits there patiently for a minute, waiting to hear the first beacon so it knows when the next beacons should arrive. So now it will correctly go to that channel, determine there's no access point there, and start roaming for a new access point with the same SSID. Bernard's been taking care of the Intel 11n driver support, and so he now supports

11n on all the current generation of Intel NICs that he can get his hands on. And he's actively been fighting and fixing 11n issues. So if you've got an IWN NIC in 9 or head, you can use 11n right now. You don't need to wait. B-E-W-N and B-W-I need a maintainer. We've done some bug fixes, but unfortunately, I'm not allowed to touch it anymore.

It comes with working for Ethereum. The Marvel driver also works great if you disable TX aggregation, and I'm looking into this for some interoperability testing. But again, it would be nice if there was a maintainer. I can't sit there and look after the Marvel driver anymore. And Bernard and Ray have been working on RA-Link hardware based on the

open BSD code. The plan here is to bring up the basic NIC support from open BSD, and then contribute back whatever we find was broken, and then fix up the 11n support, which is a lot trickier than you think. My main focus has been on the Ethereum driver. So I was sponsored for six months of last year to finish off TX and RX aggregation handling.

And when I dove into that pit of hilarity, I discovered all kinds of corner cases that just weren't being handled. So all of the TX and RX aggregation, and pause and resume, and software re-transmit and bar handling, both transmission and reception, channel width change support, all of that is supported now in head.

I've updated, I've imported the 9287 support from the Theros reference code base, and I fixed up the Merlin and Kite support, the 9280 and 9285 support, again from the Theros code base. So all of those chips, everything up to 9287 is now working and stable. As far as I can tell, and I've done some pretty in-depth noise testing there,

and all the users of those chips now report pretty much no bugs that couldn't be traced back to a really noisy wireless environment. Or they forgot to connect an antenna, one of those two. Another source of issues with the chipset support were radio and baseband calibration fixes.

I ended up helping the Linux Ath9K developers find and fix a bunch of these corner cases as well. So we ended up sort of talking to each other and fixing each other's bugs as well. So that was an example of Linux and VSD cross-development that actually worked quite well. When I fix something, he fixes it and vice versa.

In terms of driver support, there were lots and lots of weird corner cases to do with concurrency, as in having net80211 request a channel change or a reset or having a stuck beacon or a baseband hang, do a reset whilst another thread was doing TX or RX. And when you reset the chip in the middle of doing TX or RX,

the DMA engine has a habit of just writing random crap everywhere. This is a bad idea. That was fixed. For 11n, you can't drop frames. So the standard wireless driver, non-11n aggregation, if you drop a few frames and there are holes in your sequence numbers, it's fine. As long as the sequence number's progressing, everything's okay.

But what happens with 11n and TX and RX aggregation is if you miss frames and you just increase your sequence number, it's like TCP. There's a window of frames where you have to fill that window before you can continue along and software retransmission handles all the out of order stuff. It will transmit your frames out of order and it's up to the stack to reassemble them in order

and pass them up in order. If you just drop frames during a reset, then that particular window tracking stops working. So a lot of the reset-related things that just simply stopped the chip, dumped everything that was in the TX and RX queues away and then continued, that all needed to be addressed.

Again, corner cases there needed to happen. And the rate control code has been extended to support 11n enough for me to be able to use 11n. The rate control code is pretty modular. If someone wanted to port the rate control code from Linux and wanted to write their own 11n rate control code, please do. I would love it if someone took that over.

There's plenty of interesting things you can do there. But again, 11n works fine for me. That's all that matters. So what's missing for 11n? Well, the 802.11 does a pretty good job now. The only thing it doesn't really do is power saving and I'll cover that in a minute. So all of the 11n negotiation fixes are in 9, but we haven't backported them all to 8.

Some of them is just because we haven't bothered. I've made a point of not backporting anything at all, unless it's a very small driver fix. And some of them, backporting to 8 would break the ABI. I'd like someone else who is focused on 9 or 8 support to pick that project up and run with it.

As long as I'd love to be able to just MFC things, I treat 9 and 8 as snapshots of stuff that either worked or didn't. And then whenever someone gives me a bug report, I say, does it work on 9, does it work on 8? Hopefully, it says it worked on 8. If it worked on 8 and didn't work on 9, I'll go and fix it. But almost all of them have been something along the lines of it didn't work in 9 and it works in head.

I basically use them as a comparison point. IWN just works. And it works in 9, but it actually backports stuff. So people who are using IWN on 9, it should just work 11n and otherwise. Someone popped up to say that he's having crashes in 9 stable and I've asked him very nicely to report them to the FreeBSD wireless list.

So, yeah, if you want 11n right now, IWN will do perfectly fine. The Marvel driver works again, but there's some weird situation with setting up TX aggregation. So if you disable that in head, everything works fine. I actually get 60, 70 megabits of received throughput on the supported Marvel NICs with 11n.

The Ethereum stuff works extremely well in head only. And I can get up to 150 meg, like unidirectional TCP and 280 meg unidirectional UDP using Ethereum, the relevant Ethereum NICs. I'm not backporting 11n to 9. As I say that right now, it's somebody else's job. It's a big job, a lot has changed between 9 and head,

and I don't want to be responsible for trying to make 9 work as well. Somebody else wants to, feel free. The only thing that doesn't, the two things that don't work is scan doesn't work because, again, scan simply drops all the traffic in the queues and then changes channel. And so a lot of stack and driver changes are needed to actually queue that traffic, do the scan,

and then resume from where you left off. Or you do the Linux thing, which is you drop all the traffic and then you slide the sequence number along so there are no holes. One of them needs to be done. You don't scan during live traffic for the same reason. So background scan does it when there is no traffic and scan you can request at any point in time.

If you do a scan during live traffic, the same thing happens. Any active in-flight traffic gets dropped, goes off channel, does a scan, comes back, and then your 11n session hangs. And AP's power save mode needs to be fixed, and that's on my short-term to-do list. So the current issues in NetOtor 11 is a lack of sensible locking. So there are just lots and lots and lots of different places

where commands and traffic can happen, and I've listed some of them there. So if you have overlapping TX and RX, it mostly works fine. But if you have overlapping TX and RX and someone comes along and does a channel change, you can have an annoying situation where the driver is basically asked, can you please change the channel whilst you're sending traffic?

And again, weird shit happens. There are also some issues with reentrance where an RX completion will trigger a TX from the IP stack or the TCP stack. So the easiest way to do this is ICMP. Every time it receives an ICMP request,

it's going to send an ICMP echo reply every single time. And so the driver, you can't just simply get around issues by holding locks for long periods of time. The minute you hold a lock over passing a frame back up to the stack, you're going to reenter the stack somehow and you end up with lock recursion and all kinds of dirty crap. There's some issues with handling IEEE 802.11 node structs,

which is the representation of individual stations. The summary here is atomic operations for reference counting don't replace locks. So the basic issue here is, if thread A wants to decrement the reference count, thread B wants to increment it, and thread A manages to decrement it to zero and free it before thread B,

in the middle of the bit of assembly that takes the pointer, copies it to do some local work off the stack and returns it, there's a tiny race condition there, which can actually fire and the reference code will actually increment a zero reference count to one on a node that's been freed. And it doesn't sound like a condition that happens very often,

but what happens with Ioptl, what happens here is the host APD or WPA supplicant will issue an Ioptl, which will trigger off something on a task queue that happens in one thread, and then in its own context will also do something that triggers some kind of a node operation, and they will actually work in parallel every time.

Yeah. Well, the way the code used to work was the reference count was always held, the initial reference count was always held by the list. And nodes, when their reference count reached one, meant that nothing else besides the list held that reference. And so you would say, I don't need the node anymore,

the reference code would hit one, and then it would be garbage collected later on. So even if you had a stale reference, it was still pointing to a valid but going away node. Whereas now, there is no list holding the reference, it can be garbage collected at any time. And that was a change done by Sam a few years ago to fix issues where nodes, in particular the BSS node,

which was what kept the state of the current network, it would create a new node every time it needed to change something about the BSS, some kind of configuration thing. And in a noisy environment, you'd constantly be creating and destroying this BSS node, and you could end up with hundreds of them sitting there waiting for this 30-second garbage collection. So we changed it so it could immediately be freed.

But this is the side effect, is on SMP machines, this particular issue creeps up quite often. So I need to fix that at some point. But yes, you're right, the reference counting is in the wrong place. And the other issue here is with an example of there being no locking.

So this particular function will actually replace the BSS node and remove the reference to it, but there's no locking around that. So if thread A calls this function to update a node, thread B wants to use it to do something like, say, receive a packet for the network, then it can actually end up trying to receive a frame using a node that has just been freed from underneath it.

This is another one of those stupid race conditions. So I need to, as I said, this is the sort of stuff that requires me to actually fix the locking. Drivers have the same problem with concurrency, and I can't hold locks during TX and RX completion. So the way that the Intel driver gets around it is that the lock is held for any operation,

for the entirety of the operation, every operation that the driver locks held, but then he releases it to receive a frame and then locks it again without rechecking that all the state of the node is still valid. So, for example, if you're in the middle of receiving a list of frames and the driver wants to change the channel or do a reset,

then the reset function will stall waiting for the lock to be released. You're in the middle of receiving a frame. So you'll receive the frame, unlock to pass it up the stack, at which point the reset occurs, finishes occurring, and then the RX path continues along, right, instead of the RX path saying, no, you can't reset the driver

until I've finished receiving what was on the RX queue. So we need to fix that. That's a general driver problem. Power saving is a pain in the ass, especially with 11n aggregation, because we need to actually make sure we do legitimately leak one frame at a time whenever the station actually sends a PS poll frame,

and because some frames are in the power saving queue and some frames are in the IFNet queue and some frames are actually being given to the hardware to send before the station went to sleep. I need to make sure that not only do all the frames that we're sending to a station get correctly failed and then put back on a retry list, but we don't try retrying them until either the station wakes up

and sends us a null data frame, or the station sends us a PS poll frame, and then I need to leak them in order. I need to ask the driver, do you have anything in your particular queue that you need to leak? Yes, no, no. Is there anything in the power saving queue that I need to leak to this driver? Yes, no. Otherwise, just wait. And that's a bit of a pain.

But I have a plan. It's basically like two. And I need to plan out some better locking. So people have talked about batching frames in drivers and their network stack instead of having them handled one at a time. So what I'm thinking of doing in net80.11 is instead of just doing the link solution

which is to grab a lock before you do anything in the net80.11 stack, I plan on doing something along the lines of instead of handling a frame one at a time, create an mbuff frame list from the driver of say n frames, say n is 16 frames, inside the lock, and then unlock the driver, pass those frames up to the stack,

and then relock the driver. Check that the state hasn't changed and continue along. So that way, whenever I'm either completing a TX frame or I'm handling an RX frame, I'm not grabbing and releasing a lock every single time I handle a frame, and I'm also doing it outside of any driver locking context. So what I'll pass up to net80.11 will be a list of frames,

and then the other input function will only ever handle one frame at a time, but for now, the nice thing about this is when doing aggregation at n number of tens of thousands of packets a second or doing 11ac where I can get a million frames a second over the air, I'm not having to pass a frame up to the stack and then have it try to figure out whether it needs to be reordered

and held in a reorder queue and then slide the window along. I can pass it 32 frames, and it can operate on that list and see what needs to be reordered in that list. So what am I working on next? Fixing all the crap I just said was broken is the summary of this slide. I'm also going to import the current generation of 11n code from the Ethereum towel rather than from Ath9k.

I had some more permission to do this. I just need to sit down and clean up the code and submit it for the internal stuff. So that probably will appear in the next two or three months when I've got some spare time, and that will get us support up to their current generation and their next generation of 11n products,

but won't support 11ac, which I'll cover in a minute. And I hopefully will find some time to do documentation. What's coming up? All of the BSDs need better regulatory support. It all sucks is the 32nd version, and we're probably not actually regulatory compliant. At least in FreeBSD, our regulatory database is more than a couple of years old

and is missing some new frequencies. I've updated some updates for weather radar holes that you're not supposed to transmit on anymore. That's the sort of stuff that I need to sync. And what I'm hoping I can do is work with the Linux guys that have a regulatory database and find a way to import it into BSD

so that all the BSD projects can simply use this code And the regulatory code that Lewis wrote is actually IC licensed. It's not GPL. We need DFS and radar support in order to actually work as an access point in 5 GHz. At the moment, people will just configure a DFS channel and won't have radar support.

And I've seen people do this by hacking the regulatory domain database so they can get access to the DFS frequencies. This is a no-no, and if anyone notices, you'll get in trouble. And we've had issues of this at work where we've had reports from our commercial customers going into their firmware and selecting debug mode from a commercial product that's not supposed to let you change country code, not that you're supposed to disable radar.

Plenty of network equipment vendors do this. It's a no-no, not because we don't want you to do it, but because the FCC and various European regulatory bodies don't allow you to do this. So all of the BSD projects need to, in my opinion, try and get their act together over this.

The missing part from the Ethereum side is a radar detector, which we're working with Linux, using a company to write an open source one, and then I'm going to lift that verbatim as an IC license thing and drop it into BSD. And there's per-packet and dynamic power control, which is a pain in the ass if you don't have a spectrum analyzer.

But the basic premise here is, instead of configuring your access point to transmit at the highest TX power to every single node, you use low power for nodes that are close to you, you use high power for nodes that are far away from you, so you end up using less power and leaking less RF, especially if you're at home. You don't need to have high TX power

to speak to your laptop that's next to your access point. That's actually another requirement in some channels. We also should look at what we need for 11ac. That's currently going through the standards body at the moment and may appear in the next few months. Broadcom has announced hardware. Theros have announced hardware.

Broadcom have some sample hardware. This is actually happening. It's up to 1.2 gig over the air. There's a million frames a second. It's not wireless really anymore. It's not the same kind of low-speed packet throughput that people expect. It looks a lot more like Ethernet. We'll have the same problems that the Ethernet guys do.

So we can't just simply do naive locking anymore in order to get performance. So we probably want to give that a bit of thought. What BSD is lacking is developers, especially ones that like porting drivers from other operating systems. I've explicitly stated that I'm not going to port any drivers from any other operating systems. I have enough of my own problems

to deal with at the moment. So if someone wants to port the 11 index from, say, OpenBSD or Linux over to FreeBSD, I'm happy to take the code and massage it and test it and comment on it and commit it. But I'm not going to do the legwork. I need help. We also need maintainers for the other drivers. There's a lot of activity in Linux for updated chipset support.

And then OpenBSD simply slurps all of the code in, either if it's IC license, they slurp it in, or if it's not IC license, they re-implement it. So we could, as a project, simply leverage that as well and then push out fixes that we make. If someone cares about the Lucent, Prism, like 11 meg, the old gold and silver PC cards,

please come and speak to me. I know what's wrong with it. I just don't want to fix it. The NICs that are basically looked after, so if you want to use 11n or any other wireless on FreeBSD, is the Theros, the Intel NICs, and the RA-Link NICs. They're the three best supported NICs at the moment.

We're working on regression testing, especially with the software simulator. So now we're using it for doing 11s testing and regression testing. But in the future, we're going to start supporting access point mode and station mode and IVSS mode and TDMA mode so we can actually test the stack's behavior for all of this, for both new development and regression testing existing

stuff. If someone wants to take a rate control and extend it to do proper 11n, be my guest. I'll probably do 11n three and four stream support once I get the current gen of three stream 11n NICs from Theros in the tree. 11n, the three stream NICs go up to 450 megabits.

So again, 300 megabits is not really wireless anymore. 450 megabits is really not really wireless anymore. So there are some significant driver issues to make sure that that performs correctly. And finishing off powers that save support. And the final thing is actually supporting putting the NIC to sleep as a station. So access point mode, the basic access point behavior

is the access point's always on. And there's some support in some products to put part of the access point to sleep in order to save power when you're running it off battery. But by and large, most access points leave the radio and all the antennas on all the time. But for station side power save, you don't just want to be able to,

you want to basically be able to put as much of the chip to sleep and then wake up when you want to hear a beacon and wake up when you want to transmit. And there's all this complicated crap around making sure you don't do things like put the NIC to sleep in the middle of doing a TX or RX DMA. That's the kind of thing that locks up buses. So chances are, when we finish the access point sleep stuff,

Bernard will work on the stack side of station sleep and I'll work on the driver side of station sleep. And that saves significant power, very significant amounts of power. So that's my talk. Does anyone have any questions? So what's the state of ABG card?

Don't turn on 11n unless you know what you're doing. So for ABG card? ABG card works fine. For 11n, you can run, so you can either run 9 with a theros, assuming a theros now, right? So if you run 9 without 11n, it works fine. If you run 9 with 11n, you have to turn off TX aggregation

because that's just not in the tree. But 9's driver still has sleep race issues. It still has reset TX, RX race issues. It still drops frames whenever it resets. So if you have the driver say hit stuck beacon while you're actively doing traffic, it will drop what's in the queue and the AP side of your aggregation session

may hang for a little bit. And at least on our implementation, you can turn on AMPU age, which basically says, I'm going to wait until X number of milliseconds before I just declare that I'm not going to see those frames missing and then flush the queue and continue, right? So it's not as bad as it sounds,

but you definitely will see traffic dips if the thing ever resets. And in head, it doesn't. I have a SysCT all that actually forces a stuck beacon reset, and I can just sit there and while true do, SysControl blur equals one done and pass 250 megabits. And it just hammers, resets the damn NIC and still manages a couple hundred megabits. The resets on AP are fairly rare.

Unless you're in a really, really noisy environment or your microwave hates you, stuff like that. Well, like low-five figures are fine. Yeah. So yeah, as I said, ABG works fine. And I run all my boxes, either the APs run on head and they run fine, and the plenty of people run nine, and head Net 802.11 and AF. And that works fine.

I make sure that works fine. Eight and head Net 802.11 and AF. It doesn't work because the WPA supplicant and host APD were updated, and the APIs to Net 802.11 were updated, so you can't run eight's user land with head's Net 802.11.

That doesn't work. So if you want to go through the effort, and I need to tell the PF sense guys this, if they want 11 in, they can run eight, plus head Net 802.11, plus head AF, plus head WPA supplicant and host APD. And they have to hack the build system to do that, but if they won't do that, it's their fault. It should work fine.

It should work fine if you can put up the IP version. Sorry? It should work fine if you can put up the build version. Trying to keep all those things together is probably a nice thing. No, well, the only thing that changed between eight and head was the multicast queue shit for something, right? And that's like a one line change in Net 802.11 to support the particular multicast change. So I know that you can build the head

at the Net 802.11 wireless drivers in eight as a module, and that works fine. It's the user land you have to recompile. You have to recompile IF config, sorry, as well as Net 802.11 and blah. And IF config is probably the pain in the ass one because head's IF config doesn't compile on anything else. We don't have backwards compatibility if defs, right? But that's two days with some Clue dudes problem, right?

Not supported by Adrian. I only support head. Any other questions? Yo. Because TCP won't do it quickly enough,

especially in 11n when the packet transmission is in microseconds now. And so the last thing that we want to do is, well, we want to do aggregation, and we can quickly retransmit all of those frames on the hardware, right? We don't actually, the software can do a bit of the work,

but we transmit batches of frames in the hardware. And if you just drop wireless frames, then sure, you end up with TCP sessions having to do their retransmission, but that's very stack dependent, right? And for video, if you just start dropping frames with RTMP or UDP streams or even TCP video streams, if you drop a few too many frames,

then TCP may decide to back off quite significantly and take a couple of seconds to recover, which point you've lost, right? Whereas doing retransmissions in the air is a lot cheaper and easier to do, and mostly hides the latency. It doesn't always work that well, but I think the thing to keep in mind for wireless is,

at these speeds, you will lose packets. 11n aggregation is based on the concept that you are going to drop at least a couple of percent of your frames, and retransmitting those is pretty easy, so you can still present a pretty reliable low-latency environment up the stack. If you start presenting a 2% or 3% loss path to TCP

when you're trying to do 450 megabits, it will get unhappy. Anyone else? Yo. For someone who's never looked at this make money. Ah, well, okay, sorry. Firmware cards are a pain in the ass because they're firmware,

so you'd basically be stuck reading the Linux drivers and trying to get, say, for Marvel, trying to talk to Marvel about an NDA, right? So from the Ethereum side, we have an NDA program, we give people source code, sign the NDA, we give them driver docs and whatever, right? So from the Ethereum side, it's easy. But for that, I got involved without reading the 802.11 spec

because it's long, and I triple-E spec. And if you're not that way-brained, it can be quite foreboding. And to be honest, you could probably pick up maintainership of a driver having the O'Reilly 802.11 style book to give you a background into 802.11.

You don't need to have read the spec. Some parts of the driver, like, say, calculating, some drivers want you to put, say, the 802.11 preamble code in the PLCP. You need to know where it is in the spec. And you need to know things like the definitions of the timing, the inter-frame spacing timing,

and you can look those up in the spec. But you don't need to read the spec to know it. 90% of picking up something like the marble driver is going to be being familiar with device drivers and a bit of wireless, and then lots of pre-tapped above it. I think that's an Indian, and I think that's either an Indian issue. Like, Tix aggregation is either an Indian issue or it's a Tix sequence number initialisation for aggregation issue.

It doesn't look too complicated. I found it before I got on the plane here, and I went, I have to deal with it after. No. I don't think it does,

and I don't think it does not because we can't make it work. I think it's firmware dependent, right? So I think the driver has some support for ad hoc mode, but it has to disable it based on the firmware support.

You cannot use because... So what, you want to try and make your laptop

speak to your iPhone in ad hoc mode? Right, okay, I don't know. That question you could just dump on the wireless list and Bernard will know better. And again, I've seen there's some code for ad hoc mode.

So the reference at the moment, the reference for doing wireless stuff that's not a ferrous drivers is Linux because the vendors are all dumping their stuff into Linux. It's not that an interested party couldn't sign an NDA like Sam did with a bunch of other vendors

and then start hacking on stuff and get the new chip sent to them. It's mostly just a problem that the vendors actively support Linux and the open source community hasn't really picked up driver support and really engaged vendors all that close. And some people from other non-previous projects will say that vendors are impossible to deal with.

And what that translates as is vendors won't give us free access to everything versus vendors are impossible to deal with. So the short answer here, I guess, is it's possible, but chances are you'd have to find somebody who wants to maintain it and look at the Linux code to see what that supports. And if the Linux code doesn't, then you have to talk to Intel.

And I've got contacts in Intel who would love for a free BSD or any BSD developer to pick up development and run with it and they'll give them all kinds of shit. I've got contacts in Marvel that will quite happily deal with the BSD community. I've apparently got contacts in Broadcom that will do much the same. It's not that they don't want to, it's that they can't do the development themselves

and no one's picked up the slack. Any other questions? Cool. Well, start using 11n. BSD supports 11n, goddammit. I've fed up with people saying we don't do 11n. It's a load of crap. It works perfectly good. Alrighty.