* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Johannes Berg @ 2017-09-15 7:19 UTC (permalink / raw)
To: Denis Kenzior, Arend van Spriel, Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <94a01366-1af7-4728-59e4-847bfd8476e0@gmail.com>
On Thu, 2017-09-14 at 14:54 -0500, Denis Kenzior wrote:
> If you want roaming to keep oper state UP in all cases, then
> yes. Does this work on full mac cards as well?
I don't see why not.
> E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and issue
> a CMD_CONNECT to AP2?
That's not something you can do with full-MAC cards?
And even mac80211 doesn't really support pre-authentication (unless you
mean over-the-DS)
johannes
^ permalink raw reply
* Re: [PATCH] nl80211: check for the required netlink attributes presence
From: Johannes Berg @ 2017-09-15 7:18 UTC (permalink / raw)
To: Vladis Dronov, linux-wireless, linux-kernel; +Cc: # v3 . 1-rc1
In-Reply-To: <20170912222121.5032-1-vdronov@redhat.com>
On Wed, 2017-09-13 at 00:21 +0200, Vladis Dronov wrote:
> nl80211_set_rekey_data() does not check if the required attributes
> NL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing
> NL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by
> users with CAP_NET_ADMIN privilege and may result in NULL dereference
> and a system crash. Add a check for the required attributes presence.
> This patch is based on the patch by bo Zhang.
Huh. Applied, thanks.
johannes
^ permalink raw reply
* Re: rtlwifi/rtl8188ee baseband config explanation request
From: Farhan Khan @ 2017-09-15 6:26 UTC (permalink / raw)
To: Larry Finger, linux-wireless
In-Reply-To: <991a4c76-aff0-499f-11d6-59a4629b9d82@lwfinger.net>
Thank you for your prompt response.
I am trying to write a FreeBSD port of this driver. The structures of
the two drivers are significantly different, so it is not a trivial
exercise.
The FreeBSD driver also has a similar block of code that writes over an
array of data using an array of registers, and this should be easy to
re-create. But I do not see the equivalent of phy_config_bb_with_pghdr()
anywhere. I do not know if I need to maintain the order for any reason.
I attempted to reach out to Realtek through multiple mediums but did not
receive any replies. Ultimately, I may end up re-playing the same bits
without understanding what is happening.
On 09/15/2017 02:01 AM, Larry Finger wrote:
> On 09/15/2017 12:08 AM, Farhan Khan wrote:
>> Hi all,
>>
>> I am trying to get a high-level understanding of what occurs in
>> rtl88e_phy_bb_config() in
>> drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c. I understand the
>> code up until it runs _rtl88e_phy_bb8188e_config_parafile() .
>>
>>> From there, I see that phy_config_bb_with_headerfile() will write the
>> values in RTL8188EEPHY_REG_1TARRAY, runs phy_config_bb_with_pghdr(),
>> then write the values in RTL8188EEAGCTAB_1TARRAY.
>>
>> Please provide a high-level explanation of
>> phy_config_bb_with_headerfile(), and more particularly, of
>> phy_config_bb_pghdr(). What are their objectives? Also, is there a
>> reason for this specific order or can it be in any otherwise?
>
> Why do you want to know this information? Are you trying to
> reverse-engineer the Realtek wifi devices. Note that I do not know much
> about the internals of any of the Realtek devices, but I can read the
> code. The data in RTL8188EEPHY_REG_1TARRAY consists of two parts per
> entry. The first is an address, and the second is the data to be loaded
> into that address. These data are used by the firmware to calibrate
> radios, etc., and have been determined by the Realtek engineers. There
> is a similar interpretation for RTL8188EEAGCTAB_1TARRAY. I do not know
> for sure, but as the data values here are ALL written to the same
> address, I fully expect that these must be written AFTER the PHY_REG
> information. Something needs to be controlling where the data are being
> stored.
>
> The "high-level" interpretation of this code is this is what must be
> done for the device to work. If you want more information, you will need
> to investigate getting an NDA with Realtek. I do not have one, and I do
> not want such an agreement.
>
> Larry
^ permalink raw reply
* Re: rtlwifi/rtl8188ee baseband config explanation request
From: Larry Finger @ 2017-09-15 6:01 UTC (permalink / raw)
To: Farhan Khan, linux-wireless
In-Reply-To: <f37044ee-d0fb-1a3a-d98b-3233434f68ea@gmail.com>
On 09/15/2017 12:08 AM, Farhan Khan wrote:
> Hi all,
>
> I am trying to get a high-level understanding of what occurs in
> rtl88e_phy_bb_config() in
> drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c. I understand the
> code up until it runs _rtl88e_phy_bb8188e_config_parafile() .
>
>>From there, I see that phy_config_bb_with_headerfile() will write the
> values in RTL8188EEPHY_REG_1TARRAY, runs phy_config_bb_with_pghdr(),
> then write the values in RTL8188EEAGCTAB_1TARRAY.
>
> Please provide a high-level explanation of
> phy_config_bb_with_headerfile(), and more particularly, of
> phy_config_bb_pghdr(). What are their objectives? Also, is there a
> reason for this specific order or can it be in any otherwise?
Why do you want to know this information? Are you trying to reverse-engineer the
Realtek wifi devices. Note that I do not know much about the internals of any of
the Realtek devices, but I can read the code. The data in
RTL8188EEPHY_REG_1TARRAY consists of two parts per entry. The first is an
address, and the second is the data to be loaded into that address. These data
are used by the firmware to calibrate radios, etc., and have been determined by
the Realtek engineers. There is a similar interpretation for
RTL8188EEAGCTAB_1TARRAY. I do not know for sure, but as the data values here are
ALL written to the same address, I fully expect that these must be written AFTER
the PHY_REG information. Something needs to be controlling where the data are
being stored.
The "high-level" interpretation of this code is this is what must be done for
the device to work. If you want more information, you will need to investigate
getting an NDA with Realtek. I do not have one, and I do not want such an agreement.
Larry
^ permalink raw reply
* [PATCH v2] iwlwifi: mvm: allow monitor mode capture in STA mode
From: gavinli @ 2017-09-15 5:11 UTC (permalink / raw)
To: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless
Cc: linux-wireless, Gavin Li
From: Gavin Li <git@thegavinli.com>
Open up the filter if there is a monitor interface configured; this
allows all packets on the channel to be captured even if the device is
in STA mode and associated to a BSS.
Signed-off-by: Gavin Li <git@thegavinli.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 42 +++++++++++++++++++----
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 ++
3 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
index fd2fc46e2fe5..ea98fc040aa8 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
@@ -752,7 +752,8 @@ static void iwl_mvm_mac_ctxt_cmd_common(struct iwl_mvm *mvm,
cpu_to_le32(vif->bss_conf.use_short_slot ?
MAC_FLG_SHORT_SLOT : 0);
- cmd->filter_flags = cpu_to_le32(MAC_FILTER_ACCEPT_GRP);
+ cmd->filter_flags = cpu_to_le32(mvm->addl_filter_flags |
+ MAC_FILTER_ACCEPT_GRP);
for (i = 0; i < IEEE80211_NUM_ACS; i++) {
u8 txf = iwl_mvm_ac_to_tx_fifo[i];
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index db5ad222e5ea..7c6d30ea3cf1 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -1641,6 +1641,13 @@ static u64 iwl_mvm_prepare_multicast(struct ieee80211_hw *hw,
return (u64)(unsigned long)cmd;
}
+static void iwl_mvm_addl_ff_iface_iterator(
+ void *_mvm, u8 *mac, struct ieee80211_vif *vif)
+{
+ struct iwl_mvm *mvm = _mvm;
+ iwl_mvm_mac_ctxt_changed(mvm, vif, false, NULL);
+}
+
static void iwl_mvm_configure_filter(struct ieee80211_hw *hw,
unsigned int changed_flags,
unsigned int *total_flags,
@@ -1648,20 +1655,41 @@ static void iwl_mvm_configure_filter(struct ieee80211_hw *hw,
{
struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw);
struct iwl_mcast_filter_cmd *cmd = (void *)(unsigned long)multicast;
+ const u32 supported_filters =
+ FIF_BCN_PRBRESP_PROMISC |
+ FIF_CONTROL |
+ FIF_OTHER_BSS |
+ FIF_PROBE_REQ;
+ u32 addl_filter_flags = 0;
+
+ *total_flags &= supported_filters;
+ if (*total_flags & FIF_BCN_PRBRESP_PROMISC)
+ addl_filter_flags |= MAC_FILTER_IN_BEACON;
+ if (*total_flags & FIF_CONTROL)
+ addl_filter_flags |= MAC_FILTER_IN_CONTROL_AND_MGMT;
+ if (*total_flags & FIF_OTHER_BSS)
+ addl_filter_flags |= MAC_FILTER_IN_CONTROL_AND_MGMT |
+ MAC_FILTER_IN_PROMISC |
+ MAC_FILTER_IN_BEACON;
+ if (*total_flags & FIF_PROBE_REQ)
+ addl_filter_flags |= MAC_FILTER_IN_PROBE_REQUEST;
+ /* replace previous configuration */
mutex_lock(&mvm->mutex);
- /* replace previous configuration */
+ if (mvm->addl_filter_flags != addl_filter_flags) {
+ mvm->addl_filter_flags = addl_filter_flags;
+ ieee80211_iterate_active_interfaces(
+ mvm->hw, IEEE80211_IFACE_ITER_NORMAL,
+ iwl_mvm_addl_ff_iface_iterator, mvm);
+ }
+
kfree(mvm->mcast_filter_cmd);
mvm->mcast_filter_cmd = cmd;
+ if (cmd)
+ iwl_mvm_recalc_multicast(mvm);
- if (!cmd)
- goto out;
-
- iwl_mvm_recalc_multicast(mvm);
-out:
mutex_unlock(&mvm->mutex);
- *total_flags = 0;
}
static void iwl_mvm_config_iface_filter(struct ieee80211_hw *hw,
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 52f8d7a6a7dc..827c413157c7 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -832,6 +832,9 @@ struct iwl_mvm {
/* configured by mac80211 */
u32 rts_threshold;
+ /* packets to pass as requested by mac80211 */
+ u32 addl_filter_flags;
+
/* Scan status, cmd (pre-allocated) and auxiliary station */
unsigned int scan_status;
void *scan_cmd;
--
2.14.1
^ permalink raw reply related
* rtlwifi/rtl8188ee baseband config explanation request
From: Farhan Khan @ 2017-09-15 5:08 UTC (permalink / raw)
To: linux-wireless
Hi all,
I am trying to get a high-level understanding of what occurs in
rtl88e_phy_bb_config() in
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c. I understand the
code up until it runs _rtl88e_phy_bb8188e_config_parafile() .
>From there, I see that phy_config_bb_with_headerfile() will write the
values in RTL8188EEPHY_REG_1TARRAY, runs phy_config_bb_with_pghdr(),
then write the values in RTL8188EEAGCTAB_1TARRAY.
Please provide a high-level explanation of
phy_config_bb_with_headerfile(), and more particularly, of
phy_config_bb_pghdr(). What are their objectives? Also, is there a
reason for this specific order or can it be in any otherwise?
Thanks!
--
Farhan Khan
PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Ben Greear @ 2017-09-14 22:57 UTC (permalink / raw)
To: Denis Kenzior, Johannes Berg, Arend van Spriel, Arend van Spriel,
Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <4aef67e2-7476-71d7-7692-cf6ed3f6c5b8@gmail.com>
On 09/14/2017 03:42 PM, Denis Kenzior wrote:
> Hi Ben,
>
> On 09/14/2017 05:15 PM, Ben Greear wrote:
>> On 09/14/2017 02:35 PM, Denis Kenzior wrote:
>>> Hi Ben,
>>>
>>>>> I think it is sane to assume that the IP address _should_ be the same. The 802.11 spec expects this even. This is to handle bizarre networks that don't do
>>>>> this
>>>>> properly.
>>>>
>>>> Can you point me to the section in the spec about this?
>>>>
>>>
>>> Lets see, 802.11-2012, Section 4.3.4.2:
>>> "The key concept is that the ESS network appears the same to an LLC layer as an IBSS network. STAs within an ESS may communicate and mobile STAs may move from
>>> one BSS to another (within the same ESS) transparently to LLC."
>>>
>>> Section 4.5.3.2,
>>
>> Thanks for the pointer.
>>
>> It looks to me like having same SSID/auth is a requirement to be in the same ESS, but
>> just having the same ESSID/auth does not mean it is definitely in the same ESS.
>>
>
> Sure. But then your PSK has to match, or your credentials need to be accepted. I suppose you can have two separate ESSes operating with the same SSID and
> security type. But man, how likely is that? That is fundamentally broken and we should not slow everything down just to take care of a broken case.
What about two APs with ssid LEDE and open-auth, each serving DHCP, each
connected to a switch that connects to a cable modem, etc.
>
>>> etc.
>>>
>>>>>> If not, how is this different from just re-doing DHCP like normal?
>>>>>>
>>>>>
>>>>> You get to use your old IP address. So e.g. your VoIP call doesn't disappear if you decide to switch access points.
>>>>>
>>>>>> And if so, you will in some cases be allowing duplicate IP addresses on
>>>>>> a network?
>>>>>>
>>>>>
>>>>> Life is never perfect ;)
>>>>
>>>> If you are breaking networks while trying to optimize something, then I think you
>>>> are going about it wrong.
>>>>
>>>> Seems like we would need some way for the DHCP server and/or AP to proactively
>>>> notify the station that they can skip DHCP, and default to not skipping.
>>>
>>> Not unless you're planning to extend the spec? 802.11 doesn't even mention DHCP in any real manner.
>>
>> So, it could be given out by the DHCP server then. There are ways to add custom
>> options to it, right?
>>
>> User-space can remember the option and use that to decide whether to re-do DHCP
>> when a station roams to another AP in (the probable) same ESS. Since this is
>> a new option, you should not have backwards-compatibility issues.
>
> And now you're breaking layering even more. DHCP shouldn't care that a given client is connecting via ethernet or wifi. And you're still relying on DHCP.
>
> Think about it, with a normal roam, you're probably 40-70 ms latency. If you have to do 802.1x, that's probably 150+ms. With a fast-transition you're down to
> maybe 20 ms? If you need to rely on DHCP, that's 1 second or more. A user can detect latency of 100ms easily. So if their VoIP call drops for for 1 second or
> more, you have failed.
On initial connection to the network, the station does DHCP and gets a response, like normal.
But, that response has a special message in it that says "you don't need to re-do dhcp if you roam here".
User-space remembers this response for future roams...
After that, then you skip DHCP on roam to this SSID/auth network, so you have zero extra network
overhead when roaming.
You could also tell IPv6 to not drop/re-acquite its IP addresses on link-down, and then everything
works w/out having to hack on the mac80211 state, I think?
>>>> I vaguely recall that FT had some way to verify you were roaming to the same dhcp-domain
>>>> or not, but honestly, it has been a long time since I read through that...
>>>>
>>>
>>> Do you mean a mobility domain? This has nothing to do with DHCP...
>>
>> It seems to be a very convenient way to identify a group of APs that share
>> common infrastructure, more so that just having the same SSID/auth...
>>
>> Do you think there would ever be a mobility domain that did not share
>> a common DHCP server pool?
>>
>
> I would expect fast transitions to work exactly like any other transition within an ESS. Just faster. And there's nothing stopping one from configuring 2 FT
> capable ESSes with the same MDID, leading to a yet another bizarre case.
Well, if we are being very paranoid, then you have to look for some specific and purposeful
identifier, such as the DHCP option I mentioned. But, I know that at least some larger
entities are (or were a year or two ago) treating a mobility domain roam to mean that DHCP
is not needed on roam.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Denis Kenzior @ 2017-09-14 22:42 UTC (permalink / raw)
To: Ben Greear, Johannes Berg, Arend van Spriel, Arend van Spriel,
Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <038474b0-4d37-9bb7-ebf0-b92564abf5af@candelatech.com>
Hi Ben,
On 09/14/2017 05:15 PM, Ben Greear wrote:
> On 09/14/2017 02:35 PM, Denis Kenzior wrote:
>> Hi Ben,
>>
>>>> I think it is sane to assume that the IP address _should_ be the
>>>> same. The 802.11 spec expects this even. This is to handle bizarre
>>>> networks that don't do this
>>>> properly.
>>>
>>> Can you point me to the section in the spec about this?
>>>
>>
>> Lets see, 802.11-2012, Section 4.3.4.2:
>> "The key concept is that the ESS network appears the same to an LLC
>> layer as an IBSS network. STAs within an ESS may communicate and
>> mobile STAs may move from
>> one BSS to another (within the same ESS) transparently to LLC."
>>
>> Section 4.5.3.2,
>
> Thanks for the pointer.
>
> It looks to me like having same SSID/auth is a requirement to be in the
> same ESS, but
> just having the same ESSID/auth does not mean it is definitely in the
> same ESS.
>
Sure. But then your PSK has to match, or your credentials need to be
accepted. I suppose you can have two separate ESSes operating with the
same SSID and security type. But man, how likely is that? That is
fundamentally broken and we should not slow everything down just to take
care of a broken case.
>> etc.
>>
>>>>> If not, how is this different from just re-doing DHCP like normal?
>>>>>
>>>>
>>>> You get to use your old IP address. So e.g. your VoIP call doesn't
>>>> disappear if you decide to switch access points.
>>>>
>>>>> And if so, you will in some cases be allowing duplicate IP
>>>>> addresses on
>>>>> a network?
>>>>>
>>>>
>>>> Life is never perfect ;)
>>>
>>> If you are breaking networks while trying to optimize something, then
>>> I think you
>>> are going about it wrong.
>>>
>>> Seems like we would need some way for the DHCP server and/or AP to
>>> proactively
>>> notify the station that they can skip DHCP, and default to not skipping.
>>
>> Not unless you're planning to extend the spec? 802.11 doesn't even
>> mention DHCP in any real manner.
>
> So, it could be given out by the DHCP server then. There are ways to
> add custom
> options to it, right?
>
> User-space can remember the option and use that to decide whether to
> re-do DHCP
> when a station roams to another AP in (the probable) same ESS. Since
> this is
> a new option, you should not have backwards-compatibility issues.
And now you're breaking layering even more. DHCP shouldn't care that a
given client is connecting via ethernet or wifi. And you're still
relying on DHCP.
Think about it, with a normal roam, you're probably 40-70 ms latency.
If you have to do 802.1x, that's probably 150+ms. With a
fast-transition you're down to maybe 20 ms? If you need to rely on
DHCP, that's 1 second or more. A user can detect latency of 100ms
easily. So if their VoIP call drops for for 1 second or more, you have
failed.
>
>>> I vaguely recall that FT had some way to verify you were roaming to
>>> the same dhcp-domain
>>> or not, but honestly, it has been a long time since I read through
>>> that...
>>>
>>
>> Do you mean a mobility domain? This has nothing to do with DHCP...
>
> It seems to be a very convenient way to identify a group of APs that share
> common infrastructure, more so that just having the same SSID/auth...
>
> Do you think there would ever be a mobility domain that did not share
> a common DHCP server pool?
>
I would expect fast transitions to work exactly like any other
transition within an ESS. Just faster. And there's nothing stopping
one from configuring 2 FT capable ESSes with the same MDID, leading to a
yet another bizarre case.
Regards,
-Denis
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Ben Greear @ 2017-09-14 22:15 UTC (permalink / raw)
To: Denis Kenzior, Johannes Berg, Arend van Spriel, Arend van Spriel,
Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <5ec7a05e-dfa4-37e0-b108-51ca0885b9a7@gmail.com>
On 09/14/2017 02:35 PM, Denis Kenzior wrote:
> Hi Ben,
>
>>> I think it is sane to assume that the IP address _should_ be the same. The 802.11 spec expects this even. This is to handle bizarre networks that don't do this
>>> properly.
>>
>> Can you point me to the section in the spec about this?
>>
>
> Lets see, 802.11-2012, Section 4.3.4.2:
> "The key concept is that the ESS network appears the same to an LLC layer as an IBSS network. STAs within an ESS may communicate and mobile STAs may move from
> one BSS to another (within the same ESS) transparently to LLC."
>
> Section 4.5.3.2,
Thanks for the pointer.
It looks to me like having same SSID/auth is a requirement to be in the same ESS, but
just having the same ESSID/auth does not mean it is definitely in the same ESS.
> etc.
>
>>>> If not, how is this different from just re-doing DHCP like normal?
>>>>
>>>
>>> You get to use your old IP address. So e.g. your VoIP call doesn't disappear if you decide to switch access points.
>>>
>>>> And if so, you will in some cases be allowing duplicate IP addresses on
>>>> a network?
>>>>
>>>
>>> Life is never perfect ;)
>>
>> If you are breaking networks while trying to optimize something, then I think you
>> are going about it wrong.
>>
>> Seems like we would need some way for the DHCP server and/or AP to proactively
>> notify the station that they can skip DHCP, and default to not skipping.
>
> Not unless you're planning to extend the spec? 802.11 doesn't even mention DHCP in any real manner.
So, it could be given out by the DHCP server then. There are ways to add custom
options to it, right?
User-space can remember the option and use that to decide whether to re-do DHCP
when a station roams to another AP in (the probable) same ESS. Since this is
a new option, you should not have backwards-compatibility issues.
>> I vaguely recall that FT had some way to verify you were roaming to the same dhcp-domain
>> or not, but honestly, it has been a long time since I read through that...
>>
>
> Do you mean a mobility domain? This has nothing to do with DHCP...
It seems to be a very convenient way to identify a group of APs that share
common infrastructure, more so that just having the same SSID/auth...
Do you think there would ever be a mobility domain that did not share
a common DHCP server pool?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [EXT] Re: [PATCH 2/2] mwifiex: print URB submit failure error after threshold attemtps
From: Brian Norris @ 2017-09-14 21:59 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: Joe Perches, Cathy Luo, Xinming Hu, Zhiyuan Yang, James Cao,
Mangesh Malusare, linux-wireless@vger.kernel.org
In-Reply-To: <6dfc9cfaff734c12bc53ffcb063c4491@SC-EXCH02.marvell.com>
Hi Ganapathi,
On Thu, Sep 14, 2017 at 02:14:24PM +0000, Ganapathi Bhat wrote:
> > On Thu, 2017-08-31 at 01:21 +0530, Ganapathi Bhat wrote:
> > > Current driver prints dev_alloc_skb failures everytime while
> > > submitting RX URBs. This failure might be frequent in some low
> > > resource platforms. So, wait for a threshold failure count before
> > > start priting the error. This change is a follow up for the 'commit
> > > 7b368e3d15c3
> > > ("mwifiex: resubmit failed to submit RX URBs in main thread")'
> >
> > []
> >
> > > diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c
> > > b/drivers/net/wireless/marvell/mwifiex/usb.c
> > []
> > > @@ -300,9 +300,16 @@ static int mwifiex_usb_submit_rx_urb(struct
> > urb_context *ctx, int size)
> > > if (card->rx_cmd_ep != ctx->ep) {
> > > ctx->skb = dev_alloc_skb(size);
> > > if (!ctx->skb) {
> > > - mwifiex_dbg(adapter, ERROR,
> > > - "%s: dev_alloc_skb failed\n", __func__);
> > > + if (++card->rx_urb_failure_count >
> > > + MWIFIEX_RX_URB_FAILURE_THRESHOLD) {
> > > + mwifiex_dbg(adapter, ERROR,
> > > + "%s: dev_alloc_skb failed, failure
> > count = %u\n",
> > > + __func__,
> > > + card->rx_urb_failure_count);
> > > + }
> > > return -ENOMEM;
> >
> > Why not use a ratelimit?
> Since this is for receive, the packets are from AP side and we cannot
> lower the rate from AP. On some low performance systems this change
> will be helpful.
I think Joe was referring to things like printk_ratelimited() or
dev_err_ratelimited(). Those automatically ratelimit prints for you,
using a static counter. You'd just need to make a small warpper for
mwifiex_dbg() using __ratelimit().
Those sort of rate limits are significantly different than yours though.
You were looking to avoid printing errors when there are only a few
failures in a row, whereas the existing rate-limiting infrastructure
looks to avoid printing errors if too many happen in a row. Those are
different goals.
Brian
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Denis Kenzior @ 2017-09-14 21:35 UTC (permalink / raw)
To: Ben Greear, Johannes Berg, Arend van Spriel, Arend van Spriel,
Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <c33e5aed-be5a-890d-cc50-b5ac87b40d9a@candelatech.com>
Hi Ben,
>> I think it is sane to assume that the IP address _should_ be the same.
>> The 802.11 spec expects this even. This is to handle bizarre networks
>> that don't do this
>> properly.
>
> Can you point me to the section in the spec about this?
>
Lets see, 802.11-2012, Section 4.3.4.2:
"The key concept is that the ESS network appears the same to an LLC
layer as an IBSS network. STAs within an ESS may communicate and mobile
STAs may move from one BSS to another (within the same ESS)
transparently to LLC."
Section 4.5.3.2,
etc.
>>> If not, how is this different from just re-doing DHCP like normal?
>>>
>>
>> You get to use your old IP address. So e.g. your VoIP call doesn't
>> disappear if you decide to switch access points.
>>
>>> And if so, you will in some cases be allowing duplicate IP addresses on
>>> a network?
>>>
>>
>> Life is never perfect ;)
>
> If you are breaking networks while trying to optimize something, then I
> think you
> are going about it wrong.
>
> Seems like we would need some way for the DHCP server and/or AP to
> proactively
> notify the station that they can skip DHCP, and default to not skipping.
Not unless you're planning to extend the spec? 802.11 doesn't even
mention DHCP in any real manner.
>
> I vaguely recall that FT had some way to verify you were roaming to the
> same dhcp-domain
> or not, but honestly, it has been a long time since I read through that...
>
Do you mean a mobility domain? This has nothing to do with DHCP...
Regards,
-Denis
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Ben Greear @ 2017-09-14 20:47 UTC (permalink / raw)
To: Denis Kenzior, Johannes Berg, Arend van Spriel, Arend van Spriel,
Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <756be45c-fd13-56a7-b8d4-129c4fd07dc8@gmail.com>
On 09/14/2017 01:35 PM, Denis Kenzior wrote:
> Hi Ben,
>
> On 09/14/2017 03:29 PM, Ben Greear wrote:
>> On 09/14/2017 01:26 PM, Denis Kenzior wrote:
>>> Hi Ben,
>>>>
>>>> How do you re-confirm them? There are definitely cases where SSID/Security is the same but each
>>>> AP has its own DHCP server and roaming between them will require getting a new DHCP address (on
>>>> the same (NAT'd) subnet and with same gateway, likely as not).
>>>>
>>>
>>> Using DHCPREQUEST to verify obtained parameters, or the DHCPv6 equivalent Confirm message. This obviously requires some integration between the dhcp daemon and
>>> the supplicant.
>>
>> Do you want to allow the just-now-roamed station to use its old IP address(es) while you are
>> confirming?
>
> I think it is sane to assume that the IP address _should_ be the same. The 802.11 spec expects this even. This is to handle bizarre networks that don't do this
> properly.
Can you point me to the section in the spec about this?
>> If not, how is this different from just re-doing DHCP like normal?
>>
>
> You get to use your old IP address. So e.g. your VoIP call doesn't disappear if you decide to switch access points.
>
>> And if so, you will in some cases be allowing duplicate IP addresses on
>> a network?
>>
>
> Life is never perfect ;)
If you are breaking networks while trying to optimize something, then I think you
are going about it wrong.
Seems like we would need some way for the DHCP server and/or AP to proactively
notify the station that they can skip DHCP, and default to not skipping.
I vaguely recall that FT had some way to verify you were roaming to the same dhcp-domain
or not, but honestly, it has been a long time since I read through that...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: iwlwifi firmware load broken in current -git
From: Jens Axboe @ 2017-09-14 20:36 UTC (permalink / raw)
To: Srinath Mannam
Cc: Bjorn Helgaas, Johannes Berg, Luca Coelho, Grumbach, Emmanuel,
linuxwifi, linux-wireless@vger.kernel.org,
linux-pci@vger.kernel.org
In-Reply-To: <CABe79T79WhBh66iQB-5LLCQO0d37evg5tsKUGkj7+z8vNGTHcA@mail.gmail.com>
On 09/14/2017 02:04 PM, Srinath Mannam wrote:
> Hi Jens Axboe,
>
>
> On Thu, Sep 14, 2017 at 11:14 PM, Jens Axboe <axboe@kernel.dk> wrote:
>> On 09/14/2017 11:35 AM, Jens Axboe wrote:
>>> On 09/14/2017 11:28 AM, Srinath Mannam wrote:
>>>> Hi Bjorn,
>>>>
>>>> On Thu, Sep 14, 2017 at 10:52 PM, Jens Axboe <axboe@kernel.dk> wrote:
>>>>>
>>>>> On 09/14/2017 11:11 AM, Bjorn Helgaas wrote:
>>>>>> [+cc linux-pci]
>>>>>>
>>>>>> On Thu, Sep 14, 2017 at 12:00 PM, Jens Axboe <axboe@kernel.dk> wrote:
>>>>>>> On 09/12/2017 02:04 PM, Johannes Berg wrote:
>>>>>>>> On Tue, 2017-09-12 at 13:43 -0600, Jens Axboe wrote:
>>>>>>>>
>>>>>>>>> CC'ing the guilty part and Bjorn. I'm assuming it's the
>>>>>>>>> pci_is_enabled() check, since the rest of the patch shouldn't have
>>>>>>>>> functional changes.
>>>>>>>>
>>>>>>>> and pci_enable_bridge() already checks if it's already enabled, but
>>>>>>>> still enables mastering in that case if it isn't:
>>>>>>>>
>>>>>>>> static void pci_enable_bridge(struct pci_dev *dev)
>>>>>>>> {
>>>>>>>> [...]
>>>>>>>> if (pci_is_enabled(dev)) {
>>>>>>>> if (!dev->is_busmaster)
>>>>>>>> pci_set_master(dev);
>>>>>>>> return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> so I guess due to the new check we end up with mastering disabled, and
>>>>>>>> thus the firmware can't load since that's a DMA thing?
>>>>>>>
>>>>>>> Bjorn/Srinath, any input here? This is a regression that prevents wifi
>>>>>>> from working on a pretty standard laptop. It'd suck to have this be in
>>>>>>> -rc1. Seems like the trivial fix would be:
>>>>>>>
>>>>>>>
>>>>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>>>>> index b0002daa50f3..ffbe11dbdd61 100644
>>>>>>> --- a/drivers/pci/pci.c
>>>>>>> +++ b/drivers/pci/pci.c
>>>>>>> @@ -1394,7 +1394,7 @@ static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
>>>>>>> return 0; /* already enabled */
>>>>>>>
>>>>>>> bridge = pci_upstream_bridge(dev);
>>>>>>> - if (bridge && !pci_is_enabled(bridge))
>>>>>>> + if (bridge)
>>>> With this change and keeping "mutex_lock(&pci_bridge_mutex);" in
>>>> pci_enable_bridge functoin will causes a nexted lock.
>>>
>>> Took a look, and looks like you are right. That code looks like a mess,
>>> fwiw.
>>>
>>> I'd strongly suggest that the bad commit is reverted until a proper
>>> solution is found, since the simple one-liner could potentially
>>> introduce a deadlock with your patch applied.
>>
>> BTW, your patch looks pretty bad too, introducing a random mutex
>> deep on code that can be recursive. Why isn't this check in
>> pci_enable_device_flags() enough to prevent double-enable of
>> an upstream bridge?
>>
>> if (atomic_inc_return(&dev->enable_cnt) > 1)
>> return 0; /* already enabled */
>>
> This check only to verify device enable not for the bus master check.
> But device enable function calls the bridge enable if it has the bridge.
> Bridge enable function enables both device and bus master.
>
> Here the issue might be because, bridge of endpoint has already set
> device enable without set bus master in some other context. which is
> wrong.
> because all bridges should enable with bridge_enable function only.
> So we see the problem In this context, because "if (bridge &&
> !pci_is_enabled(bridge))" check stops bridge enable which intern stops
> bus master.
> pci_enable_bridge function always makes sure that both device and bus
> master are enabled in any case. If pci_enable_bridge function is not
> called means, that bridge is already has device enable flag set. which
> is not from pci_enable_bridge function.
In any case, your patch introduces a regression on systems. Please get
it reverted now, and then you can come up with a new approach to fix the
double enable of the upstream bridge.
--
Jens Axboe
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Denis Kenzior @ 2017-09-14 20:35 UTC (permalink / raw)
To: Ben Greear, Johannes Berg, Arend van Spriel, Arend van Spriel,
Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <8a26a838-adde-08f1-5f64-c98e1d947675@candelatech.com>
Hi Ben,
On 09/14/2017 03:29 PM, Ben Greear wrote:
> On 09/14/2017 01:26 PM, Denis Kenzior wrote:
>> Hi Ben,
>>>
>>> How do you re-confirm them? There are definitely cases where
>>> SSID/Security is the same but each
>>> AP has its own DHCP server and roaming between them will require
>>> getting a new DHCP address (on
>>> the same (NAT'd) subnet and with same gateway, likely as not).
>>>
>>
>> Using DHCPREQUEST to verify obtained parameters, or the DHCPv6
>> equivalent Confirm message. This obviously requires some integration
>> between the dhcp daemon and
>> the supplicant.
>
> Do you want to allow the just-now-roamed station to use its old IP
> address(es) while you are
> confirming?
I think it is sane to assume that the IP address _should_ be the same.
The 802.11 spec expects this even. This is to handle bizarre networks
that don't do this properly.
>
> If not, how is this different from just re-doing DHCP like normal?
>
You get to use your old IP address. So e.g. your VoIP call doesn't
disappear if you decide to switch access points.
> And if so, you will in some cases be allowing duplicate IP addresses on
> a network?
>
Life is never perfect ;)
Regards,
-Denis
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Ben Greear @ 2017-09-14 20:29 UTC (permalink / raw)
To: Denis Kenzior, Johannes Berg, Arend van Spriel, Arend van Spriel,
Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <c97ecdb4-fe7a-e79a-d73e-32166beb1e11@gmail.com>
On 09/14/2017 01:26 PM, Denis Kenzior wrote:
> Hi Ben,
>>
>> How do you re-confirm them? There are definitely cases where SSID/Security is the same but each
>> AP has its own DHCP server and roaming between them will require getting a new DHCP address (on
>> the same (NAT'd) subnet and with same gateway, likely as not).
>>
>
> Using DHCPREQUEST to verify obtained parameters, or the DHCPv6 equivalent Confirm message. This obviously requires some integration between the dhcp daemon and
> the supplicant.
Do you want to allow the just-now-roamed station to use its old IP address(es) while you are
confirming?
If not, how is this different from just re-doing DHCP like normal?
And if so, you will in some cases be allowing duplicate IP addresses on
a network?
Thanks,
Ben
>
> Regards,
> -Denis
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Denis Kenzior @ 2017-09-14 20:26 UTC (permalink / raw)
To: Ben Greear, Johannes Berg, Arend van Spriel, Arend van Spriel,
Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <5436d106-0b4a-9158-58bf-ff84b231cd19@candelatech.com>
Hi Ben,
>
> How do you re-confirm them? There are definitely cases where
> SSID/Security is the same but each
> AP has its own DHCP server and roaming between them will require getting
> a new DHCP address (on
> the same (NAT'd) subnet and with same gateway, likely as not).
>
Using DHCPREQUEST to verify obtained parameters, or the DHCPv6
equivalent Confirm message. This obviously requires some integration
between the dhcp daemon and the supplicant.
Regards,
-Denis
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Ben Greear @ 2017-09-14 20:08 UTC (permalink / raw)
To: Denis Kenzior, Johannes Berg, Arend van Spriel, Arend van Spriel,
Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <c2a820c4-f169-6a4d-13f3-3df323f1556a@gmail.com>
On 09/14/2017 01:05 PM, Denis Kenzior wrote:
> Hi Ben,
>>
>> There are different meanings for 'roam'. Are you just talking about
>> fast-transition roaming?
>>
>
> I'm using 'roam' as any transition between BSSes in the same SSID/Security type. So regular re-association, pre-authenticated association, fast transition.
>
>> I would think that the decision to restart DHCP (at least ipv4) should
>> be in user-space. I'm less sure about how IPv6 should deal with this.
>>
>> I have tested roaming using FT and normal-ish wpa_supplicant without
>> doing DHCP, and it works fine. Of course, it also works if you
>> choose to re-do DHCP.
>>
>
> Our thinking on this was to assume that DHCP parameters are still valid after a roam, but re-confirm them just in case. If the confirmation fails, then we can
> fall back to requesting a new DHCP lease.
How do you re-confirm them? There are definitely cases where SSID/Security is the same but each
AP has its own DHCP server and roaming between them will require getting a new DHCP address (on
the same (NAT'd) subnet and with same gateway, likely as not).
Thanks,
Ben
>
> Regards,
> -Denis
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Denis Kenzior @ 2017-09-14 20:05 UTC (permalink / raw)
To: Ben Greear, Johannes Berg, Arend van Spriel, Arend van Spriel,
Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <6d0ad07b-ca89-19a1-d3c2-ad94915b942a@candelatech.com>
Hi Ben,
>
> There are different meanings for 'roam'. Are you just talking about
> fast-transition roaming?
>
I'm using 'roam' as any transition between BSSes in the same
SSID/Security type. So regular re-association, pre-authenticated
association, fast transition.
> I would think that the decision to restart DHCP (at least ipv4) should
> be in user-space. I'm less sure about how IPv6 should deal with this.
>
> I have tested roaming using FT and normal-ish wpa_supplicant without
> doing DHCP, and it works fine. Of course, it also works if you
> choose to re-do DHCP.
>
Our thinking on this was to assume that DHCP parameters are still valid
after a roam, but re-confirm them just in case. If the confirmation
fails, then we can fall back to requesting a new DHCP lease.
Regards,
-Denis
^ permalink raw reply
* Re: iwlwifi firmware load broken in current -git
From: Srinath Mannam @ 2017-09-14 20:04 UTC (permalink / raw)
To: Jens Axboe
Cc: Bjorn Helgaas, Johannes Berg, Luca Coelho, Grumbach, Emmanuel,
linuxwifi, linux-wireless@vger.kernel.org,
linux-pci@vger.kernel.org
In-Reply-To: <93bfbc9b-8829-66fa-f4d6-6d47124e460c@kernel.dk>
Hi Jens Axboe,
On Thu, Sep 14, 2017 at 11:14 PM, Jens Axboe <axboe@kernel.dk> wrote:
> On 09/14/2017 11:35 AM, Jens Axboe wrote:
>> On 09/14/2017 11:28 AM, Srinath Mannam wrote:
>>> Hi Bjorn,
>>>
>>> On Thu, Sep 14, 2017 at 10:52 PM, Jens Axboe <axboe@kernel.dk> wrote:
>>>>
>>>> On 09/14/2017 11:11 AM, Bjorn Helgaas wrote:
>>>>> [+cc linux-pci]
>>>>>
>>>>> On Thu, Sep 14, 2017 at 12:00 PM, Jens Axboe <axboe@kernel.dk> wrote:
>>>>>> On 09/12/2017 02:04 PM, Johannes Berg wrote:
>>>>>>> On Tue, 2017-09-12 at 13:43 -0600, Jens Axboe wrote:
>>>>>>>
>>>>>>>> CC'ing the guilty part and Bjorn. I'm assuming it's the
>>>>>>>> pci_is_enabled() check, since the rest of the patch shouldn't have
>>>>>>>> functional changes.
>>>>>>>
>>>>>>> and pci_enable_bridge() already checks if it's already enabled, but
>>>>>>> still enables mastering in that case if it isn't:
>>>>>>>
>>>>>>> static void pci_enable_bridge(struct pci_dev *dev)
>>>>>>> {
>>>>>>> [...]
>>>>>>> if (pci_is_enabled(dev)) {
>>>>>>> if (!dev->is_busmaster)
>>>>>>> pci_set_master(dev);
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> so I guess due to the new check we end up with mastering disabled, and
>>>>>>> thus the firmware can't load since that's a DMA thing?
>>>>>>
>>>>>> Bjorn/Srinath, any input here? This is a regression that prevents wifi
>>>>>> from working on a pretty standard laptop. It'd suck to have this be in
>>>>>> -rc1. Seems like the trivial fix would be:
>>>>>>
>>>>>>
>>>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>>>> index b0002daa50f3..ffbe11dbdd61 100644
>>>>>> --- a/drivers/pci/pci.c
>>>>>> +++ b/drivers/pci/pci.c
>>>>>> @@ -1394,7 +1394,7 @@ static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
>>>>>> return 0; /* already enabled */
>>>>>>
>>>>>> bridge = pci_upstream_bridge(dev);
>>>>>> - if (bridge && !pci_is_enabled(bridge))
>>>>>> + if (bridge)
>>> With this change and keeping "mutex_lock(&pci_bridge_mutex);" in
>>> pci_enable_bridge functoin will causes a nexted lock.
>>
>> Took a look, and looks like you are right. That code looks like a mess,
>> fwiw.
>>
>> I'd strongly suggest that the bad commit is reverted until a proper
>> solution is found, since the simple one-liner could potentially
>> introduce a deadlock with your patch applied.
>
> BTW, your patch looks pretty bad too, introducing a random mutex
> deep on code that can be recursive. Why isn't this check in
> pci_enable_device_flags() enough to prevent double-enable of
> an upstream bridge?
>
> if (atomic_inc_return(&dev->enable_cnt) > 1)
> return 0; /* already enabled */
>
This check only to verify device enable not for the bus master check.
But device enable function calls the bridge enable if it has the bridge.
Bridge enable function enables both device and bus master.
Here the issue might be because, bridge of endpoint has already set
device enable without set bus master in some other context. which is
wrong.
because all bridges should enable with bridge_enable function only.
So we see the problem In this context, because "if (bridge &&
!pci_is_enabled(bridge))" check stops bridge enable which intern stops
bus master.
pci_enable_bridge function always makes sure that both device and bus
master are enabled in any case. If pci_enable_bridge function is not
called means, that bridge is already has device enable flag set. which
is not from pci_enable_bridge function.
Regards,
Srinath.
> --
> Jens Axboe
>
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Denis Kenzior @ 2017-09-14 19:54 UTC (permalink / raw)
To: Johannes Berg, Arend van Spriel, Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <1505418093.31630.21.camel@sipsolutions.net>
Hi Johannes,
> Well I guess any time that the carrier does in fact go down, you'd also
> reset oper state...
>
> And now that I think about it, that does in fact happen in
> ieee80211_set_disassoc(), which we even go through for FT roaming.
>
> Sounds like something we should fix?
>
If you want roaming to keep oper state UP in all cases, then yes. Does
this work on full mac cards as well?
E.g. if I CMD_CONNECT to AP1, then pre-authenticate to AP2 and issue a
CMD_CONNECT to AP2?
Regards,
-Denis
^ permalink raw reply
* iwlwifi: ToF usage
From: Joel B @ 2017-09-14 19:44 UTC (permalink / raw)
To: linux-wireless
Hi,
Starting to play around with the FTM/ToF support in iwlwifi, but
documentation is (understandably) scarce at this point. Using a pair of
8260:s I had lying around.
Can someone give me some hints on how to work the debugfs API for a
successful measurement?
I've set up one card as AP with hostapd (with ftm_responder=1 and
ftm_initiator=1 in hostapd.conf), the other as a STA.
From the STA, I've played with 'tof_range_request' in debugfs. Writing
send_range_request=1, which it doesn't choke on or anything, but nothing
seems to happen. Guess I need to set things up a bit first, but how?
If it's possible to get this to work at all at this stage, some hints on
how to do it would be great.
Thanks,
Joel
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Johannes Berg @ 2017-09-14 19:42 UTC (permalink / raw)
To: Denis Kenzior, Arend van Spriel, Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <1505418093.31630.21.camel@sipsolutions.net>
On Thu, 2017-09-14 at 21:41 +0200, Johannes Berg wrote:
>
> And now that I think about it, that does in fact happen in
> ieee80211_set_disassoc(), which we even go through for FT roaming.
>
> Sounds like something we should fix?
Not simple though - we'd have to remember to do it later if the
auth/assoc fails or so ...
johannes
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Johannes Berg @ 2017-09-14 19:41 UTC (permalink / raw)
To: Denis Kenzior, Arend van Spriel, Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <7210eb81-be88-8554-deb8-1926606ef64b@gmail.com>
On Thu, 2017-09-14 at 14:37 -0500, Denis Kenzior wrote:
> > > My earlier point is that software roams need to have the exact
> > > same behavior as well. And my understanding is that when we try
> > > to Fast-Transition (e.g. issue a CMD_ASSOCIATE), operstate is no
> > > longer UP.
> I'm talking about the kernel behavior, not wpa_s.
Oh.
> My guys discovered that the kernel seems to twiddle operstate
> automagically? E.g. see description of
> https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=4d
> 20db05d7c8806749db574e9231bd5d1c476c7f
Well I guess any time that the carrier does in fact go down, you'd also
reset oper state...
And now that I think about it, that does in fact happen in
ieee80211_set_disassoc(), which we even go through for FT roaming.
Sounds like something we should fix?
johannes
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Johannes Berg @ 2017-09-14 19:39 UTC (permalink / raw)
To: Denis Kenzior, Arend van Spriel, Arend van Spriel, Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <9219316a-5556-6acf-30de-e9aa65a05706@gmail.com>
On Thu, 2017-09-14 at 14:34 -0500, Denis Kenzior wrote:
> > I think you pretty much have to assume that, otherwise there's no
> > point
> > in roaming at all - you want your connections to stay, possibly
> > voice
> > calls to continue, etc.
>
> I'm all for using this assumption. I just wonder if real world
> disagrees? :)
I think you can probably find networks where this doesn't work, but I
don't think we should cater for that. And corporate networks done with
Cisco, Aruba or similar should have it work correctly, and in fact I'd
assume that it's pretty much only broken if you take two consumer APs
and configure them to the same SSID or something ...
johannes
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Ben Greear @ 2017-09-14 19:38 UTC (permalink / raw)
To: Denis Kenzior, Johannes Berg, Arend van Spriel, Arend van Spriel,
Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <9219316a-5556-6acf-30de-e9aa65a05706@gmail.com>
On 09/14/2017 12:34 PM, Denis Kenzior wrote:
> Hi Johannes,
>
> On 09/14/2017 02:17 PM, Johannes Berg wrote:
>> On Thu, 2017-09-14 at 13:37 -0500, Denis Kenzior wrote:
>>
>>> The question is whether all APs are actually sane after a
>>> roam. E.g. can the STA assume that the same IP address, DHCP lease,
>>> etc is still valid? I heard from various people that this might not
>>> be the case, but we haven't had a chance to verify those claims...
>>
>> I think you pretty much have to assume that, otherwise there's no point
>> in roaming at all - you want your connections to stay, possibly voice
>> calls to continue, etc.
>
> I'm all for using this assumption. I just wonder if real world disagrees? :)
There are different meanings for 'roam'. Are you just talking about
fast-transition roaming?
I would think that the decision to restart DHCP (at least ipv4) should
be in user-space. I'm less sure about how IPv6 should deal with this.
I have tested roaming using FT and normal-ish wpa_supplicant without
doing DHCP, and it works fine. Of course, it also works if you
choose to re-do DHCP.
Thanks,
Ben
>
>> However, I'm not really convinced (any more) that this is actually
>> correct. If I'm reading the supplicant code correctly, then it sets
>> IF_OPER_UP only once the connection is *completed*, so it's already
>> doing what I thought it should be doing and couldn't.
>>
>
> Yes. For a new connection it does something like:
>
> New Key
> Set Key
> New Key (group)
> Set Station (Authorized) (which fails on some drivers)
> Set OperState to UP
>
> Regards,
> -Denis
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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