Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 1月, 2017 2 次提交
  3. 09 1月, 2017 1 次提交
  5. 16 12月, 2016 1 次提交
  7. 09 12月, 2016 1 次提交
    • V
      nl80211: Use different attrs for BSSID and random MAC addr in scan req · 2fa436b3
      由 Vamsi Krishna 提交于 
      NL80211_ATTR_MAC was used to set both the specific BSSID to be scanned
and the random MAC address to be used when privacy is enabled. When both
the features are enabled, both the BSSID and the local MAC address were
getting same value causing Probe Request frames to go with unintended
DA. Hence, this has been fixed by using a different NL80211_ATTR_BSSID
attribute to set the specific BSSID (which was the more recent addition
in cfg80211) for a scan.

Backwards compatibility with old userspace software is maintained to
some extent by allowing NL80211_ATTR_MAC to be used to set the specific
BSSID when scanning without enabling random MAC address use.

Scanning with random source MAC address was introduced by commit
ad2b26ab ("cfg80211: allow drivers to support random MAC addresses
for scan") and the issue was introduced with the addition of the second
user for the same attribute in commit 818965d3 ("cfg80211: Allow a
scan request for a specific BSSID").

Fixes: 818965d3 ("cfg80211: Allow a scan request for a specific BSSID")
Signed-off-by: NVamsi Krishna <vamsin@qti.qualcomm.com>
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2fa436b3
  9. 27 10月, 2016 6 次提交
  11. 13 10月, 2016 1 次提交
    • P
      cfg80211: support virtual interfaces with different beacon intervals · 0c317a02
      由 Purushottam Kushwaha 提交于 
      This commit provides a mechanism for the host drivers to advertise the
support for different beacon intervals among the respective interface
combinations in a group, through NL80211_IFACE_COMB_BI_MIN_GCD (u32).

This value will be compared against GCD of all beaconing interfaces of
matching combinations.

If the driver doesn't advertise this value, the old behaviour where
all beacon intervals must be identical is retained.

If it is specified, then any beacon interval for an interface in the
interface combination as well as the GCD of all active beacon intervals
in the combination must be greater or equal to this value.
Signed-off-by: NPurushottam Kushwaha <pkushwah@qti.qualcomm.com>
[change commit message, some variable names, small other things]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0c317a02
  13. 30 9月, 2016 5 次提交
  15. 26 9月, 2016 1 次提交
  17. 06 7月, 2016 3 次提交
  19. 31 5月, 2016 2 次提交
    • K
      cfg80211: Advertise extended capabilities per interface type to userspace · 019ae3a9
      由 Kanchanapally, Vidyullatha 提交于 
      The driver extended capabilities may differ for different
interface types which the userspace needs to know (for
example the fine timing measurement initiator and responder
bits might differ for a station and AP). Add a new nl80211
attribute to provide extended capabilities per interface type
to userspace.
Signed-off-by: NVidyullatha Kanchanapally <vkanchan@qti.qualcomm.com>
Reviewed-by: NJouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      019ae3a9
    • J
      cfg80211: Allow cfg80211_connect_result() errors to be distinguished · bf1ecd21
      由 Jouni Malinen 提交于 
      Previously, the status parameter to cfg80211_connect_result() was
documented as using WLAN_STATUS_UNSPECIFIED_FAILURE (1) when the real
status code for the failure is not known. This value can be used by an
AP (and often is) and as such, user space cannot distinguish between
explicitly rejected authentication/association and not being able to
even try to associate or not receiving a response from the AP.

Add a new inline function, cfg80211_connect_timeout(), to be used when
the driver knows that the connection attempt failed due to a reason
where connection could not be attempt or no response was received from
the AP. The internal functions now allow a negative status value (-1) to
be used as an indication of this special case. This results in the
NL80211_ATTR_TIMED_OUT to be added to the NL80211_CMD_CONNECT event to
allow user space to determine this case was hit. For backwards
compatibility, NL80211_STATUS_CODE with the value
WLAN_STATUS_UNSPECIFIED_FAILURE is still indicated in the event in such
a case.
Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com>
[johannes: fix cfg80211_connect_bss() prototype to use int for status,
 add cfg80211_connect_timeout() to docbook, fix docbook]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      bf1ecd21
  21. 27 4月, 2016 1 次提交
  23. 26 4月, 2016 3 次提交
  25. 12 4月, 2016 2 次提交
  27. 06 4月, 2016 1 次提交
  29. 05 4月, 2016 2 次提交
  31. 24 2月, 2016 2 次提交
    • B
      cfg80211: Add global RRM capability · 0c9ca11b
      由 Beni Lev 提交于 
      Today, the supplicant will add the RRM capabilities
Information Element in the association request only if
Quiet period is supported (NL80211_FEATURE_QUIET).

Quiet is one of many RRM features, and there are other RRM
features that are not related to Quiet (e.g. neighbor
report). Therefore, requiring Quiet to enable RRM is too
restrictive.
Some of the features, like neighbor report, can be
supported by user space without any help from the kernel.
Hence adding the RRM capabilities IE to association request
should be the sole user space's decision.
Removing the RRM dependency on Quiet in the driver solves
this problem, but using an old driver with a user space
tool that would not require Quiet feature would be
problematic: the user space would add NL80211_ATTR_USE_RRM
in the association request even if the kernel doesn't
advertize NL80211_FEATURE_QUIET and the association would
be denied by the kernel.

This solution adds a global RRM capability, that tells user
space that it can request RRM capabilities IE publishment
without any specific feature support in the kernel.
Signed-off-by: NBeni Lev <beni.lev@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0c9ca11b
    • L
      cfg80211: basic support for PBSS network type · 34d50519
      由 Lior David 提交于 
      PBSS (Personal Basic Service Set) is a new BSS type for DMG
networks. It is similar to infrastructure BSS, having an AP-like
entity called PCP (PBSS Control Point), but it has few differences.
PBSS support is mandatory for 11ad devices.

Add support for PBSS by introducing a new PBSS flag attribute.
The PBSS flag is used in the START_AP command to request starting
a PCP instead of an AP, and in the CONNECT command to request
connecting to a PCP instead of an AP.
Signed-off-by: NLior David <liord@codeaurora.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34d50519
  33. 04 12月, 2015 2 次提交
  35. 13 10月, 2015 2 次提交
    • A
      cfg80211: Add multiple scan plans for scheduled scan · 3b06d277
      由 Avraham Stern 提交于 
      Add the option to configure multiple 'scan plans' for scheduled scan.
Each 'scan plan' defines the number of scan cycles and the interval
between scans. The scan plans are executed in the order they were
configured. The last scan plan will always run infinitely and thus
defines only the interval between scans.
The maximum number of scan plans supported by the device and the
maximum number of iterations in a single scan plan are advertised
to userspace so it can configure the scan plans appropriately.

When scheduled scan results are received there is no way to know which
scan plan is being currently executed, so there is no way to know when
the next scan iteration will start. This is not a problem, however.
The scan start timestamp is only used for flushing old scan results,
and there is no difference between flushing all results received until
the end of the previous iteration or the start of the current one,
since no results will be received in between.
Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3b06d277
    • D
      nl80211: allow BSS data to include CLOCK_BOOTTIME timestamp · 6e19bc4b
      由 Dmitry Shmidt 提交于 
      For location and connectivity services, userspace would often like
to know the time when the BSS was last seen. The current "last seen"
value is calculated in a way that makes it less useful, especially
if the system suspended in the meantime.

Add the ability for the driver to report a real CLOCK_BOOTTIME stamp
that can then be reported to userspace (if present).

Drivers wishing to use this must be converted to the new API to call
cfg80211_inform_bss_data() or cfg80211_inform_bss_frame_data(). They
need to ensure the reported value is accurate enough even when the
frame might have been buffered in the device (e.g. firmware.)
Signed-off-by: NDmitry Shmidt <dimitrysh@google.com>
[modified to use struct, inlines]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6e19bc4b
  37. 06 5月, 2015 1 次提交
  39. 30 3月, 2015 1 次提交