Re: Issue with frame injection on monitor interface (ath9k)
Hi. When doing iw dev wlan0 set noack_map 0x0009, frames are sent with Ack Policy set to No Ack (at QoS header), receiver don't ack those frames and I guess that minstrel_ht falls to lowest bitrate possible or it is disabled when iw command is executed. At this point, manually setting a bitrate with iw dev wlan0 set bitrates ht-mcs-5 8 doesn't throw a error and also doesn't change bitrate to the desired one, so, it doesn't work. I partially agree with you, setting for example MCS 15 after noack_map, due to lack of acks and block acks, bitrate could be higher than expected because when transmitter is transmitting, with or without frame aggregation, it doesn't have to pass to receiver mode (hardware level), wait and process each ack/back in order to transmit the next frame or next A-MPDU/A-MSDU. Also, it is expected that modulation type change to 64-QAM with 2 streams and in practice that doesn't happen, it continues at BPSK with 1 spatial stream, probably at 802.11a because iwinfo reports 6.0 Mbit/s PHY rate. Finally, thanks for your suggestion about flags on code. BR, Mário Lopes. Quoting wim torfs wto...@gmail.com: On 02/20/2015 11:11 AM, Mário Lopes wrote: Quoting wim torfs wto...@gmail.com: On 02/19/2015 03:53 PM, Mário Lopes wrote: Hi everyone. When using frame injection over monitor interface, with handmade packet with Radiotap header + QoS + Data, at sender I capture the packet with tcpdump and it is equal to the one I sent. Although, at receiver station, the packet is diferent, FCS was recalculated or forced to active and calculated, MCS is not the one I supplied, sequence number (QoS field) is not the same, amongst other things. Also, QoS Ack policy was No Ack at sender (QoS Control = 0x0020), a Ack frame was transmitted to sender and the received packet arrived with QoS Control = 0x. Mario, If I'm not mistaken, the mac80211 parses your injected packet, retrieves relevant information, such as flags from the radiotap header, removes the radiotap header from your packet and then proceeds with sending the packet as any normal packet towards the radio interface. This, however, means that either the mac80211 rate control algorithm is calls or the ath9k rate control algorithm, depending on your kernel configuration. The ath9k driver uses this rate control information to compose the tx descriptor, after which the packet is handed over to the hardware. I believe it is also the hardware (transmitter side or receiver side, that I don't know), which fills in the actual rate used for the transmission in your packet, since the hardware is capable of retransmitting your packet with a lower rate when transmissions fail too much at the highest rate from the rate selection algorithm. You mentioned that you monitor interface captures the packet as you have sent it. If I remember correctly, the mac80211 forwards this packet towards the monitor interface when the tx status of ath9k has been received, so basically, you receive transmission status information, along with your originally sent packet. Sequence numbers should have been adjusted in this packet I think, however, the transmission rate will be the same as you have specified. If you would like to send at a specific rate, you would need to use the relevant iw commands to fix the transmission rate (or hack ath9k to transmit at a fixed rate). Before trying Radiotap header approach, I did disable Ack's with iw but the transmition rate remained at basic rate (6 Mbit/s) despite forcing higher MCS with iw, so it was useless. Could be this a bug in the driver, unicast traffic sent with NoAck flag treated as a broadcast, despite higher bitrate forcing? Returning to Radiotap, what's the point of injecting a frame with radiotap header if it isn't going to be used? I didn't try all the possible combinations, but the ones I tryied, they where changed before arriving at receiver. Thanks. BR, Mário Lopes. Mario, I don't see the relation between the disabling of acks and the rate selection. I don't have a working setup currently, so I can not test it, but fixing the rate with iw should work. See whether you did everything correctly. I don't have experience with the NoAck flag, so I cannot comment on that, however, when reflecting the standard and previous work, I don't see any reason why the driver would stick to basic rates. Possibly MPDU aggregation is disabled if the NoAck means also no block acks, but this does not prevent you to use MCS rates. Look, this is me just thinking out loud, so I might be wrong here. As regards radiotap, it does have its use. For instance, if you look into net/mac80211/tx.c and search for ieee80211_parse_tx_radiotap, you will notice that it ensures whether or not the IEEE80211_TX_INTFL_DONT_ENCRYPT and IEEE80211_TX_CTL_DONTFRAG flags are set. Also, it allows you to set the IEEE80211_TX_CTL_NO_ACK flag on a per packet base. Best regards, Wim.
Re: AR9462 problems connecting again..
If it is the case that the 4-way handshake fails, then I have seen this issue before. The problem is that messages 1 to 4 are sent with the previous key. However, right after sending message 4/4, does wpa_supplicant set the new key. In some cases, such as in a high throughput environment, this could result that the key is set even before the last packet is sent out. As a result, the AP receives a packet which is encrypted with the wrong key, since it still listens with the old key. I did not notice this issue while authenticating for the first time, only after the first rekey operation. A solution would be to adjust wpa_supplicant to wait for the transmission ack before it sets its key, however, this causes issues with the key reception and transmission count, which could be circumvented by copying the old counter values upon setting the new key, but this is a dirty hack. Another solution would require some more invasive operations, that is, the new key should somehow be linked to the message 4/4 and should only be set by the driver upon transmission of the message 4/4. Best regards, Wim. On 02/23/2015 11:37 AM, Jouni Malinen wrote: On Sun, Feb 22, 2015 at 05:41:25PM -0800, Linus Torvalds wrote: Ok. Attached is what seems to be the relevant part of the wpa_supplicant.log file. The datestamp has been changed so that it can be matched up with the dmesg, and I added empty lines for pauses when I was trying to figure out what the heck it was doing, but other than that it's the raw log. 14:07:16.059389: nl80211: Authenticate (ifindex=3) 14:07:16.390659: nl80211: MLME event 37; timeout with 20:9f:db:e7:80:80 I'm assuming this is unrelated to the issue of getting disconnected after 4-way handshake, but anyway, something here prevent the simple Authentication frame exchange from completing (i.e., either the AP did not reply to these these frames or the response was lost for some reason). The following attempt did you go through without issues. 14:07:19.478850: nl80211: Authenticate (ifindex=3) 14:07:19.493911: nl80211: Authenticate event 14:07:19.494223: nl80211: Associate (ifindex=3) 14:07:19.503237: nl80211: Associate event 14:07:19.504682: wlp1s0: WPA: RX message 1 of 4-Way Handshake from 20:9f:db:e7:80:80 (ver=2) 14:07:19.505850: wlp1s0: WPA: Sending EAPOL-Key 2/4 14:07:19.510108: wlp1s0: WPA: RX message 3 of 4-Way Handshake from 20:9f:db:e7:80:80 (ver=2) 14:07:19.510233: wlp1s0: WPA: Sending EAPOL-Key 4/4 So it looks like both the AP and the station are able to send and receive EAPOL frames. EAPOL-Key message 1/4..3/4 worked fine. However, I'm assuming msg 4/4 did not make it through for some reason. 14:07:19.510338: wlp1s0: WPA: Installing PTK to the driver 14:07:19.510405: wpa_driver_nl80211_set_key: ifindex=3 alg=3 addr=0x7f0ab41cad68 key_idx=0 set_tx=1 seq_len=6 key_len=16 14:07:19.510435:addr=20:9f:db:e7:80:80 And this is where IEEE 802.11 RSN gets a bit messy.. The station installs a key for encrypting all unicast frames to the AP now that it believes 4-way handshake has been completed successfully. 14:07:19.511009: wlp1s0: WPA: Installing GTK to the driver (keyidx=1 tx=0 len=16) And same for a key to decrypt received broadcast/multicast frames. 14:07:19.511205: wlp1s0: WPA: Key negotiation completed with 20:9f:db:e7:80:80 [PTK=CCMP GTK=CCMP] 14:07:19.511223: wlp1s0: Cancelling authentication timeout 14:07:19.511238: wlp1s0: State: GROUP_HANDSHAKE - COMPLETED 14:07:19.511253: wlp1s0: CTRL-EVENT-CONNECTED - Connection to 20:9f:db:e7:80:80 completed [id=0 id_str=] As far as the station is concerned, everything looked fine until here and connection was established successfully. 14:07:20.512476: wlp1s0: WPA: RX message 3 of 4-Way Handshake from 20:9f:db:e7:80:80 (ver=2) However, the AP disagrees.. It looks like this specific AP uses a one second timeout on EAPOL-Key timeouts. This EAPOL-Key frame was likely unencrypted since the AP did not receive (or accept, but more likely not receive) msg 4/4. We are currently allowing such unencrypted EAPOL frames (but not other ethertypes) to get processed even when the pairwise key has been configured. 14:07:20.512674: wlp1s0: WPA: Sending EAPOL-Key 4/4 And here's an attempt to reply.. Alas, this will likely go out encrypted since we have the pairwise key configured and the AP will be dropping it most likely since it would configure the pairwise key for this station only after having receive valid 4/4. 14:07:20.513170: wpa_driver_nl80211_set_key: ifindex=3 alg=3 addr=0x7f0ab41cad68 key_idx=0 set_tx=1 seq_len=6 key_len=16 And station reconfigured the key.. 14:07:21.513331: wlp1s0: WPA: RX message 3 of 4-Way Handshake from 20:9f:db:e7:80:80 (ver=2) 14:07:22.514320: wlp1s0: WPA: RX message 3 of 4-Way Handshake from 20:9f:db:e7:80:80 (ver=2) These are the following two retries from AP, one second apart. Trying EAPOL-Key frames four times in normal behavior, so based on timing here, the
Re: AR9462 problems connecting again..
On Mon, Feb 23, 2015 at 11:55:30AM +0100, wim torfs wrote: If it is the case that the 4-way handshake fails, then I have seen this issue before. The problem is that messages 1 to 4 are sent with the previous key. However, right after sending message 4/4, does wpa_supplicant set the new key. In some cases, such as in a high throughput environment, this could result that the key is set even before the last packet is sent out. As a result, the AP receives a packet which is encrypted with the wrong key, since it still listens with the old key. The specific case here is not PTK rekeying, i.e., it is for the initial 4-way handshake, so there is no previous pairwise key in place. That said, I guess it would be possible for some drivers to hit this even with the initial PTK configuration if hardware acceleration is used for encryption and the frame gets delayed sufficiently long while waiting for medium access. A solution would be to adjust wpa_supplicant to wait for the transmission ack before it sets its key, however, this causes issues with the key reception and transmission count, which could be circumvented by copying the old counter values upon setting the new key, but this is a dirty hack. Another solution would require some more invasive operations, that is, the new key should somehow be linked to the message 4/4 and should only be set by the driver upon transmission of the message 4/4. I've been thinking of adding EAPOL TX status reporting into wpa_supplicant at least to make the debug log more helpful. However, this does indeed cause issues for RX and I'm not really sure I'd like to delay pairwise key configuration. The proper way of handling this would be by doing what the standard really implies, i.e., configure the key for RX only at first and then enable it for TX after EAPOL-Key msg 4/4 has been transmitted. Though, that should really be interpreted with something like enable for TX after the AP has used the key due to this possibility for retransmissions of EAPOL-Key 3/4. That said, there are corner cases even with this design, e.g., due to the STA wanting to transmit Data frames to the AP immediately after EAPOL-Key 4/4; those should really be encrypted, so the behavior here would likely need to be conditional on ethertype (RX-only for EAPOL, RX+TX for everything else). Things get even messier with PTK rekeying when there would actually need to be support for two keys (even with the same key index..) so that the retransmitted EAPOL-Key 3/4 case could be detected and replied to in a way that the AP understands the response. This gets unfortunately ugly and I'd assume almost no station implements this in a way that would handle all cases cleanly (i.e., just hope for msg 4/4 to go through and reassociate as a backup plan if things fail..). -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtlwifi: rtl8192cu: Fix some beacon issue
On Fri, Feb 20, 2015 at 6:47 PM, ap420073 . ap420...@gmail.com wrote: hostapd 2.3 has no problem but i found problem that hostapd is not starting in hostapd 1.0. would you like to try testing hostapd 2.3? Unfortunately v2.3 has the some problem. After a few cycles of /etc/init.d/hostapd stop and start it sometimes stops sending the beacon. Further cycles may or may not start sending beacons as per my original posts. -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] nl80211: add NL80211_CMD_GET_TSF
On Mon, 2015-02-23 at 21:57 +0800, Rohan Joyce wrote: This patch adds a command NL80211_CMD_GET_TSF that retrieves the 64 bit time synchronisation value for an interface. It returns the value in a uint64 attribute of type NL80211_ATTR_TSF. This should explain why and how this could possibly be used - I don't see any reasonable usage since the TSF is quickly changing and this API doesn't really allow for any synchronisation. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rtlwifi: rtl8821ae: Remove duplicate hex prefixes
The # flag in %X means print a 0X prefix. Remove the extra 0x prefix. Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk --- The file uses a mix of explicit 0x prefixes and # flags, as well as a mix of %x and %X, so it's not clear what the most consistent choice would be. drivers/net/wireless/rtlwifi/rtl8821ae/hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c index 8ec822c7..3aca53d9acfb 100644 --- a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c +++ b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c @@ -1515,7 +1515,7 @@ static bool _rtl8821ae_dynamic_rqpn(struct ieee80211_hw *hw, u32 boundary, (u8 *)(support_remote_wakeup)); RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD, -boundary=0x%#X, NPQ_RQPNValue=0x%#X, RQPNValue=0x%#X\n, +boundary=%#X, NPQ_RQPNValue=%#X, RQPNValue=%#X\n, boundary, npq_rqpn_value, rqpn_val); /* stop PCIe DMA -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] nl80211: add NL80211_CMD_GET_TSF
This patch adds a command NL80211_CMD_GET_TSF that retrieves the 64 bit time
synchronisation value for an interface. It returns the value in a uint64
attribute of type NL80211_ATTR_TSF.
Signed-off-by: Rohan Joyce rojoyce.git...@gmail.com
---
include/net/cfg80211.h | 6 ++
include/uapi/linux/nl80211.h | 10 ++
net/mac80211/cfg.c | 16 +++
net/wireless/nl80211.c | 47
net/wireless/rdev-ops.h | 11 +++
net/wireless/trace.h | 18 +
6 files changed, 108 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 64e09e1..9425d11 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2415,6 +2415,9 @@ struct cfg80211_qos_map {
* and returning to the base channel for communication with the AP.
* @tdls_cancel_channel_switch: Stop channel-switching with a TDLS peer. Both
* peers must be on the base channel when the call completes.
+ *
+ * @get_tsf: Get the current value of the time synchronization function for the
+ * given interface
*/
struct cfg80211_ops {
int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -2678,6 +2681,9 @@ struct cfg80211_ops {
void(*tdls_cancel_channel_switch)(struct wiphy *wiphy,
struct net_device *dev,
const u8 *addr);
+
+ int (*get_tsf)(struct wiphy *wiphy, struct net_device *dev,
+ u64 *tsf);
};
/*
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 68b294e..a8d228e 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -798,6 +798,10 @@
* as an event to indicate changes for devices with wiphy-specific regdom
* management.
*
+ * @NL80211_CMD_GET_TSF: Get timing synchronisation function value for the
+ * interface identified by %NL80211_ATTR_IFINDEX. The command returns
+ * the value in a %NL80211_ATTR_TSF.
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -984,6 +988,8 @@ enum nl80211_commands {
NL80211_CMD_WIPHY_REG_CHANGE,
+ NL80211_CMD_GET_TSF,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -1740,6 +1746,8 @@ enum nl80211_commands {
* @NL80211_ATTR_SCHED_SCAN_DELAY: delay before a scheduled scan (or a
* WoWLAN net-detect scan) is started, u32 in seconds.
*
+ * @NL80211_ATTR_TSF: time synchronization function value, u64.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2107,6 +2115,8 @@ enum nl80211_attrs {
NL80211_ATTR_SCHED_SCAN_DELAY,
+ NL80211_ATTR_TSF,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index dd4ff36..77a823f 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -3734,6 +3734,21 @@ static int ieee80211_del_tx_ts(struct wiphy *wiphy,
struct net_device *dev,
return -ENOENT;
}
+static int ieee80211_get_tsf(struct wiphy *wiphy, struct net_device *dev,
+u64 *tsf)
+{
+ struct ieee80211_local *local = wiphy_priv(wiphy);
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+
+ if (!local-ops-get_tsf)
+ return -EOPNOTSUPP;
+
+ *tsf = drv_get_tsf(local, sdata);
+
+ return 0;
+}
+
+
const struct cfg80211_ops mac80211_config_ops = {
.add_virtual_intf = ieee80211_add_iface,
.del_virtual_intf = ieee80211_del_iface,
@@ -3818,4 +3833,5 @@ const struct cfg80211_ops mac80211_config_ops = {
.set_ap_chanwidth = ieee80211_set_ap_chanwidth,
.add_tx_ts = ieee80211_add_tx_ts,
.del_tx_ts = ieee80211_del_tx_ts,
+ .get_tsf = ieee80211_get_tsf,
};
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e9ad9d9..cadd954 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -399,6 +399,7 @@ static const struct nla_policy
nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_WIPHY_SELF_MANAGED_REG] = { .type = NLA_FLAG },
[NL80211_ATTR_NETNS_FD] = { .type = NLA_U32 },
[NL80211_ATTR_SCHED_SCAN_DELAY] = { .type = NLA_U32 },
+ [NL80211_ATTR_TSF] = { .type = NLA_U64 },
};
/* policy for the key attributes */
@@ -1534,6 +1535,7 @@ static int nl80211_send_wiphy(struct
cfg80211_registered_device *rdev,
if (rdev-wiphy.features
NL80211_FEATURE_SUPPORTS_WMM_ADMISSION)
CMD(add_tx_ts, ADD_TX_TS);
+ CMD(get_tsf, GET_TSF);
}
/* add into the
Re: [RFC] mac80211_hwsim: notify user-space about channel change.
On Tue, 2015-02-17 at 15:59 -0800, gree...@candelatech.com wrote: From: Ben Greear gree...@candelatech.com The goal is to allow the user-space application to properly filter packets before sending them down to the kernel. This should more closely mimic what a real piece of hardware would do. + * @HWSIM_CMD_NOTIFY: notify user-space about driver changes. This is + * designed to help the user-space app better emulate radio hardware. + * This command uses: + * %HWSIM_ATTR_FREQ # Notify current operating center frequency. + * %HWSIM_ATTR_ADDR_TRANSMITTER # ID which radio we are notifying about. * @__HWSIM_CMD_MAX: enum limit This seems a bit strange - don't we already tag packets with the frequency? Why would you need the channel change separately? What does that even mean? Depending on how you use this it could entirely break off-channel operation, for example. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211_hwsim: support any address in userspace
Due to the checks in get_hwsim_data_ref_from_addr, wmediumd
was only able to use the second mac address (those starting with
0x42). This is confusing and needlessly limiting, so allow any
configured address.
While at it, use ether_addr_equal since data-addresses and the
address from the netlink payload are aligned(2).
Signed-off-by: Bob Copeland m...@bobcopeland.com
---
drivers/net/wireless/mac80211_hwsim.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 1204853..be8bb18 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -907,8 +907,7 @@ static void mac80211_hwsim_tx_frame_nl(struct ieee80211_hw
*hw,
goto nla_put_failure;
}
- if (nla_put(skb, HWSIM_ATTR_ADDR_TRANSMITTER,
- ETH_ALEN, data-addresses[1].addr))
+ if (nla_put(skb, HWSIM_ATTR_ADDR_TRANSMITTER, ETH_ALEN, hdr-addr2))
goto nla_put_failure;
/* We get the skb-data */
@@ -2608,14 +2607,18 @@ static struct mac80211_hwsim_data
*get_hwsim_data_ref_from_addr(const u8 *addr)
{
struct mac80211_hwsim_data *data;
bool _found = false;
+ int i;
spin_lock_bh(hwsim_radio_lock);
list_for_each_entry(data, hwsim_radios, list) {
- if (memcmp(data-addresses[1].addr, addr, ETH_ALEN) == 0) {
- _found = true;
- break;
+ for (i = 0; i ARRAY_SIZE(data-addresses); i++) {
+ if (ether_addr_equal(data-addresses[i].addr, addr)) {
+ _found = true;
+ goto end_loop;
+ }
}
}
+end_loop:
spin_unlock_bh(hwsim_radio_lock);
if (!_found)
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] nl80211: add NL80211_CMD_GET_TSF
Hi, The motivation for this patch is to assist using a WiiU Gamepad with Linux. The WiiU Gamepad is an input device that also contains an LCD touchscreen, speakers and a variety of sensors. The Gamepad connects to an access point (usually the WiiU console itself, but it can be coerced to connect to a properly configured hostap). The Gamepad provides five services over UDP. Two of the services that are provided (audio and video streaming to the device) use the TSF as a timestamp in the application layer. The firmware on the Gamepad checks to make sure that incoming packets for these services have timestamps within 1000us of its own internal clock, which is synced to the TSF of the access point. At the moment, users who want to use this device have to manually apply a kernel patch similar to that which was first posted to this list a year ago. This patch is my attempt to implement the functionality using a more conventional API and make it easier for end users. Should I include protocol implementation details specific to this device in the documentation of the NL80211_CMD_GET_TSF command? Thanks for your time, Rohan -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] cfg80211: Allow NL80211_ATTR_IFINDEX to be added to vendor events
In addition to what Arend said,
@@ -4263,7 +4263,8 @@ struct sk_buff *__cfg80211_alloc_event_skb(struct wiphy
*wiphy,
enum nl80211_commands cmd,
enum nl80211_attrs attr,
int vendor_event_idx,
-int approxlen, gfp_t gfp);
+int approxlen, gfp_t gfp,
+struct wireless_dev *wdev);
This is really strange. IMHO the wdev should be the second argument -
certainly usually gfp is the last one so it shouldn't be after that.
+/**
+ * cfg80211_vendor_event_alloc_ext - allocate vendor-specific event skb
+ * @wiphy: the wiphy
+ * @event_idx: index of the vendor event in the wiphy's vendor_events
+ * @approxlen: an upper bound of the length of the data that will
+ * be put into the skb
+ * @gfp: allocation flags
+ * @wdev: the wireless device
+ *
+ * This function allocates and pre-fills an skb for an event on the
+ * vendor-specific multicast group. This is otherwise identical to
+ * cfg80211_vendor_event_alloc(), but ifindex of the specified wireless
device
+ * is added to the event message before the vendor data attribute.
+ *
+ * When done filling the skb, call cfg80211_vendor_event() with the
+ * skb to send the event.
+ *
+ * Return: An allocated and pre-filled skb. %NULL if any errors happen.
+ */
+static inline struct sk_buff *
+cfg80211_vendor_event_alloc_ext(struct wiphy *wiphy, int approxlen,
+ int event_idx, gfp_t gfp,
+ struct wireless_dev *wdev)
+{
+ return __cfg80211_alloc_event_skb(wiphy, NL80211_CMD_VENDOR,
+ NL80211_ATTR_VENDOR_DATA,
+ event_idx, approxlen, gfp, wdev);
}
This doesn't seem necessary, why not just update the original function
to add and document the new optional argument?
[however, in the unlikely even that you can convince me otherwise we may
have to add this to the documentation?]
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-4.0-rc1 bug report
Hello there, [linux-4.0-rc1/drivers/net/wireless/ath/wil6210/debugfs.c:634]: (error) Width 8 given in format string (no. 1) is larger than destination buffer 'cmd[8]', use %7s to prevent overflowing it. This looks like an off-by-one error to me. Suggest either make the buffer bigger, to contain all 8 characters, or change the width to suit. Regards David Binderman -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nl80211: add new scan flag to indicate P2P search
On Mon, 2015-01-26 at 11:58 +0200, Jouni Malinen wrote: If you need to distinguish, you should be able to advertise P2P-Device supports, and then get P2P scans on the P2P-Device virtual interface. Could be a pure driver thing of course. It would be unfortunate to force people to use P2P-Device for this. Just for the record - we discussed this in Ottawa and as I understood it you seemed not to object as much to P2P-Device as here originally. In particular, we discussed the fact that P2P-Device can share MAC addresses with the regular interface, but also from a 'foreign' interface (i.e. a different NIC supporting e.g. different bands). I'll drop all of this for now, at least until you investigate P2P-Device support more thoroughly. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mac80211: use rhashtable for station table
On Fri, 2015-02-13 at 14:13 -0800, Ben Greear wrote: Oooh, maybe finally time to mix local addr with peer addr to make lots of vifs connected to same AP hash well too? :) As we discussed before, mixing it in isn't actually possible. Your patch will get easier to maintain (if you also convert it) though :) johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211-hwsim: Don't enqueue pkts that do not want txstatus.
On 02/23/2015 08:08 AM, Johannes Berg wrote: On Tue, 2015-02-10 at 10:25 -0800, gree...@candelatech.com wrote: From: Ben Greear gree...@candelatech.com Otherwise, skb is not cleaned up until there is some timeout and the tx-queue quickly becomes overly full. +++ b/drivers/net/wireless/mac80211_hwsim.c @@ -928,10 +928,14 @@ static void mac80211_hwsim_tx_frame_nl(struct ieee80211_hw *hw, genlmsg_end(skb, msg_head); genlmsg_unicast(init_net, skb, dst_portid); -/* Enqueue the packet */ -skb_queue_tail(data-pending, my_skb); data-tx_pkts++; data-tx_bytes += my_skb-len; + +/* Enqueue the packet if we are expecting a tx-status response */ +if (info-flags IEEE80211_TX_CTL_REQ_TX_STATUS) +skb_queue_tail(data-pending, my_skb); +else +ieee80211_free_txskb(hw, my_skb); This doesn't really seem right - essentially it means that whatever you just gave to userspace is now completely useless? It seems skb_orphan() could/should be put here. I don't understand your complaint, why is what I gave to user-space useless? If we just orphan them, does that clean up the skb memory properly? If not, what eventually frees the skb? Thanks, Ben johannes -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] wext: Return -E2BIG when the buffer is too small for the full scan results, including IEs.
On Thu, 2015-02-19 at 15:42 -0600, James Minor wrote:
+#define CHECK_BUF_FULL(p, c, e) \
+ do { \
+ if (unlikely(p == c)) \
+ e = -E2BIG;\
+ } while (0)
I think this would be nicer as a static inline that returned -E2BIG, or
the passed in err, instead of modifying the macro argument.
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211-hwsim: Don't enqueue pkts that do not want txstatus.
On Tue, 2015-02-10 at 10:25 -0800, gree...@candelatech.com wrote: From: Ben Greear gree...@candelatech.com Otherwise, skb is not cleaned up until there is some timeout and the tx-queue quickly becomes overly full. +++ b/drivers/net/wireless/mac80211_hwsim.c @@ -928,10 +928,14 @@ static void mac80211_hwsim_tx_frame_nl(struct ieee80211_hw *hw, genlmsg_end(skb, msg_head); genlmsg_unicast(init_net, skb, dst_portid); - /* Enqueue the packet */ - skb_queue_tail(data-pending, my_skb); data-tx_pkts++; data-tx_bytes += my_skb-len; + + /* Enqueue the packet if we are expecting a tx-status response */ + if (info-flags IEEE80211_TX_CTL_REQ_TX_STATUS) + skb_queue_tail(data-pending, my_skb); + else + ieee80211_free_txskb(hw, my_skb); This doesn't really seem right - essentially it means that whatever you just gave to userspace is now completely useless? It seems skb_orphan() could/should be put here. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mac80211: use rhashtable for station table
On Sat, 2015-02-14 at 05:14 +0300, Sergey Ryazanov wrote: A nice change! Couple of years ago I did some tests with real sets of MACs and jhash gives a better distribution than usage of a last octet. BTW, why do you use full address and generic jhash? Hashing of two least significant words could be faster. Isn't it? Well - not sure what you're trying to say? First you're saying jhash() was clearly better and then you're saying I shouldn't use it? ;-) Anyway - just using the last two bytes (or even 16-bit words) won't cover the case where the locally administered bit is set in an otherwise unchanged address, which is getting more common for P2P. I also don't really see any major drawbacks to hashing it all? johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AR9462 problems connecting again..
On Sun, Feb 22, 2015 at 05:41:25PM -0800, Linus Torvalds wrote:
Nope, everything else I have seems to be intel wireless. I think one
of the kids machines is a Mac Mini with an ath5k thing, but I'm hoping
the wpa_supplicant.log is sufficient to give somebody an idea.
It looks like there are two issues here: 1) EAPOL-Key message 4/4 (i.e.,
the second Data frame sent by the station during association) is somehow
not seen or accepted by the AP, 2) recovery from that msg 4/4 getting
lost does not work in the intended way.
For (1), one would likely need to see a wireless capture from a separate
WLAN radio to say something certain about what exactly happened.
ath5k-compatible radios would not be sufficient since this would need to
be able to see HT frames which ath9k is mostly like using here. I
haven't used iwlwifi as a sniffer, so I do not know whether that would
be a workable option for this.
In my tests, I can see the rate control algorithm (minstrel_ht) using a
pretty high rate (even MCS14 with 2-stream device, which is one short of
maximum) which is quite a bit higher than I would myself have selected
for an EAPOL frame (especially for EAPOL-Key 4/4 which has these lovely
issues with retransmissions) more or less immediately after association.
Anyway, that frame is supposed to get additional fall-back TX rates for
link layer retransmissions and those should make it much more likely for
this to be received by the AP. Sniffer trace would confirm that.
For (2), wpa_supplicant debug log gives a pretty clear idea on what is
happening and based on that, I can easily reproduce this part. In fact,
I now have a fully automated test script for verifying this with
mac80211_hwsim.
Some alternative means of improving this was discussed in this thread.
I'm not completely happy with this, but the following mac80211 changes
do fix this retransmission case and will likely make the issue you are
seeing disappear since it allows any of the four EAPOL-Key msg 4/4
transmissions to be received by the AP to avoid the disconnection. This
doesn't fix the initial trigger behind the issue, but with those EAPOL
retransmissions working, the likelihood of all four attempts failing
(with each getting multiple link-layer retransmissions) is quite small.
mac80211: Do not encrypt EAPOL frames before peer has used the key
The 4-way handshake design is a bit inconvenient for the case where msg
3/4 needs to be transmitted (e.g., AP not receiving first transmission
of 4/4). The supplicant side has already configured the pairwise key at
that point in time and while we allow unencrypted msg 3/4 to be
received, we were sending out 4/4 encrypted which will result in it
getting dropped. User space would be aware of when the EAPOL frame
should not be encrypted, but we do not have convenient means of telling
mac80211 that. For now, use a mac80211-specific hack to avoid EAPOL
frame encryption to allow retransmission of 4-way handshake messages 3/4
and 4/4 to work in a way that the authenticator side can process 4/4.
---
net/mac80211/key.h | 2 ++
net/mac80211/rx.c | 11 +++
net/mac80211/tx.c | 13 +
3 files changed, 26 insertions(+)
diff --git a/net/mac80211/key.h b/net/mac80211/key.h
index d57a9915..3e23276 100644
--- a/net/mac80211/key.h
+++ b/net/mac80211/key.h
@@ -120,6 +120,8 @@ struct ieee80211_key {
/* number of times this key has been used */
int tx_rx_count;
+ /* whether a valid RX decryption has happened with this key */
+ bool valid_rx_seen;
#ifdef CONFIG_MAC80211_DEBUGFS
struct {
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 1101563..8f3f86c 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1691,6 +1691,16 @@ ieee80211_rx_h_decrypt(struct ieee80211_rx_data *rx)
return result;
}
+static ieee80211_rx_result debug_noinline
+ieee80211_rx_h_check_key_use(struct ieee80211_rx_data *rx)
+{
+ struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(rx-skb);
+
+ if ((status-flag RX_FLAG_DECRYPTED) rx-key)
+ rx-key-valid_rx_seen = true;
+ return RX_CONTINUE;
+}
+
static inline struct ieee80211_fragment_entry *
ieee80211_reassemble_add(struct ieee80211_sub_if_data *sdata,
unsigned int frag, unsigned int seq, int rx_queue,
@@ -3139,6 +3149,7 @@ static void ieee80211_rx_handlers(struct
ieee80211_rx_data *rx,
CALL_RXH(ieee80211_rx_h_uapsd_and_pspoll)
CALL_RXH(ieee80211_rx_h_sta_process)
CALL_RXH(ieee80211_rx_h_decrypt)
+ CALL_RXH(ieee80211_rx_h_check_key_use)
CALL_RXH(ieee80211_rx_h_defragment)
CALL_RXH(ieee80211_rx_h_michael_mic_verify)
/* must be after MMIC verify so header is counted in MPDU mic */
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 88a18ff..c314c59 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -612,6 +612,19 @@
Re: AR9462 problems connecting again..
On Sun, Feb 22, 2015 at 05:41:25PM -0800, Linus Torvalds wrote: Ok. Attached is what seems to be the relevant part of the wpa_supplicant.log file. The datestamp has been changed so that it can be matched up with the dmesg, and I added empty lines for pauses when I was trying to figure out what the heck it was doing, but other than that it's the raw log. 14:07:16.059389: nl80211: Authenticate (ifindex=3) 14:07:16.390659: nl80211: MLME event 37; timeout with 20:9f:db:e7:80:80 I'm assuming this is unrelated to the issue of getting disconnected after 4-way handshake, but anyway, something here prevent the simple Authentication frame exchange from completing (i.e., either the AP did not reply to these these frames or the response was lost for some reason). The following attempt did you go through without issues. 14:07:19.478850: nl80211: Authenticate (ifindex=3) 14:07:19.493911: nl80211: Authenticate event 14:07:19.494223: nl80211: Associate (ifindex=3) 14:07:19.503237: nl80211: Associate event 14:07:19.504682: wlp1s0: WPA: RX message 1 of 4-Way Handshake from 20:9f:db:e7:80:80 (ver=2) 14:07:19.505850: wlp1s0: WPA: Sending EAPOL-Key 2/4 14:07:19.510108: wlp1s0: WPA: RX message 3 of 4-Way Handshake from 20:9f:db:e7:80:80 (ver=2) 14:07:19.510233: wlp1s0: WPA: Sending EAPOL-Key 4/4 So it looks like both the AP and the station are able to send and receive EAPOL frames. EAPOL-Key message 1/4..3/4 worked fine. However, I'm assuming msg 4/4 did not make it through for some reason. 14:07:19.510338: wlp1s0: WPA: Installing PTK to the driver 14:07:19.510405: wpa_driver_nl80211_set_key: ifindex=3 alg=3 addr=0x7f0ab41cad68 key_idx=0 set_tx=1 seq_len=6 key_len=16 14:07:19.510435:addr=20:9f:db:e7:80:80 And this is where IEEE 802.11 RSN gets a bit messy.. The station installs a key for encrypting all unicast frames to the AP now that it believes 4-way handshake has been completed successfully. 14:07:19.511009: wlp1s0: WPA: Installing GTK to the driver (keyidx=1 tx=0 len=16) And same for a key to decrypt received broadcast/multicast frames. 14:07:19.511205: wlp1s0: WPA: Key negotiation completed with 20:9f:db:e7:80:80 [PTK=CCMP GTK=CCMP] 14:07:19.511223: wlp1s0: Cancelling authentication timeout 14:07:19.511238: wlp1s0: State: GROUP_HANDSHAKE - COMPLETED 14:07:19.511253: wlp1s0: CTRL-EVENT-CONNECTED - Connection to 20:9f:db:e7:80:80 completed [id=0 id_str=] As far as the station is concerned, everything looked fine until here and connection was established successfully. 14:07:20.512476: wlp1s0: WPA: RX message 3 of 4-Way Handshake from 20:9f:db:e7:80:80 (ver=2) However, the AP disagrees.. It looks like this specific AP uses a one second timeout on EAPOL-Key timeouts. This EAPOL-Key frame was likely unencrypted since the AP did not receive (or accept, but more likely not receive) msg 4/4. We are currently allowing such unencrypted EAPOL frames (but not other ethertypes) to get processed even when the pairwise key has been configured. 14:07:20.512674: wlp1s0: WPA: Sending EAPOL-Key 4/4 And here's an attempt to reply.. Alas, this will likely go out encrypted since we have the pairwise key configured and the AP will be dropping it most likely since it would configure the pairwise key for this station only after having receive valid 4/4. 14:07:20.513170: wpa_driver_nl80211_set_key: ifindex=3 alg=3 addr=0x7f0ab41cad68 key_idx=0 set_tx=1 seq_len=6 key_len=16 And station reconfigured the key.. 14:07:21.513331: wlp1s0: WPA: RX message 3 of 4-Way Handshake from 20:9f:db:e7:80:80 (ver=2) 14:07:22.514320: wlp1s0: WPA: RX message 3 of 4-Way Handshake from 20:9f:db:e7:80:80 (ver=2) These are the following two retries from AP, one second apart. Trying EAPOL-Key frames four times in normal behavior, so based on timing here, the issue is in AP not receiving (or accepting) msg 4/4. 14:07:23.542903: nl80211: Deauthenticate event And this is the expected deauthentication by the AP after the last EAPOL-Key frame retransmission failed to get a valid response. So yes, this is a race condition of sorts. It is interesting if verbose debugging in wpa_supplicant is enough to make this less likely to fail. That will give some more time between the EAPOL-Key msg 4/4 transmission (packet socket send() on the netdev) and pairwise key configuration (netlink send). In theory, it could be possible to get even the first EAPOL-Key msg 4/4 encrypted if the kernel operations for Data frame transmission and nl80211 key configuration get reordered. Though, if that were to be happening commonly, we would see significantly more issues with this, so I'd assume this is not really the main issue here. I'm not sure why the AP would not accept EAPOL-Key msg 4/4, so it would be interesting to see a wireless capture log to confirm that the first attempt of sending that out did indeed result in the frame going out and doing so without encryption. As far as making this issue less likely to cause
Re: [RFC] mac80211: use rhashtable for station table
2015-02-23 19:33 GMT+03:00 Johannes Berg johan...@sipsolutions.net:
On Sat, 2015-02-14 at 05:14 +0300, Sergey Ryazanov wrote:
A nice change! Couple of years ago I did some tests with real sets of
MACs and jhash gives a better distribution than usage of a last octet.
BTW, why do you use full address and generic jhash? Hashing of two
least significant words could be faster. Isn't it?
Well - not sure what you're trying to say? First you're saying jhash()
was clearly better and then you're saying I shouldn't use it? ;-)
In first case, I mean the jhash _algorithm_, which has a better
distribution, in second case I mean the _generic_ jhash() _function_
and express my doubts about its performance. See below.
Anyway - just using the last two bytes (or even 16-bit words) won't
cover the case where the locally administered bit is set in an otherwise
unchanged address, which is getting more common for P2P.
I also don't really see any major drawbacks to hashing it all?
I agree that hashing all octets is not a drawback. But the jhash()
function is tailored to the input data of variable length, while we
have a vector of fixed length and appropriate functions. Could we do
the hashing in following way:
u32 sta_info_hash(void *addr, u32 len, u32 seed)
{
u32 *k = addr + 2;
return jhash_1word(*k, seed);
}
structu rhashtable_pararms param = {
...
.hashfn = sta_info_hash,
...
}
or even (to account LA bit):
u32 sta_info_hash(void *addr, u32 len, u32 seed)
{
u32 *k = addr;
return jhash_2words(k[0], k[1], seed);
}
structu rhashtable_pararms param = {
...
.key_len = 8,
.hashfn = sta_info_hash,
...
}
This could save a couple of CPU circles and a couple of bytes in the
output image :)
--
Sergey
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AR9462 problems connecting again..
On Mon, Feb 23, 2015 at 12:06:09PM -0800, Linus Torvalds wrote: On Mon, Feb 23, 2015 at 9:17 AM, Jouni Malinen j...@w1.fi wrote: mac80211: Do not encrypt EAPOL frames before peer has used the key Hmm. This patch does not seem to make a difference. I thought it did at first, but then removed the wpa_supplicant debugging, and got the same failures. Interesting. That would seem to imply that this AP does not like something about the EAPOL-Key msg 4/4 from the station during the faster timing (no wpa_supplicant debug) and would even be unable to accept the responses during retransmissions.. I'm not sure what could cause that. Is there anything that the AP could provide as far as logging is concerned? How far is the station from the AP? Would it be possible to see whether the behavior changes if you were within, say, five meters or so? This should allow the higher transmit rate proposed by minstrel_ht to work pretty reliably and that could confirm if this is indeed related to too high a rate being used here and then for some reason being unable to fall back to a sufficiently low rate to work at higher distance. It would be useful if you can capture the 802.11 frame exchange from a failed connection case with an external wireless sniffer. It sounds like this should be doable with iwlwifi and while I haven't tested this myself, I'd assume something like this would do the trick (this is assuming that the interface is not being used at the time, e.g., with wpa_supplicant): sudo iw dev wlan0 set type monitor sudo ip link set wlan0 up sudo iw dev wlan0 set freq 2462 HT20 sudo dumpcap -i wlan0 -w /tmp/wlan0.pcap # test connection and stop dumpcap after the failure # and sudo ip link set wlan0 down; sudo iw dev wlan0 set type station # to restore normal station mode -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Fri, Feb 20, 2015 at 2:58 AM, Krishna Chaitanya
chaitanya.m...@gmail.com wrote:
On Fri, Feb 20, 2015 at 1:00 AM, Krishna Chaitanya
chaitanya.m...@gmail.com wrote:
Hi Johannes,
The BW tracking feature in mac80211 is causing connection problems and
operating mode/bw problems when switching b/w modes and bw's in AP.
For Eg. Initially if AP is operating in VHT-80MHz, and then we changed
in to HT-40MHz, mac80211 cannot handle it because the VHT capability
is mismatched b/w stored info (ifmgd-flags).
I have tried your DISABLE_BW_TRACK patch, that helps making the
connection but it doesn't update the chipset causing issues.
Ideally we should be able to handle all the config changes right?
Before that i have a basic question? Should we reset our tracking after
the connection is lost, in my case above the connection was lost (Config
change in A triggers a reboot), still mac80211 is tracking the BW changes?
Any ideas johannes? Currenlty we kind-of disabled BW tracking as a work around
for this issue.
mlme.c: Removed the capability checks.
if (!cfg80211_chandef_valid(chandef)) {
sdata_info(sdata,
AP %pM chandef invalid - disconnect\n,
ifmgd-bssid);
return -EINVAL;
}
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: rtl8723au: rtl8723a_hal_init.c: remove unnecessary braces
Daniele Alessandrelli daniele.alessandre...@gmail.com writes:
Fix all checkpatch braces {} are not necessary warnings for
rtl8723au/hal/rtl8723a_hal_init.c
Signed-off-by: Daniele Alessandrelli daniele.alessandre...@gmail.com
---
drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 40
---
1 file changed, 14 insertions(+), 26 deletions(-)
Looks good to me.
Acked-by: Jes Sorensen jes.soren...@redhat.com
diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
index a5eadd4..e88d851 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
@@ -424,9 +424,8 @@ hal_ReadEFuse_WiFi(struct rtw_adapter *padapter,
offset = GET_HDR_OFFSET_2_0(efuseHeader);
ReadEFuseByte23a(padapter, eFuse_Addr++, efuseExtHdr);
- if (ALL_WORDS_DISABLED(efuseExtHdr)) {
+ if (ALL_WORDS_DISABLED(efuseExtHdr))
continue;
- }
offset |= ((efuseExtHdr 0xF0) 1);
wden = (efuseExtHdr 0x0F);
@@ -524,9 +523,8 @@ hal_ReadEFuse_BT(struct rtw_adapter *padapter,
ReadEFuseByte23a(padapter, eFuse_Addr++,
efuseExtHdr);
- if (ALL_WORDS_DISABLED(efuseExtHdr)) {
+ if (ALL_WORDS_DISABLED(efuseExtHdr))
continue;
- }
offset |= ((efuseExtHdr 0xF0) 1);
wden = (efuseExtHdr 0x0F);
@@ -630,9 +628,8 @@ u16 rtl8723a_EfuseGetCurrentSize_WiFi(struct rtw_adapter
*padapter)
hoffset = GET_HDR_OFFSET_2_0(efuse_data);
efuse_addr++;
efuse_OneByteRead23a(padapter, efuse_addr, efuse_data);
- if (ALL_WORDS_DISABLED(efuse_data)) {
+ if (ALL_WORDS_DISABLED(efuse_data))
continue;
- }
hoffset |= ((efuse_data 0xF0) 1);
hworden = efuse_data 0x0F;
@@ -721,9 +718,8 @@ u16 rtl8723a_EfuseGetCurrentSize_BT(struct rtw_adapter
*padapter)
}
/* Check if we need to check next bank efuse */
- if (efuse_addr retU2) {
+ if (efuse_addr retU2)
break; /* don't need to check next bank. */
- }
}
retU2 = ((bank - 1) * EFUSE_BT_REAL_BANK_CONTENT_LEN) + efuse_addr;
@@ -1149,9 +1145,8 @@ static int _LLTWrite(struct rtw_adapter *padapter, u32
address, u32 data)
/* polling */
do {
value = rtl8723au_read32(padapter, LLTReg);
- if (_LLT_NO_ACTIVE == _LLT_OP_VALUE(value)) {
+ if (_LLT_NO_ACTIVE == _LLT_OP_VALUE(value))
break;
- }
if (count POLLING_LLT_THRESHOLD) {
RT_TRACE(_module_hal_init_c_, _drv_err_,
@@ -1174,16 +1169,14 @@ int InitLLTTable23a(struct rtw_adapter *padapter, u32
boundary)
for (i = 0; i (txpktbuf_bndy - 1); i++) {
status = _LLTWrite(padapter, i, i + 1);
- if (status != _SUCCESS) {
+ if (status != _SUCCESS)
return status;
- }
}
/* end of list */
status = _LLTWrite(padapter, (txpktbuf_bndy - 1), 0xFF);
- if (status != _SUCCESS) {
+ if (status != _SUCCESS)
return status;
- }
/* Make the other pages as ring buffer */
/* This ring buffer is used as beacon buffer if we config this
@@ -1191,16 +1184,14 @@ int InitLLTTable23a(struct rtw_adapter *padapter, u32
boundary)
/* Otherwise used as local loopback buffer. */
for (i = txpktbuf_bndy; i Last_Entry_Of_TxPktBuf; i++) {
status = _LLTWrite(padapter, i, (i + 1));
- if (_SUCCESS != status) {
+ if (_SUCCESS != status)
return status;
- }
}
/* Let last entry point to the start entry of ring buffer */
status = _LLTWrite(padapter, Last_Entry_Of_TxPktBuf, txpktbuf_bndy);
- if (status != _SUCCESS) {
+ if (status != _SUCCESS)
return status;
- }
return status;
}
@@ -1435,9 +1426,9 @@ static void _DisableAnalog(struct rtw_adapter
*padapter, bool bWithoutHWSM)
/* HW Auto state machine */
int CardDisableHWSM(struct rtw_adapter *padapter, u8 resetMCU)
{
- if (padapter-bSurpriseRemoved) {
+ if (padapter-bSurpriseRemoved)
return _SUCCESS;
- }
+
/* RF Off Sequence */
Re: AR9462 problems connecting again..
On Mon, Feb 23, 2015 at 9:17 AM, Jouni Malinen j...@w1.fi wrote: mac80211: Do not encrypt EAPOL frames before peer has used the key Hmm. This patch does not seem to make a difference. I thought it did at first, but then removed the wpa_supplicant debugging, and got the same failures. On Sun, Feb 22, 2015 at 10:01 PM, Sujith Manoharan suj...@msujith.org wrote: Or 'iw dev wlp1s0 set bitrates ht-mcs-2.4 0' to choose the lowest HT rate. This *might* have worked. But it's a bit hard to really make sure, since it sometimes does succeed even without debugging when I do nothing at all, but it did work twice in a row after doing that. Sporadic association problems could be a problem with the chosen rates. This would show the rates for the EAPOL frames: iw dev wlp1s0 interface add mon0 type monitor ifconfig mon0 up Hmm. I don't actually see a mon0 interface after the iw dev interface add thing. Yes, iw sees it when I do iw dev, but ifconfig does not. This machine has a fairly minimal kernel config. Does that type monitor interface perhaps need some debug infrastructure that I haven't added? tshark -i mon0 -Y eapol -T fields -e radiotap.datarate -e wlan -e eapol -e wlan.sa -e wlan.da .. and then this fails, presumably for similar reasons. Linus -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AR9462 problems connecting again..
On Mon, Feb 23, 2015 at 12:06 PM, Linus Torvalds torva...@linux-foundation.org wrote: This machine has a fairly minimal kernel config. Does that type monitor interface perhaps need some debug infrastructure that I haven't added? Nope. Same behavior with a F21 kernel (which means that the touchpad doesn't work, but that's a separate and known issue with this platform). Linus -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] cfg80211: Allow NL80211_ATTR_IFINDEX to be added to vendor events
+/**
+ * cfg80211_vendor_event_alloc_ext - allocate vendor-specific event
+skb
+ * @wiphy: the wiphy
+ * @event_idx: index of the vendor event in the wiphy's vendor_events
+ * @approxlen: an upper bound of the length of the data that will
+ * be put into the skb
+ * @gfp: allocation flags
+ * @wdev: the wireless device
+ *
+ * This function allocates and pre-fills an skb for an event on the
+ * vendor-specific multicast group. This is otherwise identical to
+ * cfg80211_vendor_event_alloc(), but ifindex of the specified
+wireless device
+ * is added to the event message before the vendor data attribute.
+ *
+ * When done filling the skb, call cfg80211_vendor_event() with the
+ * skb to send the event.
+ *
+ * Return: An allocated and pre-filled skb. %NULL if any errors happen.
+ */
+static inline struct sk_buff *
+cfg80211_vendor_event_alloc_ext(struct wiphy *wiphy, int approxlen,
+ int event_idx, gfp_t gfp,
+ struct wireless_dev *wdev)
+{
+ return __cfg80211_alloc_event_skb(wiphy, NL80211_CMD_VENDOR,
+ NL80211_ATTR_VENDOR_DATA,
+ event_idx, approxlen, gfp, wdev);
}
This doesn't seem necessary, why not just update the original function to add
and document the new optional argument?
[however, in the unlikely even that you can convince me otherwise we may have
to add this to the documentation?]
This means that this kernel change can't be pulled in without corresponding
driver changes to call cfg80211_vendor_event_alloc() with a NULL for wdev.
Please confirm if this is acceptable; otherwise, we would need to use the new
wrapper defined above.
Thanks,
Ahmad Kholaif
N�r��yb�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [RFC] mac80211: use rhashtable for station table
On Tue, 2015-02-24 at 00:26 +0300, Sergey Ryazanov wrote:
Well - not sure what you're trying to say? First you're saying jhash()
was clearly better and then you're saying I shouldn't use it? ;-)
In first case, I mean the jhash _algorithm_, which has a better
distribution, in second case I mean the _generic_ jhash() _function_
and express my doubts about its performance. See below.
Ah.
I agree that hashing all octets is not a drawback. But the jhash()
function is tailored to the input data of variable length, while we
have a vector of fixed length and appropriate functions. Could we do
the hashing in following way:
u32 sta_info_hash(void *addr, u32 len, u32 seed)
{
u32 *k = addr + 2;
return jhash_1word(*k, seed);
}
This would work, but without the LA bit obviously.
or even (to account LA bit):
u32 sta_info_hash(void *addr, u32 len, u32 seed)
{
u32 *k = addr;
return jhash_2words(k[0], k[1], seed);
}
This won't exactly work as there's no known padding there so that k[1]
accesses invalid data, but I get the point. It should then be
This could save a couple of CPU circles and a couple of bytes in the
output image :)
I don't think it would save bytes? The jhash function is common after
all. Ah, but it's an inline, so it would be generated here.
We also can't rely on 4-byte alignment though, so perhaps we should do
something like
u32 sta_info_hash(void *addr, u32 len, u32 seed)
{
u16 *a = addr;
return jhash_3words(a[0], a[1], a[2], seed);
}
instead? Not sure what effect that has on jhash though if we don't have
anything in the high 16 bits.
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AR9462 problems connecting again..
On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen j...@w1.fi wrote: How far is the station from the AP? Would it be possible to see whether the behavior changes if you were within, say, five meters or so? Well, it was pretty much within five meters already, but there was a thin wall in between (and the old AP was right next to the laptop, which might add some noise even if they are on different channels). Going closer does seem to help, but again, it's not like this is 100% reproducible to begin with. So the theory that the driver starts at too high a transmit rate, and then does not handle failures well, might be true. Of course, not handle failures well is something of an understatement. It would be useful if you can capture the 802.11 frame exchange from a failed connection case with an external wireless sniffer. I will try with my (much more reliable) iwlwifi laptop. At least the merge window is over, so I should have some time. Knock wood. Linus -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mac80211: use rhashtable for station table
On Mon, 2015-02-23 at 22:52 +0100, Johannes Berg wrote:
We also can't rely on 4-byte alignment though, so perhaps we should do
something like
u32 sta_info_hash(void *addr, u32 len, u32 seed)
{
u16 *a = addr;
return jhash_3words(a[0], a[1], a[2], seed);
}
Or better do
return jhash_2words(addr[0], (addr[1] 16) | addr[2], seed);
since I have no idea how the missing high 16 bits would behave.
(we can rely on 2-byte alignment, but not 4-byte)
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mac80211: use rhashtable for station table
On Mon, 2015-02-23 at 23:01 +0100, Johannes Berg wrote:
On Mon, 2015-02-23 at 22:52 +0100, Johannes Berg wrote:
We also can't rely on 4-byte alignment though, so perhaps we should do
something like
u32 sta_info_hash(void *addr, u32 len, u32 seed)
{
u16 *a = addr;
return jhash_3words(a[0], a[1], a[2], seed);
}
Or better do
return jhash_2words(addr[0], (addr[1] 16) | addr[2], seed);
since I have no idea how the missing high 16 bits would behave.
(we can rely on 2-byte alignment, but not 4-byte)
Actually, we cannot rely on alignment, so we need to do this:
static u32 sta_addr_hash(const void *key, u32 length, u32 seed)
{
return jhash(key, ETH_ALEN, seed);
}
which still generates better code since the compiler can optimise based
on the fixed length.
johannes
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: use rhashtable for station table
From: Johannes Berg johannes.b...@intel.com
We currently have a hand-rolled table with 256 entries and are
using the last byte of the MAC address as the hash. This hash
is obviously very fast, but collisions are easily created and
we waste a lot of space in the common case of just connecting
as a client to an AP where we just have a single station. The
other common case of an AP is also suboptimal due to the size
of the hash table and the ease of causing collisions.
Convert all of this to use rhashtable with jhash, which gives
us the advantage of a far better hash function (with random
perturbation to avoid hash collision attacks) and of course
that the hash table grows and shrinks dynamically with chain
length, improving both cases above.
Use a specialised hash function (using jhash, but with fixed
length) to achieve better compiler optimisation as suggested
by Sergey Ryazanov.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/main.c| 9 +++--
net/mac80211/rx.c | 4 +-
net/mac80211/sta_info.c| 92 +-
net/mac80211/sta_info.h| 37 +--
net/mac80211/status.c | 4 +-
6 files changed, 64 insertions(+), 85 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 3afe36824703..798392398ab5 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -26,6 +26,7 @@
#include linux/etherdevice.h
#include linux/leds.h
#include linux/idr.h
+#include linux/rhashtable.h
#include net/ieee80211_radiotap.h
#include net/cfg80211.h
#include net/mac80211.h
@@ -1195,7 +1196,7 @@ struct ieee80211_local {
spinlock_t tim_lock;
unsigned long num_sta;
struct list_head sta_list;
- struct sta_info __rcu *sta_hash[STA_HASH_SIZE];
+ struct rhashtable sta_hash;
struct timer_list sta_cleanup;
int sta_generation;
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 5e09d354c5a5..95d59d24b271 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -557,6 +557,9 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t
priv_data_len,
local = wiphy_priv(wiphy);
+ if (sta_info_init(local))
+ goto err_free;
+
local-hw.wiphy = wiphy;
local-hw.priv = (char *)local + ALIGN(sizeof(*local), NETDEV_ALIGN);
@@ -629,8 +632,6 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t
priv_data_len,
spin_lock_init(local-ack_status_lock);
idr_init(local-ack_status_frames);
- sta_info_init(local);
-
for (i = 0; i IEEE80211_MAX_QUEUES; i++) {
skb_queue_head_init(local-pending[i]);
atomic_set(local-agg_queue_stop[i], 0);
@@ -650,6 +651,9 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t
priv_data_len,
ieee80211_roc_setup(local);
return local-hw;
+ err_free:
+ wiphy_free(wiphy);
+ return NULL;
}
EXPORT_SYMBOL(ieee80211_alloc_hw_nm);
@@ -1173,7 +1177,6 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw)
destroy_workqueue(local-workqueue);
wiphy_unregister(local-hw.wiphy);
- sta_info_stop(local);
ieee80211_wep_free(local);
ieee80211_led_exit(local);
kfree(local-int_scan_req);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index ed38d8302659..aa238a66ae2e 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3417,7 +3417,7 @@ static void __ieee80211_rx_handle_packet(struct
ieee80211_hw *hw,
__le16 fc;
struct ieee80211_rx_data rx;
struct ieee80211_sub_if_data *prev;
- struct sta_info *sta, *tmp, *prev_sta;
+ struct sta_info *sta, *prev_sta;
int err = 0;
fc = ((struct ieee80211_hdr *)skb-data)-frame_control;
@@ -3454,7 +3454,7 @@ static void __ieee80211_rx_handle_packet(struct
ieee80211_hw *hw,
if (ieee80211_is_data(fc)) {
prev_sta = NULL;
- for_each_sta_info(local, hdr-addr2, sta, tmp) {
+ for_each_sta_info(local, hdr-addr2, sta) {
if (!prev_sta) {
prev_sta = sta;
continue;
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 00ca8dcc2bcf..db7749347e01 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -68,28 +68,7 @@
static int sta_info_hash_del(struct ieee80211_local *local,
struct sta_info *sta)
{
- struct sta_info *s;
-
- s = rcu_dereference_protected(local-sta_hash[STA_HASH(sta-sta.addr)],
- lockdep_is_held(local-sta_mtx));
- if (!s)
- return -ENOENT;
- if (s == sta) {
- rcu_assign_pointer(local-sta_hash[STA_HASH(sta-sta.addr)],
- s-hnext);
- return 0;
- }
-
- while
Re: [RFC] mac80211: use rhashtable for station table
2015-02-24 1:07 GMT+03:00 Johannes Berg johan...@sipsolutions.net:
On Mon, 2015-02-23 at 23:01 +0100, Johannes Berg wrote:
On Mon, 2015-02-23 at 22:52 +0100, Johannes Berg wrote:
We also can't rely on 4-byte alignment though, so perhaps we should do
something like
u32 sta_info_hash(void *addr, u32 len, u32 seed)
{
u16 *a = addr;
return jhash_3words(a[0], a[1], a[2], seed);
}
Or better do
return jhash_2words(addr[0], (addr[1] 16) | addr[2], seed);
since I have no idea how the missing high 16 bits would behave.
(we can rely on 2-byte alignment, but not 4-byte)
Actually, we cannot rely on alignment, so we need to do this:
static u32 sta_addr_hash(const void *key, u32 length, u32 seed)
{
return jhash(key, ETH_ALEN, seed);
}
which still generates better code since the compiler can optimise based
on the fixed length.
Nice catch!
--
Sergey
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AR9462 problems connecting again..
On 23 February 2015 at 13:53, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen j...@w1.fi wrote: How far is the station from the AP? Would it be possible to see whether the behavior changes if you were within, say, five meters or so? Well, it was pretty much within five meters already, but there was a thin wall in between (and the old AP was right next to the laptop, which might add some noise even if they are on different channels). Going closer does seem to help, but again, it's not like this is 100% reproducible to begin with. So the theory that the driver starts at too high a transmit rate, and then does not handle failures well, might be true. Of course, not handle failures well is something of an understatement. It would be useful if you can capture the 802.11 frame exchange from a failed connection case with an external wireless sniffer. I will try with my (much more reliable) iwlwifi laptop. At least the merge window is over, so I should have some time. Knock wood. Hm, can we just hack mac80211/ath9k to set /all/ EAPOL frames to the lowest negotiated basic rate and test? That way we don't have to worry about things resetting fixed rates or whatnot. I've done that with FreeBSD's atheros/intel drivers and net80211 stack to fix exactly these, although I'm thinking about adding a patch based on Jouni's note about EAPOL encrypting the final response. Does ath9k have an easy interface for dumping out the TX descriptors and response? That way we can see (a) what it's transmitting as, and (b) whether the hardware indicated it got an ACK for the particular frame. -adrian -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: use rhashtable for station table
Err, well, I need to rebase this patch on the changed rhashtable APIs in net-next :) WIP. johannes -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AR9462 problems connecting again..
On Mon, Feb 23, 2015 at 02:22:32PM -0800, Adrian Chadd wrote: On 23 February 2015 at 13:53, Linus Torvalds torva...@linux-foundation.org wrote: So the theory that the driver starts at too high a transmit rate, and then does not handle failures well, might be true. Of course, not handle failures well is something of an understatement. Hm, can we just hack mac80211/ath9k to set /all/ EAPOL frames to the lowest negotiated basic rate and test? That way we don't have to worry about things resetting fixed rates or whatnot. This did not get exactly supportive response when this was proposed last time (Sep 2013). Anyway, for a quick test, this can be done with the following one-liner: diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index c314c59..b45038f 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -566,6 +566,7 @@ ieee80211_tx_h_check_control_port_protocol(struct ieee80211_tx_data *tx) if (tx-sdata-control_port_no_encrypt) info-flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT; info-control.flags |= IEEE80211_TX_CTRL_PORT_CTRL_PROTO; + info-flags |= IEEE80211_TX_CTL_USE_MINRATE; } return TX_CONTINUE; Even I think that this goes a bit too far especially on 2.4 GHz band, but I would actually consider limiting EAPOL frames to using non-HT/VHT (e.g., 6 Mbps OFDM at least for EAPOL-Key frames) to avoid some interoperability issues. I would say that the current minstrel_ht behavior is somewhat excessive for EAPOL-Key frames in the other direction. Using MCS 14 with fallback to something like MCS 5 for the second Data frame after an association can certainly fail. Number of Linux drivers do already limit EAPOL frame TX rate, so this specific item is mainly applicable only to driver that use minstrel from mac80211 (e.g., ath9k). Though, that IEEE80211_TX_CTL_USE_MINRATE would likely affect most mac80211 drivers. -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AR9462 problems connecting again..
On Mon, Feb 23, 2015 at 2:43 PM, Jouni Malinen j...@w1.fi wrote: This did not get exactly supportive response when this was proposed last time (Sep 2013). Anyway, for a quick test, this can be done with the following one-liner: fwiw, that one-liner seems to work fine for me. Which I guess is not a huge surprise. Side note: I've done the turn off wifi and turn it back on several times to test that patch, and it has worked every time. BUT I also see this odd behavior where the logs show that it tries to authenticate twice: the first time it does that send auth to 20:9f .. thing three times (looks like 100ms apart), and nothing happens so it does authentication with 20:9f .. timed out. Then it waits three seconds and tries again, and now it succeeds on the first try. The only downside of that seems to be that it takes an extra 3s to connect to the network - but it does now seem to *reliably* connect - so it's not a big problem, but I wonder why it should be that repeatable. Is there some difference between the first and the second time it tries to authenticate? Anyway, even if people don't like that particular patch, it does seem like *something* like that should be done. Linus -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AR9462 problems connecting again..
Jouni Malinen wrote: Even I think that this goes a bit too far especially on 2.4 GHz band, but I would actually consider limiting EAPOL frames to using non-HT/VHT (e.g., 6 Mbps OFDM at least for EAPOL-Key frames) to avoid some interoperability issues. I would say that the current minstrel_ht behavior is somewhat excessive for EAPOL-Key frames in the other direction. Using MCS 14 with fallback to something like MCS 5 for the second Data frame after an association can certainly fail. Number of Linux drivers do already limit EAPOL frame TX rate, so this specific item is mainly applicable only to driver that use minstrel from mac80211 (e.g., ath9k). Though, that IEEE80211_TX_CTL_USE_MINRATE would likely affect most mac80211 drivers. We had this in the ath9k RC, where EAPOL frames were sent out at min-rate on the VO queue. I think instead of re-introducing it in the driver, having it in minstrel is cleaner. Sujith -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AR9462 problems connecting again..
(sorry to send HTML the first time... oops)
Over the weekend I found a bug in minstrel-ht that might well be
implicated here.
The last retransmit rate is meant to be a 'get the packet there
reliably' rate; minstrel-ht doesn't do that right, and can pick a
fairly flaky rate instead.
Can't generate a proper patch right now, so this diff might not apply
cleanly, but the fix is simply to change 75 to 99 in the two places
below:
@@ -437,7 +448,7 @@ minstrel_ht_set_best_prob_rate(struct mi
(max_tp_group != MINSTREL_CCK_GROUP))
return;
- if (mrs-prob_ewma MINSTREL_FRAC(75, 100)) {
+ if (mrs-prob_ewma MINSTREL_FRAC(99, 100)) {
cur_tp_avg = minstrel_ht_get_tp_avg(mi, cur_group, cur_idx);
if (cur_tp_avg tmp_tp_avg)
mi-max_prob_rate = index;
@@ -526,7 +537,7 @@ minstrel_ht_prob_rate_reduce_streams(str
* Rules for rate selection:
* - max_prob_rate must use only one stream, as a tradeoff between delivery
*probability and throughput during strong fluctuations
- * - as long as the max prob rate has a probability of more than 75%, pick
+ * - as long as the max prob rate has a probability of more than 99%, pick
*higher throughput rates, even if the probablity is a bit lower
*/
static void
On Tue, Feb 24, 2015 at 11:29 AM, Sujith Manoharan suj...@msujith.org wrote:
Jouni Malinen wrote:
Even I think that this goes a bit too far especially on 2.4 GHz band,
but I would actually consider limiting EAPOL frames to using non-HT/VHT
(e.g., 6 Mbps OFDM at least for EAPOL-Key frames) to avoid some
interoperability issues. I would say that the current minstrel_ht
behavior is somewhat excessive for EAPOL-Key frames in the other
direction. Using MCS 14 with fallback to something like MCS 5 for the
second Data frame after an association can certainly fail.
Number of Linux drivers do already limit EAPOL frame TX rate, so this
specific item is mainly applicable only to driver that use minstrel from
mac80211 (e.g., ath9k). Though, that IEEE80211_TX_CTL_USE_MINRATE would
likely affect most mac80211 drivers.
We had this in the ath9k RC, where EAPOL frames were sent out at min-rate
on the VO queue. I think instead of re-introducing it in the driver,
having it in minstrel is cleaner.
Sujith
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mac80211: iterate using station list in AP SMPS
From: Johannes Berg johannes.b...@intel.com
When changing AP SMPS, we need to look up all the stations for this
interface, so there's no reason to iterate over hash chains rather than doing
the simpler iteration over the station list.
Yup - thank you for that.
I remember I tried to find a better to do that when I implemented this back
then, don't why I didn't do what you are doing now...
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/cfg.c | 69
--
1 file changed, 30 insertions(+), 39 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index
dd4ff36c557a..06557e4f9588 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2273,7 +2273,6 @@ int __ieee80211_request_smps_ap(struct
ieee80211_sub_if_data *sdata, {
struct sta_info *sta;
enum ieee80211_smps_mode old_req;
- int i;
if (WARN_ON_ONCE(sdata-vif.type != NL80211_IFTYPE_AP))
return -EINVAL;
@@ -2301,48 +2300,40 @@ int __ieee80211_request_smps_ap(struct
ieee80211_sub_if_data *sdata,
smps_mode, atomic_read(sdata-u.ap.num_mcast_sta));
mutex_lock(sdata-local-sta_mtx);
- for (i = 0; i STA_HASH_SIZE; i++) {
- for (sta = rcu_dereference_protected(sdata-local-
sta_hash[i],
- lockdep_is_held(sdata-local-sta_mtx));
- sta;
- sta = rcu_dereference_protected(sta-hnext,
- lockdep_is_held(sdata-local-sta_mtx))) {
- /*
- * Only stations associated to our AP and
- * associated VLANs
- */
- if (sta-sdata-bss != sdata-u.ap)
- continue;
+ list_for_each_entry(sta, sdata-local-sta_list, list) {
+ /*
+ * Only stations associated to our AP and
+ * associated VLANs
+ */
+ if (sta-sdata-bss != sdata-u.ap)
+ continue;
- /* This station doesn't support MIMO - skip it */
- if (sta_info_tx_streams(sta) == 1)
- continue;
+ /* This station doesn't support MIMO - skip it */
+ if (sta_info_tx_streams(sta) == 1)
+ continue;
- /*
- * Don't wake up a STA just to send the action frame
- * unless we are getting more restrictive.
- */
- if (test_sta_flag(sta, WLAN_STA_PS_STA)
- !ieee80211_smps_is_restrictive(sta-
known_smps_mode,
-smps_mode)) {
- ht_dbg(sdata,
-Won't send SMPS to sleeping STA
%pM\n,
-sta-sta.addr);
- continue;
- }
+ /*
+ * Don't wake up a STA just to send the action frame
+ * unless we are getting more restrictive.
+ */
+ if (test_sta_flag(sta, WLAN_STA_PS_STA)
+ !ieee80211_smps_is_restrictive(sta-known_smps_mode,
+smps_mode)) {
+ ht_dbg(sdata, Won't send SMPS to sleeping STA
%pM\n,
+sta-sta.addr);
+ continue;
+ }
- /*
- * If the STA is not authorized, wait until it gets
- * authorized and the action frame will be sent then.
- */
- if (!test_sta_flag(sta, WLAN_STA_AUTHORIZED))
- continue;
+ /*
+ * If the STA is not authorized, wait until it gets
+ * authorized and the action frame will be sent then.
+ */
+ if (!test_sta_flag(sta, WLAN_STA_AUTHORIZED))
+ continue;
- ht_dbg(sdata, Sending SMPS to %pM\n, sta-
sta.addr);
- ieee80211_send_smps_action(sdata, smps_mode,
-sta-sta.addr,
-sdata-vif.bss_conf.bssid);
- }
+ ht_dbg(sdata, Sending SMPS to %pM\n, sta-sta.addr);
+ ieee80211_send_smps_action(sdata, smps_mode, sta-
sta.addr,
+sdata-vif.bss_conf.bssid);
}
mutex_unlock(sdata-local-sta_mtx);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AR9462 problems connecting again..
On Mon, Feb 23, 2015 at 03:00:39PM -0800, Linus Torvalds wrote: On Mon, Feb 23, 2015 at 2:43 PM, Jouni Malinen j...@w1.fi wrote: This did not get exactly supportive response when this was proposed last time (Sep 2013). Anyway, for a quick test, this can be done with the following one-liner: fwiw, that one-liner seems to work fine for me. Good to know. That seems to confirm that the issue is most likely in some of the higher HT rates not working with that AP for some reason at least for EAPOL frames immediately following the association. This should really have worked since I'm pretty sure minstrel will add a lower MCS index as a fallback rate, but maybe there are some interop issues or just close enough to being below the required signal strength (though, I'd find that somewhat unlikely unless there is something messed up with the antennas etc. taken into account your description on how close the devices are and what's between them). Side note: I've done the turn off wifi and turn it back on several times to test that patch, and it has worked every time. BUT I also see this odd behavior where the logs show that it tries to authenticate twice: the first time it does that send auth to 20:9f .. thing three times (looks like 100ms apart), and nothing happens so it does authentication with 20:9f .. timed out. Then it waits three seconds and tries again, and now it succeeds on the first try. The only downside of that seems to be that it takes an extra 3s to connect to the network - but it does now seem to *reliably* connect - so it's not a big problem, but I wonder why it should be that repeatable. Is there some difference between the first and the second time it tries to authenticate? There have been some issues in this area in the past, but it is a bit difficult to say what could have caused it here without a wireless capture from the operating channel of the AP. It is possible that those Authentication frames were not actually transmitted due to some issue or they could have even been sent out on incorrect channel, etc. That shouldn't really happen that frequently (i.e., others should be seeing and reporting this as well..), but it's possible something gets messed up in channel configuration. Anyway, even if people don't like that particular patch, it does seem like *something* like that should be done. Agreed. Just need to figure out a suitable compromise somewhere in the middle of the minimum and close-to-maximum rates. As far as ath9k is concerned, it would actually support four different rates for retry series where minstrel uses only three, so it would be easy even for that driver on its own to add a lower rate at the end if we cannot find consensus on something more generic in mac80211. That said, I'd rather see minstrel getting more conservative for EAPOL frames. -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2] mac80211: use rhashtable for station table
From: Johannes Berg johannes.b...@intel.com
We currently have a hand-rolled table with 256 entries and are
using the last byte of the MAC address as the hash. This hash
is obviously very fast, but collisions are easily created and
we waste a lot of space in the common case of just connecting
as a client to an AP where we just have a single station. The
other common case of an AP is also suboptimal due to the size
of the hash table and the ease of causing collisions.
Convert all of this to use rhashtable with jhash, which gives
us the advantage of a far better hash function (with random
perturbation to avoid hash collision attacks) and of course
that the hash table grows and shrinks dynamically with chain
length, improving both cases above.
Use a specialised hash function (using jhash, but with fixed
length) to achieve better compiler optimisation as suggested
by Sergey Ryazanov.
NOTE: There are two ugly things - one is the need for RCU in
sta_info_get_bss(), but I think that cannot be avoided;
the other is using internal definitions of rhashtable
in for_each_sta_info() - could be cleaned up?
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/main.c| 9 ++--
net/mac80211/rx.c | 9 +++-
net/mac80211/sta_info.c| 101 ++---
net/mac80211/sta_info.h| 41 +++---
net/mac80211/status.c | 8 +++-
6 files changed, 86 insertions(+), 85 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 3afe36824703..798392398ab5 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -26,6 +26,7 @@
#include linux/etherdevice.h
#include linux/leds.h
#include linux/idr.h
+#include linux/rhashtable.h
#include net/ieee80211_radiotap.h
#include net/cfg80211.h
#include net/mac80211.h
@@ -1195,7 +1196,7 @@ struct ieee80211_local {
spinlock_t tim_lock;
unsigned long num_sta;
struct list_head sta_list;
- struct sta_info __rcu *sta_hash[STA_HASH_SIZE];
+ struct rhashtable sta_hash;
struct timer_list sta_cleanup;
int sta_generation;
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 5e09d354c5a5..95d59d24b271 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -557,6 +557,9 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t
priv_data_len,
local = wiphy_priv(wiphy);
+ if (sta_info_init(local))
+ goto err_free;
+
local-hw.wiphy = wiphy;
local-hw.priv = (char *)local + ALIGN(sizeof(*local), NETDEV_ALIGN);
@@ -629,8 +632,6 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t
priv_data_len,
spin_lock_init(local-ack_status_lock);
idr_init(local-ack_status_frames);
- sta_info_init(local);
-
for (i = 0; i IEEE80211_MAX_QUEUES; i++) {
skb_queue_head_init(local-pending[i]);
atomic_set(local-agg_queue_stop[i], 0);
@@ -650,6 +651,9 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t
priv_data_len,
ieee80211_roc_setup(local);
return local-hw;
+ err_free:
+ wiphy_free(wiphy);
+ return NULL;
}
EXPORT_SYMBOL(ieee80211_alloc_hw_nm);
@@ -1173,7 +1177,6 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw)
destroy_workqueue(local-workqueue);
wiphy_unregister(local-hw.wiphy);
- sta_info_stop(local);
ieee80211_wep_free(local);
ieee80211_led_exit(local);
kfree(local-int_scan_req);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 1101563357ea..f6e17dd5a056 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3417,7 +3417,8 @@ static void __ieee80211_rx_handle_packet(struct
ieee80211_hw *hw,
__le16 fc;
struct ieee80211_rx_data rx;
struct ieee80211_sub_if_data *prev;
- struct sta_info *sta, *tmp, *prev_sta;
+ struct sta_info *sta, *prev_sta;
+ struct rhash_head *tmp;
int err = 0;
fc = ((struct ieee80211_hdr *)skb-data)-frame_control;
@@ -3452,9 +3453,13 @@ static void __ieee80211_rx_handle_packet(struct
ieee80211_hw *hw,
ieee80211_scan_rx(local, skb);
if (ieee80211_is_data(fc)) {
+ const struct bucket_table *tbl;
+
prev_sta = NULL;
- for_each_sta_info(local, hdr-addr2, sta, tmp) {
+ tbl = rht_dereference_rcu(local-sta_hash.tbl,
local-sta_hash);
+
+ for_each_sta_info(local, tbl, hdr-addr2, sta, tmp) {
if (!prev_sta) {
prev_sta = sta;
continue;
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 00ca8dcc2bcf..a86a2e9331cc 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -68,28 +68,7 @@
static int sta_info_hash_del(struct ieee80211_local *local,
[PATCH] mac80211: simplify station assignment in ieee80211_tx_prepare()
From: Johannes Berg johannes.b...@intel.com
There's no need for the second conditional as the same will be
done immediately afterwards if there's no station assigned.
Remove the useless conditional, move fallback assignment into
the else branch and don't try to look up a multicast address
which cannot be found anyway.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/tx.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 88a18ffe2975..76b95ce23113 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1167,13 +1167,9 @@ ieee80211_tx_prepare(struct ieee80211_sub_if_data *sdata,
tx-sta = rcu_dereference(sdata-u.vlan.sta);
if (!tx-sta sdata-dev-ieee80211_ptr-use_4addr)
return TX_DROP;
- } else if (info-flags (IEEE80211_TX_CTL_INJECTED |
- IEEE80211_TX_INTFL_NL80211_FRAME_TX) ||
- tx-sdata-control_port_protocol == tx-skb-protocol) {
+ } else if (!is_multicast_ether_addr(hdr-addr1)) {
tx-sta = sta_info_get_bss(sdata, hdr-addr1);
}
- if (!tx-sta)
- tx-sta = sta_info_get(sdata, hdr-addr1);
if (tx-sta ieee80211_is_data_qos(hdr-frame_control)
!ieee80211_is_qos_nullfunc(hdr-frame_control)
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: iterate using station list in AP SMPS
From: Johannes Berg johannes.b...@intel.com
When changing AP SMPS, we need to look up all the stations
for this interface, so there's no reason to iterate over
hash chains rather than doing the simpler iteration over
the station list.
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/cfg.c | 69 --
1 file changed, 30 insertions(+), 39 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index dd4ff36c557a..06557e4f9588 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2273,7 +2273,6 @@ int __ieee80211_request_smps_ap(struct
ieee80211_sub_if_data *sdata,
{
struct sta_info *sta;
enum ieee80211_smps_mode old_req;
- int i;
if (WARN_ON_ONCE(sdata-vif.type != NL80211_IFTYPE_AP))
return -EINVAL;
@@ -2301,48 +2300,40 @@ int __ieee80211_request_smps_ap(struct
ieee80211_sub_if_data *sdata,
smps_mode, atomic_read(sdata-u.ap.num_mcast_sta));
mutex_lock(sdata-local-sta_mtx);
- for (i = 0; i STA_HASH_SIZE; i++) {
- for (sta = rcu_dereference_protected(sdata-local-sta_hash[i],
- lockdep_is_held(sdata-local-sta_mtx));
-sta;
-sta = rcu_dereference_protected(sta-hnext,
- lockdep_is_held(sdata-local-sta_mtx))) {
- /*
-* Only stations associated to our AP and
-* associated VLANs
-*/
- if (sta-sdata-bss != sdata-u.ap)
- continue;
+ list_for_each_entry(sta, sdata-local-sta_list, list) {
+ /*
+* Only stations associated to our AP and
+* associated VLANs
+*/
+ if (sta-sdata-bss != sdata-u.ap)
+ continue;
- /* This station doesn't support MIMO - skip it */
- if (sta_info_tx_streams(sta) == 1)
- continue;
+ /* This station doesn't support MIMO - skip it */
+ if (sta_info_tx_streams(sta) == 1)
+ continue;
- /*
-* Don't wake up a STA just to send the action frame
-* unless we are getting more restrictive.
-*/
- if (test_sta_flag(sta, WLAN_STA_PS_STA)
- !ieee80211_smps_is_restrictive(sta-known_smps_mode,
- smps_mode)) {
- ht_dbg(sdata,
- Won't send SMPS to sleeping STA %pM\n,
- sta-sta.addr);
- continue;
- }
+ /*
+* Don't wake up a STA just to send the action frame
+* unless we are getting more restrictive.
+*/
+ if (test_sta_flag(sta, WLAN_STA_PS_STA)
+ !ieee80211_smps_is_restrictive(sta-known_smps_mode,
+ smps_mode)) {
+ ht_dbg(sdata, Won't send SMPS to sleeping STA %pM\n,
+ sta-sta.addr);
+ continue;
+ }
- /*
-* If the STA is not authorized, wait until it gets
-* authorized and the action frame will be sent then.
-*/
- if (!test_sta_flag(sta, WLAN_STA_AUTHORIZED))
- continue;
+ /*
+* If the STA is not authorized, wait until it gets
+* authorized and the action frame will be sent then.
+*/
+ if (!test_sta_flag(sta, WLAN_STA_AUTHORIZED))
+ continue;
- ht_dbg(sdata, Sending SMPS to %pM\n, sta-sta.addr);
- ieee80211_send_smps_action(sdata, smps_mode,
- sta-sta.addr,
- sdata-vif.bss_conf.bssid);
- }
+ ht_dbg(sdata, Sending SMPS to %pM\n, sta-sta.addr);
+ ieee80211_send_smps_action(sdata, smps_mode, sta-sta.addr,
+ sdata-vif.bss_conf.bssid);
}
mutex_unlock(sdata-local-sta_mtx);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
