[iwn] round four - 5100 works, 21xx works, EAPOL fixes, rate selection fixes

[Adrian Chadd]

followup:

* 6205 works
* 6230 works
* 6200 works
* 2230 works
* 1030 works
* 5100 works

What i haven't yet tested:

* 4965, mostly because I'm scared to
* Whichever NIC Eitan has, as he has it and I don't (2200?)
* (and obviously whatever other NICs exist that I don't have)

What doesn't work:

* Centrino 100 - EEPROM read failure, then kernel hang
* 6150, 6235, 6250 - all have a variant on firmware panic or failed
calibration upload.

So, the 6xxx NICs that don't work should be easy to solve - they
should already have (somewhat) worked with -HEAD.
The Centrino 100 is a bit more of a special case.

If you have any of the above NICs that work or that I haven't yet
tested, I'd really appreciate it if you could spin up the latest diff
with the latest net80211 code. It should behave quite a bit better.

Thanks!



-adrian


On 8 November 2013 23:46, Adrian Chadd <adrian at freebsd.org> wrote:
> Argh, why am I still hacking on the iwn(4) driver.
>
> So, I saw a lot of broken stuff. This patch fixes some.
>
> http://people.freebsd.org/~adrian/iwn/20131108-iwn-update-works-full-5100-11.diff
>
> You have to update sys/net80211 and sys/dev/iwn to the latest version
> in HEAD before you apply this diff.
>
> What's committed:
>
> * AMRR wasn't correctly initializing the initial rate, so it thought
> it was starting at MCS15 but it was in fact starting at MCS0. This
> caused hilarity.
>
> * AMRR should be selecting a "mostly ok" rate, not MCS15. So, this was
> also fixed.
>
> What's in this patch:
>
> * EAPOL frames were going out at the normal data rate, rather than
> going out at the management rate. Like ath(4), override this.  Once I
> fixed AMRR to set the initial rate from MCS0 to the "best initial
> rate" it chose MCS15 and this failed. It showed up as the initial
> association suceeding but the auth exchange failed, logging a
> "pre-shared key may be incorrect" message. Sigh. So, like ath(4),
> detect if it's EAPOL and if so override.
>
> * If an AMPDU frame TX failed the firmware doesn't send up a
> compressed-BA notification as it doesn't receive one.
> iwn_ampdu_tx_done() doesn't do any rate control notification - that is
> left up to the compressed BA RX function. So, if an entire A-MPDU
> transmit failed, there'd be no notification of such - and the rate
> control code never got notified of said failures! Thus it would never
> back off the rate. So, if the whole frame transmission failed, just
> notify the rate control code so it correctly backs off the rate
> selection.
>
> With this, things are .. more stable. The whole A-MPDU handling needs
> a lot of work to make as correct as the ath(4) driver, but that is so
> not in the scope of what I'm doing here.
>
>
>
> -adrian