Here's my shortlist of iwn(4) issues. Please feel free to acquire one
or more of these particular tasks.

* the 6235 doesn't work. I have one, but I'm busy doing ${WORK} so
chasing down why isn't on my todo list for a few weeks. Sorry.
* The scan code is broken. We're not setting the active/passive values
correctly, we're not setting the service maximum time field correctly.
Thus, the scan command can hang when scanning passive channels.
Setting these things correctly (based on iwlwifi) mostly works.
service_time is a bit wonky as the iwlwifi code sets it to (blah) |
(some other blah << 22) and so I've seen it scan channel 13 for 4
million microseconds, which I don't think is "right."
* We should block sending scan if we've already sent a scan command
(ie, we should fail that scan) if it hasn't completed.
* We should block sending RXON if we've sent a scan command if it
hasn't completed - we should error out
* .. and then clear the scan tracking flag when we do a chipset reset.
* The scan beacon timer config has to take the beacon interval into
account AND make sure that we come back on channel for long enough to
do traffic/hear beacons. That way we don't disassociate when we are
scanning because we stopped hearing our real traffic.
* The NIC is rejecting frame TX on passive channels (eg 5GHZ radar
channels) until it hears a beacon. Since we're not doing software
retransmit of frames in this case, we end up failing to associate
reliably on these channels. The correct mechanism is to queue the
frame again and when we receive a beacon, clear the "TX queue paused"
flag and re-schedule frames. Maybe, if someone is evil enough, they
could abuse the net80211 powersave queue to re-queue an 802.11 frame
and wake up the power save queue when it's done.

There's also a net80211 bug where if the scan is cancelled at the
wrong spot (I think at the end) then it ends up never resetting the
ss_next value to 0, and subsequent scan requests end up failing as
there's no channels to scan. That also has to be fixed.

I think those are the annoying bugs. They mostly show up in various
company offices (Yahoo, Netflix) rather than at home.

It'd also be nice to correctly use the scan infrastructure on iwn(4)
to do bulk scans. net80211 scans one channel at a time. We should be
able to write an iwn(4) specific scan module in the driver that
registers a scan module optimised for the NIC. The NIC can scan
multiple channels and send out multiple SSID probes by the firmware;
it doesn't have to transition in and out of the SCAN state to do this.

The intel NIC support is getting better but I really could do with
some help here. I'm kind of still feeling a bit burnt out here. :-)

freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to