- 11 10月, 2007 9 次提交
-
-
由 Johannes Berg 提交于
When doing key selection for software decryption, mac80211 gets a few things wrong: it always uses pairwise keys if configured, even if the frame is addressed to a multicast address. Also, it doesn't allow using a key index of zero if a pairwise key has also been found. This patch changes the key selection code to be (more) in line with the 802.11 specification. I have confirmed that with this, multicast frames are correctly decrypted and I've tested with WEP as well. While at it, I've cleaned up the semantics of the hardware flags IEEE80211_HW_WEP_INCLUDE_IV and IEEE80211_HW_DEVICE_HIDES_WEP and clarified them in the mac80211.h header; it is also now allowed to set the IEEE80211_HW_DEVICE_HIDES_WEP option even if it only applies to frames that have been decrypted by the hw, unencrypted frames must be dropped but encrypted frames that the hardware couldn't handle can be passed up unmodified. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Acked-by: NMichael Wu <flamingice@sourmilk.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Unused in drivers, userspace and mac80211. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Acked-by: NMichael Wu <flamingice@sourmilk.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Johannes Berg 提交于
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Johannes Berg 提交于
The flag is never checked because drivers can simply call ieee80211_beacon_get() regardless of setting this flag. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Acked-by: NMichael Wu <flamingice@sourmilk.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Johannes Berg 提交于
The callback isn't used so remove it. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Acked-by: NMichael Wu <flamingice@sourmilk.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Daniel Drake 提交于
zd1211rw and bcm43xx are interested in being notified when ERP IE conditions change, so that they can reprogram a register which affects how control frames are transmitted. This patch adds an interface similar to the one that can be found in softmac. Signed-off-by: NDaniel Drake <dsd@gentoo.org> Signed-off-by: NJiri Benc <jbenc@suse.cz> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Daniel Drake 提交于
Similarly to CTS protection, whether short preambles are used for 802.11b transmissions should be a per-subif setting, not device global. For STAs, this patch makes short preamble handling automatic based on the ERP IE. For APs, hostapd still uses the prism ioctls, but the write ioctl has been restricted to AP-only subifs. ieee80211_txrx_data.short_preamble (an unused field) was removed. Unfortunately, some API changes were required for the following functions: - ieee80211_generic_frame_duration - ieee80211_rts_duration - ieee80211_ctstoself_duration - ieee80211_rts_get - ieee80211_ctstoself_get Affected drivers were updated accordingly. Signed-off-by: NDaniel Drake <dsd@gentoo.org> Signed-off-by: NJiri Benc <jbenc@suse.cz> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
mac80211 informs the driver what the short and long retry values are through set_retry_limit(), but when packets are being transmitted it did not inform the driver which of the 2 retry limits should actually be used. Instead it sends the actual value, but for drivers that can only set the retry limit and the register and in the descriptor need to indicate which of the limits should be used this is not really useful. This patch will add a IEEE80211_TXCTL_LONG_RETRY_LIMIT flag to the ieee80211_tx_control structure. By default the short retry limit should be used but if the flag is set the long retry should be used. This does not prevent the driver to ignore the request for "no retry" packets, but at least those will be send out with the short retry limit. But there is no perfect cure for this problem.. :( Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJiri Benc <jbenc@suse.cz> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Michael Wu 提交于
The sta_info code has some awkward locking which prevents some driver callbacks from being allowed to sleep. This patch makes the locking more focused so code that calls driver callbacks are allowed to sleep. It also converts sta_lock to a rwlock. Signed-off-by: NMichael Wu <flamingice@sourmilk.net> Signed-off-by: NJiri Benc <jbenc@suse.cz> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 13 7月, 2007 2 次提交
-
-
由 Johannes Berg 提交于
The semantics of not having an add_interface callback are not well defined, this callback is required because otherwise you cannot obtain the requested MAC address of the device. Change the documentation to reflect this, add a note about having no MAC address at all, add a warning that mac_addr in struct ieee80211_if_init_conf can be NULL and finally verify that a few callbacks are assigned by way of BUG_ON() Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJiri Benc <jbenc@suse.cz> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Remove ieee80211_set_aid_for_sta and associated code. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJiri Benc <jbenc@suse.cz> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 06 5月, 2007 1 次提交
-
-
由 Jiri Benc 提交于
Add mac80211, the IEEE 802.11 software MAC layer. Signed-off-by: NJiri Benc <jbenc@suse.cz> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-