293339 |
07-Jan-2016 |
avos |
net80211 drivers: fix ieee80211_init_channels() usage
Fix out-of-bounds read (all) / write (11n capable) for drivers that are using ieee80211_init_channels() to initialize channel list.
Tested with: * RTL8188EU, STA mode. * RTL8188CUS, STA mode. * WUSB54GC, HOSTAP mode.
Approved by: adrian (mentor) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D4818
|
287197 |
27-Aug-2015 |
glebius |
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack.
Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing.
Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
|
286410 |
07-Aug-2015 |
glebius |
Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack.
Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Details here:
https://wiki.freebsd.org/projects/ifnet/net80211
Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances of problems are low. The wtap wasn't compilable even before this change. But the ndis driver is complex, and it is likely to be broken with this commit. Help with testing and debugging it is appreciated.
Differential Revision: D2655, D2740 Sponsored by: Nginx, Inc. Sponsored by: Netflix
|
283540 |
25-May-2015 |
glebius |
Change three methods in struct ieee80211com, namely ic_updateslot, ic_update_mcast and ic_update_promisc, to pass pointer to the ieee80211com, not to the ifnet.
Sponsored by: Netflix Sponsored by: Nginx, Inc.
|
254279 |
13-Aug-2013 |
adrian |
ieee80211_rate2plcp() and ieee80211_rate2phytype() are both pre-11n routines and thus assert if one passes in a rate code with the high bit set.
Since the high bit can indicate either IEEE80211_RATE_BASIC or IEEE80211_RATE_MCS, it's up to the caller to determine whether the rate is 11n or not, and either mask out the BASIC bit, or call a different function.
(Yes, this does mean that net80211 should grow 11n-aware rate2phytype() and rate2plcp() functions..)
This may need to happen for the other drivers - it's currently only done (now) for iwn(4) and bwi(4).
PR: kern/181100
|
206358 |
07-Apr-2010 |
rpaulo |
net80211 rate control framework (net80211 ratectl).
This framework allows drivers to abstract the rate control algorithm and just feed the framework with the usable parameters. The rate control framework will now deal with passing the parameters to the selected algorithm. Right now we have AMRR (the default) and RSSADAPT but there's no way to select one with ifconfig, yet. The objective is to have more rate control algorithms in the net80211 stack so all drivers[0] can use it. Ideally, we'll have the well-known sample rate control algorithm in the net80211 at some point so all drivers can use it (not just ath).
[0] all drivers that do rate control in software, that is.
Reviewed by: bschmidt, thompsa, weyongo MFC after: 1 months
|
192306 |
18-May-2009 |
imp |
Fix a typo from the original driver. We need to write ctrl2 into RF register 0x52, not ctrl1. This appears to be a mistake in the bcm reverse engineering page, and has been corrected there. Tracing through the code, this is more in keeping with the "documented" register. Sephe thinks it looks interesting and may be worth fixing. :)
Submitted by: ddkprog at yahoo com Reviewed by: Sepherosa Ziehau
|
192277 |
18-May-2009 |
imp |
Turns out that my BCM4318 has a PCI ID of 0x4319, which lead me to believe it was a BCM4319. However, it is the a/b/g variation of the BCM4318. The chip itself is labelled BCM4318EKFBG, and the board is BCM94318MKABG.
Paradox's patch includes the type of 802.11 wireless for each card, but changes all the names (I don't think the latter is quite right). Import that part of the patch, but keep the current set of BCM names (with a minor tweak for the 4306 ones). I'll need to verify them via some other means.
Obtained from: http://paradox.lissyara.su/bwi.diff (partially)
|
191762 |
03-May-2009 |
imp |
Bring in Andrew Thompson's port of Sepherosa Ziehau's bwi driver for Broadcom BCM43xx chipsets. This driver uses the v3 firmware that needs to be fetched separately. A port will be committed to create the bwi firmware module.
The driver matches the following chips: Broadcom BCM4301, BCM4307, BCM4306, BCM4309, BCM4311, BCM4312, BCM4318, BCM4319
The driver works for 802.11b and 802.11g.
Limitations: This doesn't support the 802.11a or 802.11n portion of radios. Some BCM4306 and BCM4309 cards don't work with Channel 1, 2 or 3. Documenation for this firmware is reverse engineered from http://bcm.sipsolutions.net/ V4 of the firmware is needed for 11a or 11n support http://bcm-v4.sipsolutions.net/ Firmware needs to be fetched from a third party, port to be committed
# I've tested this with a BCM4319 mini-pci and a BCM4318 CardBus card, and # not connected it to the build until the firmware port is committed.
Obtained from: DragonFlyBSD, //depot/projects/vap Reviewed by: sam@, thompsa@
|