Searched hist:284588 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-11-stable/sys/dev/iwn/ | ||
| H A D | if_iwnvar.h | diff 284588 Thu Jun 18 23:56:50 MDT 2015 adrian First cut at attempting to buffer frames until we see a beacon. The iwn(4) firmware forgets most of its channel state after an RXON command. This means that any beacons its seen on passive 5GHz channels are forgotten upon an association/authorisation request. This unfortuantely means that 5GHz association almost always fails - the assoc and/or auth frames are dropped with a status of "passive channel, haven't seen a beacon yet." (0x90.) So: * add an xmit queue, global, to buffer frames * modify the xmit path to use the mbuf tag from net80211 to specify raw frame details * buffer xmit frames from both raw and non-raw paths * if a beacon is seen in the RX path, schedule a taskqueue to send said frames and un-buffer things. * flush frames during state change back to INIT, or NIC down/up/detach. This isn't the final shape I'd like this to be in but it certainly is better than 5GHz "not working at all". Tested: * Intel 5100, STA mode (before spilling coffee) * Intel 5300, STA mode (after spilling coffee) Story: * This has been bugging me at work for months, which I just worked around by throwing an ath(4) into my Lenovo T400 cardbus slot. * Our ops director discovered indeed FreeBSD runs well on the Lenovo T420p, except for that pesky 5GHz thing. So now developers also can have a T420p running FreeBSD to do work with. Their #1 feedback to me - "boy it'd be nice if 5GHz wifi worked." * .. then, I was at NANOG but stuck with 5GHz only wifi and no ath(4) NIC to put in a laptop - and I snapped. Thus, the reason this is actually work related. MFC after: 2 weeks Sponsored by: Norse Corp, Inc. |
| H A D | if_iwn.c | diff 284588 Thu Jun 18 23:56:50 MDT 2015 adrian First cut at attempting to buffer frames until we see a beacon. The iwn(4) firmware forgets most of its channel state after an RXON command. This means that any beacons its seen on passive 5GHz channels are forgotten upon an association/authorisation request. This unfortuantely means that 5GHz association almost always fails - the assoc and/or auth frames are dropped with a status of "passive channel, haven't seen a beacon yet." (0x90.) So: * add an xmit queue, global, to buffer frames * modify the xmit path to use the mbuf tag from net80211 to specify raw frame details * buffer xmit frames from both raw and non-raw paths * if a beacon is seen in the RX path, schedule a taskqueue to send said frames and un-buffer things. * flush frames during state change back to INIT, or NIC down/up/detach. This isn't the final shape I'd like this to be in but it certainly is better than 5GHz "not working at all". Tested: * Intel 5100, STA mode (before spilling coffee) * Intel 5300, STA mode (after spilling coffee) Story: * This has been bugging me at work for months, which I just worked around by throwing an ath(4) into my Lenovo T400 cardbus slot. * Our ops director discovered indeed FreeBSD runs well on the Lenovo T420p, except for that pesky 5GHz thing. So now developers also can have a T420p running FreeBSD to do work with. Their #1 feedback to me - "boy it'd be nice if 5GHz wifi worked." * .. then, I was at NANOG but stuck with 5GHz only wifi and no ath(4) NIC to put in a laptop - and I snapped. Thus, the reason this is actually work related. MFC after: 2 weeks Sponsored by: Norse Corp, Inc. |
Completed in 109 milliseconds