* [PATCH] mac80211: Add RX flag to indicate ICV stripped
From: Johannes Berg @ 2017-01-11 15:41 UTC (permalink / raw)
To: linux-wireless; +Cc: David Spinadel
From: David Spinadel <david.spinadel@intel.com>
Add a flag that indicates that the WEP ICV was stripped from an
RX packet, allowing the device to not transfer that if it's
already checked.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/mac80211.h | 5 ++++-
net/mac80211/wep.c | 3 ++-
net/mac80211/wpa.c | 3 ++-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 5f5cb194cd78..86967b85dfd0 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1017,7 +1017,7 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
* @RX_FLAG_DECRYPTED: This frame was decrypted in hardware.
* @RX_FLAG_MMIC_STRIPPED: the Michael MIC is stripped off this frame,
* verification has been done by the hardware.
- * @RX_FLAG_IV_STRIPPED: The IV/ICV are stripped from this frame.
+ * @RX_FLAG_IV_STRIPPED: The IV and ICV are stripped from this frame.
* If this flag is set, the stack cannot do any replay detection
* hence the driver or hardware will have to do that.
* @RX_FLAG_PN_VALIDATED: Currently only valid for CCMP/GCMP frames, this
@@ -1088,6 +1088,8 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
* @RX_FLAG_ALLOW_SAME_PN: Allow the same PN as same packet before.
* This is used for AMSDU subframes which can have the same PN as
* the first subframe.
+ * @RX_FLAG_ICV_STRIPPED: The ICV is stripped from this frame. CRC checking must
+ * be done in the hardware.
*/
enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR = BIT(0),
@@ -1123,6 +1125,7 @@ enum mac80211_rx_flags {
RX_FLAG_RADIOTAP_VENDOR_DATA = BIT(31),
RX_FLAG_MIC_STRIPPED = BIT_ULL(32),
RX_FLAG_ALLOW_SAME_PN = BIT_ULL(33),
+ RX_FLAG_ICV_STRIPPED = BIT_ULL(34),
};
#define RX_FLAG_STBC_SHIFT 26
diff --git a/net/mac80211/wep.c b/net/mac80211/wep.c
index efa3f48f1ec5..73e8f347802e 100644
--- a/net/mac80211/wep.c
+++ b/net/mac80211/wep.c
@@ -293,7 +293,8 @@ ieee80211_crypto_wep_decrypt(struct ieee80211_rx_data *rx)
return RX_DROP_UNUSABLE;
ieee80211_wep_remove_iv(rx->local, rx->skb, rx->key);
/* remove ICV */
- if (pskb_trim(rx->skb, rx->skb->len - IEEE80211_WEP_ICV_LEN))
+ if (!(status->flag & RX_FLAG_ICV_STRIPPED) &&
+ pskb_trim(rx->skb, rx->skb->len - IEEE80211_WEP_ICV_LEN))
return RX_DROP_UNUSABLE;
}
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index 8af6dd388d11..c1ef22df865f 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -294,7 +294,8 @@ ieee80211_crypto_tkip_decrypt(struct ieee80211_rx_data *rx)
return RX_DROP_UNUSABLE;
/* Trim ICV */
- skb_trim(skb, skb->len - IEEE80211_TKIP_ICV_LEN);
+ if (!(status->flag & RX_FLAG_ICV_STRIPPED))
+ skb_trim(skb, skb->len - IEEE80211_TKIP_ICV_LEN);
/* Remove IV */
memmove(skb->data + IEEE80211_TKIP_IV_LEN, skb->data, hdrlen);
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] mac80211: calculate min channel width correctly
From: Johannes Berg @ 2017-01-11 15:37 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <20170111153748.797-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
In the current minimum chandef code there's an issue in that the
recalculation can happen after rate control is initialized for a
station that has a wider bandwidth than the current chanctx, and
then rate control can immediately start using those higher rates
which could cause problems.
Observe that first of all that this problem is because we don't
take non-associated and non-uploaded stations into account. The
restriction to non-associated is quite pointless and is one of
the causes for the problem described above, since the rate init
will happen before the station is set to associated; no frames
could actually be sent until associated, but the rate table can
already contain higher rates and that might cause problems.
Also, rejecting non-uploaded stations is wrong, since the rate
control can select higher rates for those as well.
Secondly, it's then necessary to recalculate the minimal config
before initializing rate control, so that when rate control is
initialized, the higher rates are already available. This can be
done easily by adding the necessary function call in rate init.
Change-Id: Ib9bc02d34797078db55459d196993f39dcd43070
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/chan.c | 3 ---
net/mac80211/rate.c | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index e75cbf6ecc26..a0d901d8992e 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -231,9 +231,6 @@ ieee80211_get_max_required_bw(struct ieee80211_sub_if_data *sdata)
!(sta->sdata->bss && sta->sdata->bss == sdata->bss))
continue;
- if (!sta->uploaded || !test_sta_flag(sta, WLAN_STA_ASSOC))
- continue;
-
max_bw = max(max_bw, ieee80211_get_sta_bw(&sta->sta));
}
rcu_read_unlock();
diff --git a/net/mac80211/rate.c b/net/mac80211/rate.c
index 206698bc93f4..9e2641d45587 100644
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -40,6 +40,8 @@ void rate_control_rate_init(struct sta_info *sta)
ieee80211_sta_set_rx_nss(sta);
+ ieee80211_recalc_min_chandef(sta->sdata);
+
if (!ref)
return;
--
2.9.3
^ permalink raw reply related
* [PATCH 3/3] mac80211: recalculate min channel width on VHT opmode changes
From: Johannes Berg @ 2017-01-11 15:37 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <20170111153748.797-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
When an associated station changes its VHT operating mode this
can/will affect the bandwidth it's using, and consequently we
must recalculate the minimum bandwidth we need to use. Failure
to do so can lead to one of two scenarios:
1) we use a too high bandwidth, this is benign
2) we use a too narrow bandwidth, causing rate control and
actual PHY configuration to be out of sync, which can in
turn cause problems/crashes
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/iface.c | 21 +++++++++++++++++++++
net/mac80211/rx.c | 9 +--------
net/mac80211/vht.c | 4 +++-
3 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 41497b670e2b..d37ae7dc114b 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -6,6 +6,7 @@
* Copyright (c) 2006 Jiri Benc <jbenc@suse.cz>
* Copyright 2008, Johannes Berg <johannes@sipsolutions.net>
* Copyright 2013-2014 Intel Mobile Communications GmbH
+ * Copyright (c) 2016 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -1295,6 +1296,26 @@ static void ieee80211_iface_work(struct work_struct *work)
} else if (ieee80211_is_action(mgmt->frame_control) &&
mgmt->u.action.category == WLAN_CATEGORY_VHT) {
switch (mgmt->u.action.u.vht_group_notif.action_code) {
+ case WLAN_VHT_ACTION_OPMODE_NOTIF: {
+ struct ieee80211_rx_status *status;
+ enum nl80211_band band;
+ u8 opmode;
+
+ status = IEEE80211_SKB_RXCB(skb);
+ band = status->band;
+ opmode = mgmt->u.action.u.vht_opmode_notif.operating_mode;
+
+ mutex_lock(&local->sta_mtx);
+ sta = sta_info_get_bss(sdata, mgmt->sa);
+
+ if (sta)
+ ieee80211_vht_handle_opmode(sdata, sta,
+ opmode,
+ band);
+
+ mutex_unlock(&local->sta_mtx);
+ break;
+ }
case WLAN_VHT_ACTION_GROUPID_MGMT:
ieee80211_process_mu_groups(sdata, mgmt);
break;
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index c87e61358b77..3090dd4342f6 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2881,17 +2881,10 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)
switch (mgmt->u.action.u.vht_opmode_notif.action_code) {
case WLAN_VHT_ACTION_OPMODE_NOTIF: {
- u8 opmode;
-
/* verify opmode is present */
if (len < IEEE80211_MIN_ACTION_SIZE + 2)
goto invalid;
-
- opmode = mgmt->u.action.u.vht_opmode_notif.operating_mode;
-
- ieee80211_vht_handle_opmode(rx->sdata, rx->sta,
- opmode, status->band);
- goto handled;
+ goto queue;
}
case WLAN_VHT_ACTION_GROUPID_MGMT: {
if (len < IEEE80211_MIN_ACTION_SIZE + 25)
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index 6832bf6ab69f..43e45bb660bc 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -527,8 +527,10 @@ void ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
u32 changed = __ieee80211_vht_handle_opmode(sdata, sta, opmode, band);
- if (changed > 0)
+ if (changed > 0) {
+ ieee80211_recalc_min_chandef(sdata);
rate_control_rate_update(local, sband, sta, changed);
+ }
}
void ieee80211_get_vht_mask_from_cap(__le16 vht_cap,
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] cfg80211: consider VHT opmode on station update
From: Johannes Berg @ 2017-01-11 15:37 UTC (permalink / raw)
To: linux-wireless; +Cc: Beni Lev
From: Beni Lev <beni.lev@intel.com>
Currently, this attribute is only fetched on station addition, but
not on station change. Since this info is only present in the assoc
request, with full station state support in the driver it cannot be
present when the station is added.
Thus, add support for changing the VHT opmode on station update if
done before (or while) the station is marked as associated. After
this, ignore it, since it used to be ignored.
Signed-off-by: Beni Lev <beni.lev@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/uapi/linux/nl80211.h | 4 +++-
net/wireless/nl80211.c | 15 +++++++++++++++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6b76e3b0c18e..bea982af9cfb 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1772,7 +1772,9 @@ enum nl80211_commands {
*
* @NL80211_ATTR_OPMODE_NOTIF: Operating mode field from Operating Mode
* Notification Element based on association request when used with
- * %NL80211_CMD_NEW_STATION; u8 attribute.
+ * %NL80211_CMD_NEW_STATION or %NL80211_CMD_SET_STATION (only when
+ * %NL80211_FEATURE_FULL_AP_CLIENT_STATE is supported, or with TDLS);
+ * u8 attribute.
*
* @NL80211_ATTR_VENDOR_ID: The vendor ID, either a 24-bit OUI or, if
* %NL80211_VENDOR_ID_IS_LINUX is set, a special Linux ID (not used yet)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ef5eff93a8b8..5c1b267e22be 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4615,6 +4615,15 @@ int cfg80211_check_station_change(struct wiphy *wiphy,
break;
}
+ /*
+ * Older kernel versions ignored this attribute entirely, so don't
+ * reject attempts to update it but mark it as unused instead so the
+ * driver won't look at the data.
+ */
+ if (statype != CFG80211_STA_AP_CLIENT_UNASSOC &&
+ statype != CFG80211_STA_TDLS_PEER_SETUP)
+ params->opmode_notif_used = false;
+
return 0;
}
EXPORT_SYMBOL(cfg80211_check_station_change);
@@ -4854,6 +4863,12 @@ static int nl80211_set_station(struct sk_buff *skb, struct genl_info *info)
params.local_pm = pm;
}
+ if (info->attrs[NL80211_ATTR_OPMODE_NOTIF]) {
+ params.opmode_notif_used = true;
+ params.opmode_notif =
+ nla_get_u8(info->attrs[NL80211_ATTR_OPMODE_NOTIF]);
+ }
+
/* Include parameters for TDLS peer (will check later) */
err = nl80211_set_station_tdls(info, ¶ms);
if (err)
--
2.9.3
^ permalink raw reply related
* [PATCH] mac80211: fix the TID on NDPs sent as EOSP carrier
From: Johannes Berg @ 2017-01-11 15:37 UTC (permalink / raw)
To: linux-wireless; +Cc: Emmanuel Grumbach
From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In the commit below, I forgot to translate the mac80211's
AC to QoS IE order. Moreover, the condition in the if was
wrong. Fix both issues.
This bug would hit only with clients that didn't set all
the ACs as delivery enabled.
Fixes: f438ceb81d4 ("mac80211: uapsd_queues is in QoS IE order")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/sta_info.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index b6cfcf038c11..50c309094c37 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -1501,8 +1501,8 @@ ieee80211_sta_ps_deliver_response(struct sta_info *sta,
/* This will evaluate to 1, 3, 5 or 7. */
for (ac = IEEE80211_AC_VO; ac < IEEE80211_NUM_ACS; ac++)
- if (ignored_acs & BIT(ac))
- continue;
+ if (!(ignored_acs & ieee80211_ac_to_qos_mask[ac]))
+ break;
tid = 7 - 2 * ac;
ieee80211_send_null_response(sta, tid, reason, true, false);
--
2.9.3
^ permalink raw reply related
* Re: mac80211: Fix headroom allocation when forwarding mesh pkt
From: Johannes Berg @ 2017-01-11 15:08 UTC (permalink / raw)
To: Cedric Izoard, linux-wireless@vger.kernel.org
In-Reply-To: <e3b7a95724944c6aadc8512eadfe1c1d@ceva-dsp.com>
On Wed, 2017-01-11 at 14:39 +0000, Cedric Izoard wrote:
> This patch fix issue introduced by commit
> "mac80211: Ensure enough headroom when forwarding mesh pkt"
I reworded that, and replaced the commit reference with a Fixes: tag,
please try to do that in the future.
Applied, but I also reindented that to match the expression.
johannes
^ permalink raw reply
* Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Johannes Berg @ 2017-01-11 15:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-wireless, David S. Miller, Networking, linux-kernel
In-Reply-To: <CAK8P3a2mOT=BG=9yxJ1e-q__5FYq6dfF3t3bT1vqcgFaQAUjog@mail.gmail.com>
On Wed, 2017-01-11 at 16:00 +0100, Arnd Bergmann wrote:
> On Wed, Jan 11, 2017 at 3:38 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
> > > This works fine here because iwe->u.data.length is guaranteed to
> > > be
> > > NULL, and the memcpy doesn't actually have an effect.
> >
> > I think you mean 0, not NULL, but I can fix that when I apply it.
>
> Right, thanks!
Applied. Also fixed the typo in the subject :)
johannes
^ permalink raw reply
* Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Arnd Bergmann @ 2017-01-11 15:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, David S. Miller, Networking, linux-kernel
In-Reply-To: <1484145522.29931.13.camel@sipsolutions.net>
On Wed, Jan 11, 2017 at 3:38 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
>> This works fine here because iwe->u.data.length is guaranteed to be
>> NULL, and the memcpy doesn't actually have an effect.
>
> I think you mean 0, not NULL, but I can fix that when I apply it.
Right, thanks!
Arnd
^ permalink raw reply
* mac80211: Fix headroom allocation when forwarding mesh pkt
From: Cedric Izoard @ 2017-01-11 14:39 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
This patch fix issue introduced by commit
"mac80211: Ensure enough headroom when forwarding mesh pkt"
When forwarding mesh pkt, mac80211 may also add security header,
and it must therefore be taken into account in the needed headroom.
Signed-off-by: Cedric Izoard <cedric.izoard@ceva-dsp.com>
---
net/mac80211/rx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index c037c5b..e376093 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2472,7 +2472,8 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
if (!ifmsh->mshcfg.dot11MeshForwarding)
goto out;
- fwd_skb = skb_copy_expand(skb, local->tx_headroom, 0, GFP_ATOMIC);
+ fwd_skb = skb_copy_expand(skb, local->tx_headroom +
+ sdata->encrypt_headroom, 0, GFP_ATOMIC);
if (!fwd_skb) {
net_info_ratelimited("%s: failed to clone mesh frame\n",
sdata->name);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Johannes Berg @ 2017-01-11 14:38 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-wireless, David S. Miller, netdev, linux-kernel
In-Reply-To: <20170111143532.485827-1-arnd@arndb.de>
On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
> gcc-7 complains that wl3501_cs passes NULL into a function that
> then uses the argument as the input for memcpy:
>
> drivers/net/wireless/wl3501_cs.c: In function 'wl3501_get_scan':
> include/net/iw_handler.h:559:3: error: argument 2 null where non-null
> expected [-Werror=nonnull]
> memcpy(stream + point_len, extra, iwe->u.data.length);
I love wext ;-)
> This works fine here because iwe->u.data.length is guaranteed to be
> NULL, and the memcpy doesn't actually have an effect.
I think you mean 0, not NULL, but I can fix that when I apply it.
johannes
^ permalink raw reply
* [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Arnd Bergmann @ 2017-01-11 14:35 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Arnd Bergmann, David S. Miller, Johannes Berg,
netdev, linux-kernel
gcc-7 complains that wl3501_cs passes NULL into a function that
then uses the argument as the input for memcpy:
drivers/net/wireless/wl3501_cs.c: In function 'wl3501_get_scan':
include/net/iw_handler.h:559:3: error: argument 2 null where non-null expected [-Werror=nonnull]
memcpy(stream + point_len, extra, iwe->u.data.length);
This works fine here because iwe->u.data.length is guaranteed to be
NULL, and the memcpy doesn't actually have an effect.
Making the length check explicit avoids the warning and should have
no other effect here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/net/iw_handler.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/net/iw_handler.h b/include/net/iw_handler.h
index e0f4109e64c6..1a41043688bc 100644
--- a/include/net/iw_handler.h
+++ b/include/net/iw_handler.h
@@ -556,7 +556,8 @@ iwe_stream_add_point(struct iw_request_info *info, char *stream, char *ends,
memcpy(stream + lcp_len,
((char *) &iwe->u) + IW_EV_POINT_OFF,
IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
- memcpy(stream + point_len, extra, iwe->u.data.length);
+ if (iwe->u.data.length)
+ memcpy(stream + point_len, extra, iwe->u.data.length);
stream += event_len;
}
return stream;
--
2.9.0
^ permalink raw reply related
* RE: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Cedric Izoard @ 2017-01-11 13:41 UTC (permalink / raw)
To: Johannes Berg, Masashi Honma, linux-wireless@vger.kernel.org
In-Reply-To: <1484141660.29931.11.camel@sipsolutions.net>
PiA+IFdoZW4gY2FsbGluZyBkcnZfdHgoKSB0aGUgaGVhZHJvb20gaXMgbm90IGJpZyBlbm91Z2gg
Zm9yIHRoZSBkcml2ZXIuDQo+IA0KPiBPay4NCj4gDQo+ID4gPg0KPiA+ID4gTWF5YmUgd2UncmUg
YWRkaW5nIHNvbWV0aGluZyBlbHNlIHRvIHRoaXMgc2tiPw0KPiA+ID4NCj4gPiA+IEkgY2FuJ3Qg
ZmluZCBhbnl0aGluZyBpbiB0aGUgYXRoOWtfaHRjIGRyaXZlciB0aGF0J3MgYWRkaW5nIG1vcmUN
Cj4gPiA+IHRoYW4NCj4gPiA+IDIzIGJ5dGVzIChpdCdzIGFkdmVydGlzaW5nIDI0KSBidXQgY2xl
YXJseSB0aGUgbGFzdCA4IGJ5dGVzIGhlcmUgYXJlDQo+ID4gPiBmYWlsaW5nOg0KPiA+ID4NCj4g
PiA+ID4gW8KgwqDCoDgzLjIwMDM0Nl0gc2tidWZmOiBza2JfdW5kZXJfcGFuaWM6IHRleHQ6ZmZm
ZmZmZmZhMDM0YzAyOA0KPiA+ID4gPiBsZW46MTU0DQo+ID4gPiA+IHB1dDo4IGhlYWQ6ZmZmZjg4
MDIxMzQyMmUwMCBkYXRhOmZmZmY4ODAyMTM0MjJkZmEgdGFpbDoweDk0DQo+ID4gPiA+IGVuZDow
eGMwDQo+ID4gPiA+IGRldjo8TlVMTD4NCj4gPiA+DQo+ID4gPiBNYXliZSBtYWM4MDIxMSBpcyBw
dXR0aW5nIHNvbWV0aGluZyBlbHNlPyBJdCdkIGhhdmUgdG8gYmUNCj4gPg0KPiA+IHllcyBtYWM4
MDIxMSBpcyBhZGRpbmcgdGhlIHNlY3VyaXR5IGhlYWRlci4NCj4gPiBoZWFkcm9vbSBhc2tlZCB0
byBza2JfY29weV9leHBhbmQgc2hvdWxkIGFsc28gdGFrZSBzZGF0YS0NCj4gPiA+ZW5jcnlwdF9o
ZWFkcm9vbSBpbnRvIGFjY291bnQuDQo+IA0KPiBJIHN1c3BlY3RlZCB0aGF0LCBzaW5jZSBpdCB3
YXMgYWJvdXQgdGhlIG9ubHkgcGxhY2UgdGhhdCB3YXMgYWRkaW5nIGFueXRoaW5nLA0KPiBidXQg
SSBjb3VsZG4ndCB0ZXN0IGl0IDopDQo+IA0KPiBDYW4geW91IHNlbmQgYSBwYXRjaD8NCg0KU3Vy
ZSwgSSB3aWxsIHNlbmQgYSBwYXRjaC4NCg0KY2VkcmljDQo=
^ permalink raw reply
* RE: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Cedric Izoard @ 2017-01-11 13:22 UTC (permalink / raw)
To: Johannes Berg, Masashi Honma, linux-wireless@vger.kernel.org
In-Reply-To: <1484136355.29931.1.camel@sipsolutions.net>
PiA+IEhlcmUgaXMgdGhlIHN0YWNrIHRyYWNlIEkgZ2V0Og0KPiA+IEkgYWRkZWQgYSB0cmFjZSBi
ZWZvcmUgY2FsbGluZyBza2JfY29weV9leHBhbmQgdG8gZ2V0IHRoZSBoZWFkcm9vbSBvZg0KPiA+
IHRoZSBidWZmZXIgYmVmb3JlIHRoZSBjb3B5IGFuZCB0aGUgaGVhZHJvb20gYXNrZWQgYnkgdGhl
IGRyaXZlci4NCj4gPg0KPiA+IFvCoMKgwqA4My4yMDAyNjFdIE1FU0ggZndkOiBza2JfaGVhZHJv
b209MTU0LCBuZWVkZWQgaGVhZHJvb209MjQNCj4gDQo+IENvdWxkIHlvdSBhbHNvIGFkZCBhIHNp
bWlsYXIgdHJhY2UganVzdCBiZWZvcmUgY2FsbGluZyBkcnZfdHgoKT8NCg0KV2hlbiBjYWxsaW5n
IGRydl90eCgpIHRoZSBoZWFkcm9vbSBpcyBub3QgYmlnIGVub3VnaCBmb3IgdGhlIGRyaXZlci4N
Cg0KPiANCj4gTWF5YmUgd2UncmUgYWRkaW5nIHNvbWV0aGluZyBlbHNlIHRvIHRoaXMgc2tiPw0K
PiANCj4gSSBjYW4ndCBmaW5kIGFueXRoaW5nIGluIHRoZSBhdGg5a19odGMgZHJpdmVyIHRoYXQn
cyBhZGRpbmcgbW9yZSB0aGFuDQo+IDIzIGJ5dGVzIChpdCdzIGFkdmVydGlzaW5nIDI0KSBidXQg
Y2xlYXJseSB0aGUgbGFzdCA4IGJ5dGVzIGhlcmUgYXJlDQo+IGZhaWxpbmc6DQo+IA0KPiA+IFvC
oMKgwqA4My4yMDAzNDZdIHNrYnVmZjogc2tiX3VuZGVyX3BhbmljOiB0ZXh0OmZmZmZmZmZmYTAz
NGMwMjggbGVuOjE1NA0KPiA+IHB1dDo4IGhlYWQ6ZmZmZjg4MDIxMzQyMmUwMCBkYXRhOmZmZmY4
ODAyMTM0MjJkZmEgdGFpbDoweDk0IGVuZDoweGMwDQo+ID4gZGV2OjxOVUxMPg0KPiANCj4gTWF5
YmUgbWFjODAyMTEgaXMgcHV0dGluZyBzb21ldGhpbmcgZWxzZT8gSXQnZCBoYXZlIHRvIGJlDQoN
CnllcyBtYWM4MDIxMSBpcyBhZGRpbmcgdGhlIHNlY3VyaXR5IGhlYWRlci4NCmhlYWRyb29tIGFz
a2VkIHRvIHNrYl9jb3B5X2V4cGFuZCBzaG91bGQgYWxzbyB0YWtlIHNkYXRhLT5lbmNyeXB0X2hl
YWRyb29tIGludG8gYWNjb3VudC4NCg0KY2VkcmljDQo=
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Johannes Berg @ 2017-01-11 13:34 UTC (permalink / raw)
To: Cedric Izoard, Masashi Honma, linux-wireless@vger.kernel.org
In-Reply-To: <2b0df84e78434d11af1089e82485704b@ceva-dsp.com>
> When calling drv_tx() the headroom is not big enough for the driver.
Ok.
> >
> > Maybe we're adding something else to this skb?
> >
> > I can't find anything in the ath9k_htc driver that's adding more
> > than
> > 23 bytes (it's advertising 24) but clearly the last 8 bytes here
> > are
> > failing:
> >
> > > [ 83.200346] skbuff: skb_under_panic: text:ffffffffa034c028
> > > len:154
> > > put:8 head:ffff880213422e00 data:ffff880213422dfa tail:0x94
> > > end:0xc0
> > > dev:<NULL>
> >
> > Maybe mac80211 is putting something else? It'd have to be
>
> yes mac80211 is adding the security header.
> headroom asked to skb_copy_expand should also take sdata-
> >encrypt_headroom into account.
I suspected that, since it was about the only place that was adding
anything, but I couldn't test it :)
Can you send a patch?
johannes
^ permalink raw reply
* Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout
From: Johannes Berg @ 2017-01-11 13:31 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, Purushottam Kushwaha
In-Reply-To: <1483984388-30237-3-git-send-email-jouni@qca.qualcomm.com>
> + * @timeout_reason: reason for connection timeout. This is used when
> the
> + * connection fails due to a timeout instead of an explicit
> rejection from
> + * the AP. 0 (NL80211_CONNECT_TIMEOUT_UNSPECIFIED) is used
> for other cases.
I think this description is misleading - one could easily understand
"for other cases" to indicate for the cases that the AP did explicitly
reject it, but that's obviously not true.
Perhaps that could be reworded, to say it's used when it's not known,
or such? I'd not indicate the value (0) either, just specify the name,
and put a % in front to get better formatting for it please.
> + resp_ie_len, status, gfp,
> + NL80211_TIMEOUT_UNSPECIFIED);
> }
NL80211_CONNECT_TIMEOUT_UNSPECIFIED in the comment is wrong then.
johannes
^ permalink raw reply
* Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout
From: Johannes Berg @ 2017-01-11 13:26 UTC (permalink / raw)
To: Malinen, Jouni, Arend Van Spriel
Cc: linux-wireless@vger.kernel.org, Kushwaha, Purushottam
In-Reply-To: <20170111131335.GB27748@jouni.qca.qualcomm.com>
On Wed, 2017-01-11 at 13:13 +0000, Malinen, Jouni wrote:
>
> > > @@ -172,6 +174,7 @@ static int cfg80211_conn_do_work(struct
> > > wireless_dev *wdev)
> > > case CFG80211_CONN_AUTH_FAILED:
> > > + *treason = NL80211_TIMEOUT_AUTH;
> >
> > ... but it seems AUTH failure always is a timeout?
>
> The CFG80211_CONN_AUTH_FAILED case is currently used only in
> cfg80211_sme_auth_timeout() which is indeed always a timeout.
Might be worth simply renaming it, since you have the reason there
unconditionally?
johannes
^ permalink raw reply
* Re: [PATCH v2 2/3] cfg80211: Add support to randomize TA of Public Action frames
From: Johannes Berg @ 2017-01-11 13:25 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1483984388-30237-2-git-send-email-jouni@qca.qualcomm.com>
On Mon, 2017-01-09 at 19:53 +0200, Jouni Malinen wrote:
>
> + if (!wdev->current_bss &&
> + !wiphy_ext_feature_isset(
> + &rdev->wiphy,
> + NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA))
> + return -EINVAL;
> + if (wdev->current_bss &&
> + !wiphy_ext_feature_isset(
> + &rdev->wiphy,
> + NL80211_EXT_FEATURE_MGMT_TX_RANDOM_TA_CO
> NNECTED))
> + return -EINVAL;
> + }
This current_bss stuff is going to be somewhat racy, but I guess we can
live with that.
Looks good, but doesn't apply without the first patch.
johannes
^ permalink raw reply
* Re: [PATCH v3 1/3] cfg80211: Add support to sched scan to report better BSSs
From: Johannes Berg @ 2017-01-11 13:22 UTC (permalink / raw)
To: Vamsi, Krishna, Arend Van Spriel, Malinen, Jouni
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <54d6fd2bc55f4c9290402e692ed27005@aphydexm01b.ap.qualcomm.com>
On Wed, 2017-01-11 at 07:48 +0000, Vamsi, Krishna wrote:
> > -----Original Message-----
>
>
> > > + * @relative_rssi_set: Indicates whether @relative_rssi is set
> > > or not.
> >
> > So you see a use-case for doing a scan with @relative_rssi being
> > zero, right?
>
> Yes. Zero value for relative_rssi is also valid.
Or negative even, I guess?
> > > + * @relative_rssi: Relative RSSI threshold in dB to restrict
> > > scan result
> > > + * reporting in connected state to cases where a matching
> > > BSS is
> >
> > determined
> > > + * to have better RSSI than the current connected BSS.
> > > The relative RSSI
> > > + * threshold values are ignored in disconnected state.
> >
> > The description says "better RSSI" so I suppose it could be typed
> > as u8. The last sentence is intended driver behavior
>
> I like to leave this as s8 only. This will leave more flexibility to
> userspace especially in case of more than two bands in future.
I guess you should reword that - instead of "better" it should say how
this value is applied, as a delta to the current RSSI, and then
reporting the result.
However, I don't understand your comment about this being related to
multiple bands, can you clarify? The relative_rssi just determines the
filter after the adjustment(s) done with rssi_adjust, but how could it
be relevant?
The only use case for relative_rssi being negative would be when you
actually *want* to see slightly worse networks than the one you're
connected to, e.g. to determine if you should use them because they
have better parameters (e.g. HT/VHT or soon HE).
> > > + if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI]) {
> > > + request->relative_rssi = nla_get_s8(
> > > + attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_R
> > > SSI]);
> > > + request->relative_rssi_set = true;
> > > + }
> > > +
> > > + if (attrs[NL80211_ATTR_SCHED_SCAN_RSSI_ADJUST]) {
> >
> > Maybe I misread but I thought this attribute to be applicable only
> > if
> > request->relative_rssi_set is true.
>
> @relative_rssi is valid only when @relative_rssi_set is set to true
> and @rssi_adjust is valid only when @relative_rssi is valid. I think
> that is understandable to drivers and there is no need of explicit
> check here.
It wouldn't be problematic to parse the RSSI_ADJUST only when the
others are present though, so that a driver could apply the rssi_adjust
unconditionally (since, if it's not parsed, the delta will be 0.)
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: wext does not need to set monitor channel in managed mode
From: Johannes Berg @ 2017-01-11 13:15 UTC (permalink / raw)
To: Jorge Ramirez-Ortiz; +Cc: linux-wireless, daniel.lezcano, daniel.thompson
In-Reply-To: <1483971949-10014-1-git-send-email-jorge.ramirez-ortiz@linaro.org>
On Mon, 2017-01-09 at 15:25 +0100, Jorge Ramirez-Ortiz wrote:
> There is not a valid reason to attempt setting the monitor channel
> while in managed mode. Since this code path only deals with this
> mode,
> remove the code block.
>
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] RFC: Universal scan proposal
From: Johannes Berg @ 2017-01-11 13:14 UTC (permalink / raw)
To: Arend Van Spriel, Dmitry Shmidt; +Cc: linux-wireless
In-Reply-To: <eb6a9c5e-0817-3b63-1e2f-d6bbff867b05@broadcom.com>
> > Well, we might not even need different commands. We need different
> > storage internally, but if you request the results for a given scan
> > ID then you might get a totally different result format? Though
> > that wouldn't lend itself well to query "everything you have" which
> > is also useful. But even then, it could be done by passing the
> > appropriate "report type" attribute to the dump command - we need
> > that anyway for trigger.
>
> True. With "report type" attribute you do not mean the actual
> report_type thing, right. Hopefully you mean the parameter attribute
> that implicitly relates to a "report type".
Right, I wasn't really thinking in terms of attributes while writing
this. OTOH, something like an attribute *would* be needed, no?
> The risk here is that it
> requires careful description of what user-space needs to look for if
> it gets a notification. I think having separate
> notification/retrieval commands lowers the risk of misinterpretation.
Yeah, fair point.
> Not sure if we're getting ahead of ourselves. Yes, we have to
> determine attributes for each scan "report type", but it is not a
> prerequisite for the other topic.
We'll also have to figure out which report types we need at all :)
> I guess to answer the question about the partial results attributes
> we need to know what the possible higher-level use-cases are. Other
> source of information would be to look what is done for g-scan in
> Android "M" or "N", but not sure if that is best approach as we may
> not consider all use-cases.
Right.
johannes
^ permalink raw reply
* Re: [PATCH 3/3] cfg80211: Specify the reason for connect timeout
From: Malinen, Jouni @ 2017-01-11 13:13 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Johannes Berg, linux-wireless@vger.kernel.org,
Kushwaha, Purushottam
In-Reply-To: <a59ef282-921d-6591-ab33-0a8dd3ef4294@broadcom.com>
On Mon, Jan 09, 2017 at 09:24:56PM +0100, Arend Van Spriel wrote:
> > diff --git a/net/wireless/sme.c b/net/wireless/sme.c
> > @@ -38,6 +38,7 @@ struct cfg80211_conn {
> > CFG80211_CONN_ASSOCIATE_NEXT,
> > CFG80211_CONN_ASSOCIATING,
> > CFG80211_CONN_ASSOC_FAILED,
> > + CFG80211_CONN_ASSOC_FAILED_TIMEOUT,
>=20
> Was kinda expecting AUTH_FAILED_TIMEOUT....
Me too when going through the changes.. But only the association failure
cases had different triggers that needed a change here.
> > @@ -172,6 +174,7 @@ static int cfg80211_conn_do_work(struct wireless_de=
v *wdev)
> > case CFG80211_CONN_AUTH_FAILED:
> > + *treason =3D NL80211_TIMEOUT_AUTH;
>=20
> ... but it seems AUTH failure always is a timeout?
The CFG80211_CONN_AUTH_FAILED case is currently used only in
cfg80211_sme_auth_timeout() which is indeed always a timeout.
--=20
Jouni Malinen PGP id EFC895FA=
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Felix Fietkau @ 2017-01-11 12:21 UTC (permalink / raw)
To: IgorMitsyanko, Johannes Berg, Linus Lüssing,
Stephen Hemminger
Cc: netdev, bridge, linux-wireless, linux-kernel, David S . Miller,
M. Braun
In-Reply-To: <ee946686-699c-da64-4932-f58e3f1a83ad@quantenna.com>
On 2017-01-11 13:15, IgorMitsyanko wrote:
> On 01/11/2017 02:30 PM, Felix Fietkau wrote:
>> On 2017-01-11 12:26, IgorMitsyanko wrote:
>>> On 01/11/2017 12:27 AM, Felix Fietkau wrote:
>>>> On 2017-01-10 11:56, Johannes Berg wrote:
>>>>> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
>>>>>> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
>>>>>>> I wonder if MAC80211 should be doing IGMP snooping and not bridge
>>>>>>> in this environment.
>>>>>> In the long term, yes. For now, not quite sure.
>>>>> There's no "for now" in the kernel. Code added now will have to be
>>>>> maintained essentially forever.
>>>> I'm not sure that putting the IGMP snooping code in mac80211 is a good
>>>> idea, that would be quite a bit of code duplication.
>>>> This implementation works, it's very simple, and it's quite flexible for
>>>> a number of use cases.
>>>>
>>>> Is there any remaining objection to merging this in principle (aside
>>>> from potential issues with the code)?
>>>>
>>>> - Felix
>>>>
>>>
>>> Hi Felix, can we consider two examples configurations with multicast
>>> traffic:
>>>
>>> 1. AP is a source of multicast traffic itself, no bridge on AP. For
>>> example, wireless video server streaming to several clients.
>>> In this situation, we can not make use of possible advantages given by
>>> mc-to-uc conversion?
>> You could simply put the AP interface in a bridge, no need to have any
>> other bridge members present.
>>
>>> 2. A configuration with AP + STA + 3 client devices behind STA.
>>> ----|client 1|
>>> |
>>> | mc |----|AP|----|STA|---|---|client 2|
>>> |server| |
>>> ----|client 3|
>>>
>>> Multicast server behind AP streams MC video traffic. All 3 clients
>>> behind the STA have joined the multicast group.
>>> I'm not sure if this case will be handled correctly with mc-to-uc
>>> conversion in bridge on AP?
>> What do you mean by "3 client devices behind STA"? Are you using a
>> 4-addr STA, multicast routing, or some kind of vendor specific "client
>> bridge" hackery?
>
> 3 client devices connected by backbone Ethernet network. Generic
> case is probably STA/AP operating in 4-addr mode (more or less standard
> solution as far as I know).
If the AP is running in 4-addr mode, it will need to have a bridge
interface anyway, because the link to the STA will be split out into a
separate virtual interface (AP_VLAN iftype).
In this case you don't actually need any multicast-to-unicast
conversion, because the multicast traffic will be unicast on 802.11
already (due to use of 4-addr mode).
- Felix
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: IgorMitsyanko @ 2017-01-11 12:15 UTC (permalink / raw)
To: Felix Fietkau, Johannes Berg, Linus Lüssing,
Stephen Hemminger
Cc: netdev, bridge, linux-wireless, linux-kernel, David S . Miller,
M. Braun
In-Reply-To: <015bf651-7584-13c0-16b9-d4e29e23c96b@nbd.name>
On 01/11/2017 02:30 PM, Felix Fietkau wrote:
> On 2017-01-11 12:26, IgorMitsyanko wrote:
>> On 01/11/2017 12:27 AM, Felix Fietkau wrote:
>>> On 2017-01-10 11:56, Johannes Berg wrote:
>>>> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
>>>>> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
>>>>>> I wonder if MAC80211 should be doing IGMP snooping and not bridge
>>>>>> in this environment.
>>>>> In the long term, yes. For now, not quite sure.
>>>> There's no "for now" in the kernel. Code added now will have to be
>>>> maintained essentially forever.
>>> I'm not sure that putting the IGMP snooping code in mac80211 is a good
>>> idea, that would be quite a bit of code duplication.
>>> This implementation works, it's very simple, and it's quite flexible for
>>> a number of use cases.
>>>
>>> Is there any remaining objection to merging this in principle (aside
>>> from potential issues with the code)?
>>>
>>> - Felix
>>>
>>
>> Hi Felix, can we consider two examples configurations with multicast
>> traffic:
>>
>> 1. AP is a source of multicast traffic itself, no bridge on AP. For
>> example, wireless video server streaming to several clients.
>> In this situation, we can not make use of possible advantages given by
>> mc-to-uc conversion?
> You could simply put the AP interface in a bridge, no need to have any
> other bridge members present.
>
>> 2. A configuration with AP + STA + 3 client devices behind STA.
>> ----|client 1|
>> |
>> | mc |----|AP|----|STA|---|---|client 2|
>> |server| |
>> ----|client 3|
>>
>> Multicast server behind AP streams MC video traffic. All 3 clients
>> behind the STA have joined the multicast group.
>> I'm not sure if this case will be handled correctly with mc-to-uc
>> conversion in bridge on AP?
> What do you mean by "3 client devices behind STA"? Are you using a
> 4-addr STA, multicast routing, or some kind of vendor specific "client
> bridge" hackery?
3 client devices connected by backbone Ethernet network. Generic
case is probably STA/AP operating in 4-addr mode (more or less standard
solution as far as I know).
"Client bridge" approach should not concern us here I think, it will
seem to AP and AP's bridge as a single client.
>
> - Felix
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Johannes Berg @ 2017-01-11 12:05 UTC (permalink / raw)
To: Cedric Izoard, Masashi Honma, linux-wireless@vger.kernel.org
In-Reply-To: <927a79f16e8c429da7a0d06f1bfb2567@ceva-dsp.com>
> I made a quick test with dongle using ath9k_htc driver and I indeed
> reproduce the issue.
Thanks.
> Here is the stack trace I get:
> I added a trace before calling skb_copy_expand to get the headroom of
> the buffer before the copy and the headroom asked by the driver.
>
> [ 83.200261] MESH fwd: skb_headroom=154, needed headroom=24
Could you also add a similar trace just before calling drv_tx()?
Maybe we're adding something else to this skb?
I can't find anything in the ath9k_htc driver that's adding more than
23 bytes (it's advertising 24) but clearly the last 8 bytes here are
failing:
> [ 83.200346] skbuff: skb_under_panic: text:ffffffffa034c028 len:154
> put:8 head:ffff880213422e00 data:ffff880213422dfa tail:0x94 end:0xc0
> dev:<NULL>
Maybe mac80211 is putting something else? It'd have to be
johannes
^ permalink raw reply
* RE: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Cedric Izoard @ 2017-01-11 11:35 UTC (permalink / raw)
To: Masashi Honma, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <1dd6e9f3-5ad2-1138-8017-c0ab208d9f88@gmail.com>
PiBPbiAyMDE35bm0MDHmnIgxMeaXpSAyMDowMSwgSm9oYW5uZXMgQmVyZyB3cm90ZToNCj4gPiBT
dXJlLCBzc2ggd29uJ3QgLSBJIHdhcyB0aGlua2luZyBvZiBuZXRjb25zb2xlOg0KPiA+IGh0dHBz
Oi8vd3d3Lmtlcm5lbC5vcmcvZG9jL0RvY3VtZW50YXRpb24vbmV0d29ya2luZy9uZXRjb25zb2xl
LnR4dA0KPiANCj4gT2gsIEkgc2VlLiBUaGFua3MsIEkgd2lsbCB0cnkuDQo+IA0KPiBNYXNhc2hp
IEhvbm1hLg0KSGksDQoNCkkgbWFkZSBhIHF1aWNrIHRlc3Qgd2l0aCBkb25nbGUgdXNpbmcgYXRo
OWtfaHRjIGRyaXZlciBhbmQgSSBpbmRlZWQgcmVwcm9kdWNlIHRoZSBpc3N1ZS4NCkhlcmUgaXMg
dGhlIHN0YWNrIHRyYWNlIEkgZ2V0Og0KSSBhZGRlZCBhIHRyYWNlIGJlZm9yZSBjYWxsaW5nIHNr
Yl9jb3B5X2V4cGFuZCB0byBnZXQgdGhlIGhlYWRyb29tIG9mIHRoZSBidWZmZXIgYmVmb3JlIHRo
ZSBjb3B5IGFuZCB0aGUgaGVhZHJvb20gYXNrZWQgYnkgdGhlIGRyaXZlci4NCg0KWyAgIDgzLjIw
MDI2MV0gTUVTSCBmd2Q6IHNrYl9oZWFkcm9vbT0xNTQsIG5lZWRlZCBoZWFkcm9vbT0yNA0KWyAg
IDgzLjIwMDM0Nl0gc2tidWZmOiBza2JfdW5kZXJfcGFuaWM6IHRleHQ6ZmZmZmZmZmZhMDM0YzAy
OCBsZW46MTU0IHB1dDo4IGhlYWQ6ZmZmZjg4MDIxMzQyMmUwMCBkYXRhOmZmZmY4ODAyMTM0MjJk
ZmEgdGFpbDoweDk0IGVuZDoweGMwIGRldjo8TlVMTD4NClsgICA4My4yMDAzNTldIC0tLS0tLS0t
LS0tLVsgY3V0IGhlcmUgXS0tLS0tLS0tLS0tLQ0KWyAgIDgzLjIwMDM2Ml0ga2VybmVsIEJVRyBh
dCAuLi9uZXQvY29yZS9za2J1ZmYuYzoxMDUhDQpbICAgODMuMjAwMzY0XSBpbnZhbGlkIG9wY29k
ZTogMDAwMCBbIzFdIFNNUA0KWyAgIDgzLjIwMDM2Nl0gTW9kdWxlcyBsaW5rZWQgaW46IGF0aDlr
X2h0YyBhdGg5a19jb21tb24gYXRoOWtfaHcgYXRoMTBrX3BjaSBhdGgxMGtfY29yZSBtYWM4MDIx
MSBhdGggY2ZnODAyMTEgeDg2X3BrZ190ZW1wX3RoZXJtYWwNClsgICA4My4yMDAzNzddIENQVTog
NCBQSUQ6IDI5IENvbW06IGtzb2Z0aXJxZC80IE5vdCB0YWludGVkIDQuOS4wKyAjMw0KWyAgIDgz
LjIwMDM3OV0gSGFyZHdhcmUgbmFtZTogRGVsbCBJbmMuIE9wdGlQbGV4IDk5MC8wNkQ3VFIsIEJJ
T1MgQTE5IDA4LzI2LzIwMTUNClsgICA4My4yMDAzODFdIHRhc2s6IGZmZmY4ODAyMjNlNTVjYzAg
dGFzay5zdGFjazogZmZmZmM5MDAwMGRiODAwMA0KWyAgIDgzLjIwMDM4M10gUklQOiAwMDEwOls8
ZmZmZmZmZmY4MTcwMDk0Yz5dICBbPGZmZmZmZmZmODE3MDA5NGM+XSBza2JfcGFuaWMrMHg1Yy8w
eDYwDQpbICAgODMuMjAwMzkxXSBSU1A6IDAwMTg6ZmZmZmM5MDAwMGRiYmJhMCAgRUZMQUdTOiAw
MDAxMDI4Ng0KWyAgIDgzLjIwMDM5M10gUkFYOiAwMDAwMDAwMDAwMDAwMDg2IFJCWDogMDAwMDAw
MDAwMDAwMDAwNiBSQ1g6IDAwMDAwMDAwMDAwMDAwMDANClsgICA4My4yMDAzOThdIFJEWDogZmZm
Zjg4MDIyNTMxMjZkOCBSU0k6IGZmZmY4ODAyMjUzMGNiMjggUkRJOiBmZmZmODgwMjI1MzBjYjI4
DQpbICAgODMuMjAwNDAwXSBSQlA6IGZmZmZjOTAwMDBkYmJiYzAgUjA4OiAwMDAwMDAwMDAwMDMw
ZTlhIFIwOTogMDAwMDAwMDAwMDAwMDAwNQ0KWyAgIDgzLjIwMDQwMV0gUjEwOiAwMDAwMDAwMDAw
MDAwMDAwIFIxMTogMDAwMDAwMDAwMDAwMDJjOCBSMTI6IGZmZmY4ODAyMjJkMGEwMDANClsgICA4
My4yMDA0MDNdIFIxMzogMDAwMDAwMDAwMDAwOTIwMCBSMTQ6IGZmZmY4ODAyMjFiYTdmMDAgUjE1
OiAwMDAwMDAwMDAwMDAwMDEwDQpbICAgODMuMjAwNDA2XSBGUzogIDAwMDAwMDAwMDAwMDAwMDAo
MDAwMCkgR1M6ZmZmZjg4MDIyNTMwMDAwMCgwMDAwKSBrbmxHUzowMDAwMDAwMDAwMDAwMDAwDQpb
ICAgODMuMjAwNDA4XSBDUzogIDAwMTAgRFM6IDAwMDAgRVM6IDAwMDAgQ1IwOiAwMDAwMDAwMDgw
MDUwMDMzDQpbICAgODMuMjAwNDEwXSBDUjI6IDAwMDA3ZmQ0MTQwMTBjOTggQ1IzOiAwMDAwMDAw
MjIyNDdkMDAwIENSNDogMDAwMDAwMDAwMDA0MDZlMA0KWyAgIDgzLjIwMDQxMV0gU3RhY2s6DQpb
ICAgODMuMjAwNDEzXSAgZmZmZjg4MDIxMzQyMmRmYSAwMDAwMDAwMDAwMDAwMDk0IDAwMDAwMDAw
MDAwMDAwYzAgZmZmZmZmZmY4MWMzMDhkOQ0KWyAgIDgzLjIwMDQxN10gIGZmZmZjOTAwMDBkYmJi
ZDAgZmZmZmZmZmY4MTcwMTliNyBmZmZmYzkwMDAwZGJiYzAwIGZmZmZmZmZmYTAzNGMwMjgNClsg
ICA4My4yMDA0MjBdICBmZmZmODgwMjIxYmE3ZjAwIGZmZmY4ODAyMjI2ZDE1YTAgMDAwMDAwMDAw
MDAwMDAwMCBmZmZmYzkwMDAwZGJiY2I4DQpbICAgODMuMjAwNDIzXSBDYWxsIFRyYWNlOg0KWyAg
IDgzLjIwMDQyOV0gIFs8ZmZmZmZmZmY4MTcwMTliNz5dIHNrYl9wdXNoKzB4MzcvMHg0MA0KWyAg
IDgzLjIwMDQzNV0gIFs8ZmZmZmZmZmZhMDM0YzAyOD5dIGh0Y19pc3N1ZV9zZW5kLmNvbnN0cHJv
cC4yKzB4MjgvMHg2MCBbYXRoOWtfaHRjXQ0KWyAgIDgzLjIwMDQ0MV0gIFs8ZmZmZmZmZmZhMDM0
YzNkMT5dIGh0Y19zZW5kKzB4MTEvMHgyMCBbYXRoOWtfaHRjXQ0KWyAgIDgzLjIwMDQ0NV0gIFs8
ZmZmZmZmZmZhMDM0ZmJkNz5dIGF0aDlrX2h0Y190eF9zdGFydCsweGQ3LzB4MmEwIFthdGg5a19o
dGNdDQpbICAgODMuMjAwNDUwXSAgWzxmZmZmZmZmZmEwMzUxMzI4Pl0gYXRoOWtfaHRjX3R4KzB4
YTgvMHhkMCBbYXRoOWtfaHRjXQ0KWyAgIDgzLjIwMDQ3MV0gIFs8ZmZmZmZmZmZhMDBkNzAyNz5d
IGllZWU4MDIxMV90eF9mcmFncysweDEzNy8weDFmMCBbbWFjODAyMTFdDQpbICAgODMuMjAwNDg5
XSAgWzxmZmZmZmZmZmEwMGQ3MWZjPl0gX19pZWVlODAyMTFfdHgrMHg3Yy8weDE4MCBbbWFjODAy
MTFdDQpbICAgODMuMjAwNTA2XSAgWzxmZmZmZmZmZmEwMGRjNTc1Pl0gaWVlZTgwMjExX3R4KzB4
ZTUvMHgxMTAgW21hYzgwMjExXQ0KWyAgIDgzLjIwMDUxOF0gIFs8ZmZmZmZmZmZhMDBkZGRlZj5d
IGllZWU4MDIxMV90eF9wZW5kaW5nKzB4OGYvMHgxZjAgW21hYzgwMjExXQ0KWyAgIDgzLjIwMDUy
Ml0gIFs8ZmZmZmZmZmY4MTA5MDM4Nj5dID8gcGlja19uZXh0X3Rhc2tfZmFpcisweDQwNi8weDQ3
MA0KWyAgIDgzLjIwMDUyOF0gIFs8ZmZmZmZmZmY4MTA1ZjExYT5dIHRhc2tsZXRfYWN0aW9uKzB4
ZGEvMHhmMA0KWyAgIDgzLjIwMDUzMl0gIFs8ZmZmZmZmZmY4MTA1ZjZjMj5dIF9fZG9fc29mdGly
cSsweGUyLzB4MjcwDQpbICAgODMuMjAwNTM2XSAgWzxmZmZmZmZmZjgxMDVmODY3Pl0gcnVuX2tz
b2Z0aXJxZCsweDE3LzB4MzANClsgICA4My4yMDA1NDBdICBbPGZmZmZmZmZmODEwN2E1NjU+XSBz
bXBib290X3RocmVhZF9mbisweDEwNS8weDE2MA0KWyAgIDgzLjIwMDU0M10gIFs8ZmZmZmZmZmY4
MTA3YTQ2MD5dID8gc29ydF9yYW5nZSsweDIwLzB4MjANClsgICA4My4yMDA1NDddICBbPGZmZmZm
ZmZmODEwNzZkZTU+XSBrdGhyZWFkKzB4YzUvMHhlMA0KWyAgIDgzLjIwMDU1MF0gIFs8ZmZmZmZm
ZmY4MTA3NmQyMD5dID8ga3RocmVhZF9wYXJrKzB4NjAvMHg2MA0KWyAgIDgzLjIwMDU1NF0gIFs8
ZmZmZmZmZmY4MTg1OGJkMj5dIHJldF9mcm9tX2ZvcmsrMHgyMi8weDMwDQpbICAgODMuMjAwNTU2
XSBDb2RlOiBjNCAwMCAwMCAwMCA0OCA4OSA0NCAyNCAxMCA4YiA4NyBjMCAwMCAwMCAwMCA0OCA4
OSA0NCAyNCAwOCA0OCA4YiA4NyBkMCAwMCAwMCAwMCA0OCBjNyBjNyAyOCA1NyBjMyA4MSA0OCA4
OSAwNCAyNCBlOCAxNSA3OCBhMiBmZiA8MGY+IDBiIDY2IDkwIDU1IDQ4IDg5IGU1IDQxIDU3IDQx
IDU2IDQxIDU1IDQxIDU0IDUzIDY1IDRjIDhiIDM0DQpbICAgODMuMjAwNTk2XSBSSVAgIFs8ZmZm
ZmZmZmY4MTcwMDk0Yz5dIHNrYl9wYW5pYysweDVjLzB4NjANClsgICA4My4yMDA2MDJdICBSU1Ag
PGZmZmZjOTAwMDBkYmJiYTA+DQoNCmNlZHJpYw0K
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox