RE: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
>Ah, heh. Yes, I think this is exactly the use case they have in mind.
>Each of the multiple BSSes is represented by its own AP type virtual interface.
Yes . This is the requirement we are targeting . The use case is also to have
different beacon interval for these VAP's and hence this patch.
Please let us know if this patch with typo addressed to "different" is
acceptable. Shall raise another patch set accordingly.
Regards,
Sunil
N�r��yb�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
On 18-7-2016 21:21, Arend Van Spriel wrote: > On 18-7-2016 21:15, Johannes Berg wrote: >> On Mon, 2016-07-18 at 21:13 +0200, Arend Van Spriel wrote: >>> >>> On 18-7-2016 20:56, Johannes Berg wrote: On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote: > Driver may allow support for different beacon interval on virtual > interfaces. > Allow if such support is advertised by driver. This adds new > ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL. We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface combinations, perhaps it would make sense to also put this flag there? >>> >>> Hi Johannes, >>> >>> Was looking at the same thing. The description of that flag was a bit >>> unclear to me. >>> >>> """ >>> * @beacon_int_infra_match: In this combination, the beacon intervals >>> * between infrastructure and AP types must match. This is >>> required >>> * only in special cases. >>> """ >>> >>> It is not explicitly stated but it implies the STA vif is connected, >>> right. >> >> Yes. >> >> Forget this flag. I don't think any driver sets it - it was a hack for >> iwldvm. I also don't think any userspace cares about it, and it likely >> never really worked. What if the STA vif reconnects anyway? Uhm. My memory tells me differently and LXR also [1] :-p Regards, Arend [1] http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c#L6182 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
On 07/18/2016 12:14 PM, Johannes Berg wrote: On Mon, 2016-07-18 at 12:04 -0700, Ben Greear wrote: On 07/18/2016 11:56 AM, Johannes Berg wrote: On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote: Driver may allow support for different beacon interval on virtual interfaces. Allow if such support is advertised by driver. This adds new ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL. We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface combinations, perhaps it would make sense to also put this flag there? I was under impression that ath9k had supported this for years, but I guess I haven't tested it lately It may very well have, but if userspace can't rely on it because other drivers don't then it's pretty pointless. A flag would be nice, but for backwards compat, it could be a negative flag. But, if mac80211 has to be patched to make this work, then maybe the ath9k feature has been disabled/broken for some time and wouldn't matter anyway. Also, ath9k had some restrictions about having the timers be certain multiples of each other so the hardware could properly service beacons for multiple vdevs. If chip-specific restrictions remain, then it may be almost impossible to communicate this properly to the hostapd/userspace. At best, the driver could just fail to start the vdev in case of mismatch? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
> Whoops. Should not use abbreviations like that. I meant the > Multiple-BSSID functionality (from hostapd): Ah, heh. Yes, I think this is exactly the use case they have in mind. Each of the multiple BSSes is represented by its own AP type virtual interface. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
On 18-7-2016 21:15, Johannes Berg wrote: > On Mon, 2016-07-18 at 21:13 +0200, Arend Van Spriel wrote: >> >> On 18-7-2016 20:56, Johannes Berg wrote: >>> On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote: Driver may allow support for different beacon interval on virtual interfaces. Allow if such support is advertised by driver. This adds new ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL. >>> >>> We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface >>> combinations, >>> perhaps it would make sense to also put this flag there? >> >> Hi Johannes, >> >> Was looking at the same thing. The description of that flag was a bit >> unclear to me. >> >> """ >> * @beacon_int_infra_match: In this combination, the beacon intervals >> * between infrastructure and AP types must match. This is >> required >> * only in special cases. >> """ >> >> It is not explicitly stated but it implies the STA vif is connected, >> right. > > Yes. > > Forget this flag. I don't think any driver sets it - it was a hack for > iwldvm. I also don't think any userspace cares about it, and it likely > never really worked. What if the STA vif reconnects anyway? > > I was merely pointing this out wrt. the grouping and where to put > something new. > >> Probably going off-topic here, but I am also wondering about the >> use-case of the above patch. I have been looking at M-BSS. Toward >> user-space these are AP interfaces, but like described in >> hostapd.conf >> example a number of AP configuration items are required to be equal. >> Now >> we also have chipsets with two 802.11 cores and on each an AP could >> be >> setup with independent beacon interval. So to make the distinction >> would >> it make sense to introduce MBSS_AP iftype? Or does AP_VLAN cover the >> MBSS use-case? >> > > I don't think AP_VLAN does, but isn't a mesh portal simply a mesh point > interface and an AP interface? Whoops. Should not use abbreviations like that. I meant the Multiple-BSSID functionality (from hostapd): # Multiple BSSID support ## # # Above configuration is using the default interface (wlan#, or multi-SSID VLAN # interfaces). Other BSSIDs can be added by using separator 'bss' with # default interface name to be allocated for the data packets of the new BSS. # # hostapd will generate BSSID mask based on the BSSIDs that are # configured. hostapd will verify that dev_addr & MASK == dev_addr. If this is # not the case, the MAC address of the radio must be changed before starting # hostapd (ifconfig wlan0 hw ether ). If a BSSID is configured for # every secondary BSS, this limitation is not applied at hostapd and other # masks may be used if the driver supports them (e.g., swap the locally # administered bit) # # BSSIDs are assigned in order to each BSS, unless an explicit BSSID is # specified using the 'bssid' parameter. # If an explicit BSSID is specified, it must be chosen such that it: # - results in a valid MASK that covers it and the dev_addr # - is not the same as the MAC address of the radio # - is not the same as any other explicitly specified BSSID # # Alternatively, the 'use_driver_iface_addr' parameter can be used to request # hostapd to use the driver auto-generated interface address (e.g., to use the # exact MAC addresses allocated to the device). # # Not all drivers support multiple BSSes. The exact mechanism for determining # the driver capabilities is driver specific. With the current (i.e., a recent # kernel) drivers using nl80211, this information can be checked with "iw list" # (search for "valid interface combinations"). # # Please note that hostapd uses some of the values configured for the first BSS # as the defaults for the following BSSes. However, it is recommended that all # BSSes include explicit configuration of all relevant configuration items. # Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
On Mon, 2016-07-18 at 21:13 +0200, Arend Van Spriel wrote: > > On 18-7-2016 20:56, Johannes Berg wrote: > > On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote: > > > Driver may allow support for different beacon interval on virtual > > > interfaces. > > > Allow if such support is advertised by driver. This adds new > > > ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL. > > > > We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface > > combinations, > > perhaps it would make sense to also put this flag there? > > Hi Johannes, > > Was looking at the same thing. The description of that flag was a bit > unclear to me. > > """ > * @beacon_int_infra_match: In this combination, the beacon intervals > * between infrastructure and AP types must match. This is > required > * only in special cases. > """ > > It is not explicitly stated but it implies the STA vif is connected, > right. Yes. Forget this flag. I don't think any driver sets it - it was a hack for iwldvm. I also don't think any userspace cares about it, and it likely never really worked. What if the STA vif reconnects anyway? I was merely pointing this out wrt. the grouping and where to put something new. > Probably going off-topic here, but I am also wondering about the > use-case of the above patch. I have been looking at M-BSS. Toward > user-space these are AP interfaces, but like described in > hostapd.conf > example a number of AP configuration items are required to be equal. > Now > we also have chipsets with two 802.11 cores and on each an AP could > be > setup with independent beacon interval. So to make the distinction > would > it make sense to introduce MBSS_AP iftype? Or does AP_VLAN cover the > MBSS use-case? > I don't think AP_VLAN does, but isn't a mesh portal simply a mesh point interface and an AP interface? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
On 18-7-2016 20:56, Johannes Berg wrote: > On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote: >> Driver may allow support for different beacon interval on virtual >> interfaces. >> Allow if such support is advertised by driver. This adds new >> ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL. > > We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface combinations, > perhaps it would make sense to also put this flag there? Hi Johannes, Was looking at the same thing. The description of that flag was a bit unclear to me. """ * @beacon_int_infra_match: In this combination, the beacon intervals * between infrastructure and AP types must match. This is required * only in special cases. """ It is not explicitly stated but it implies the STA vif is connected, right. Probably going off-topic here, but I am also wondering about the use-case of the above patch. I have been looking at M-BSS. Toward user-space these are AP interfaces, but like described in hostapd.conf example a number of AP configuration items are required to be equal. Now we also have chipsets with two 802.11 cores and on each an AP could be setup with independent beacon interval. So to make the distinction would it make sense to introduce MBSS_AP iftype? Or does AP_VLAN cover the MBSS use-case? Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
On Mon, 2016-07-18 at 12:04 -0700, Ben Greear wrote: > > On 07/18/2016 11:56 AM, Johannes Berg wrote: > > On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote: > > > Driver may allow support for different beacon interval on virtual > > > interfaces. > > > Allow if such support is advertised by driver. This adds new > > > ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL. > > > > We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface > > combinations, > > perhaps it would make sense to also put this flag there? > > I was under impression that ath9k had supported this for years, > but I guess I haven't tested it lately > It may very well have, but if userspace can't rely on it because other drivers don't then it's pretty pointless. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
On 07/18/2016 11:56 AM, Johannes Berg wrote: On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote: Driver may allow support for different beacon interval on virtual interfaces. Allow if such support is advertised by driver. This adds new ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL. We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface combinations, perhaps it would make sense to also put this flag there? I was under impression that ath9k had supported this for years, but I guess I haven't tested it lately Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
On Mon, 2016-07-18 at 19:23 +0530, Purushottam Kushwaha wrote: > Driver may allow support for different beacon interval on virtual > interfaces. > Allow if such support is advertised by driver. This adds new > ext_feature as NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL. We have NL80211_IFACE_COMB_STA_AP_BI_MATCH in interface combinations, perhaps it would make sense to also put this flag there? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cfg80211: Allow differnt beacon interval if driver supports
Purushottam Kushwaha writes: > Driver may allow support for different beacon interval on virtual interfaces. > Allow if such support is advertised by driver. This adds new ext_feature as > NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL. > > Signed-off-by: Purushottam Kushwaha A typo in the title: "differnt" -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
