It looks like both new nl80211 operations (scan and auth/assoc) end up
being added in Linux 2.6.30, so we do not need to maintain the backwards
compatibility code in wpa_supplicant.
A new network block parameter, scan_freq, can be used to specify subset
of frequencies to scan. This can speed up scanning process considerably
if it is known that only a small subset of channels is actually used in
the network. A union of configured frequencies for all enabled network
blocks is used in scan requests.
Currently, only driver_nl80211.c has support for this functionality.
For example, following parameter marks 2.4 GHz channels 1, 6, 11 to be
scanned: scan_freq=2412 2437 2462
This version is adding the configuration option (mode=2) for this and
driver capability reporting to figure out whether AP mode can be used.
However, this does not actually implement any real functionality yet.
Need to set drv->ifindex before calling set_mode(). In addition, set the
mode before setting the interface up to avoid having to set it down
again.
Add more useful error message on mode changes.
All these driver handlers can be implemented in associate() handler
which gets all the needed information in the parameters structure. The
old functions that provided only a single parameter will be removed
eventually to clean up the driver_ops structure, so driver wrappers
should start using the newer mechanism.
This can be used, e.g., with mac80211-based Linux drivers with
nl80211. This allows over-the-air FT protocol to be used (IEEE
802.11r).
Since the nl80211 interface needed for this is very recent (added
today into wireless-testing.git), driver_nl80211.c has backwards
compatibility code that uses WEXT for association if the kernel does
not support the new commands. This compatibility code can be
disabled by defining NO_WEXT_COMPAT. That code will also be removed
at some point to clean up driver_nl80211.c.
This adds first part of FT resource request as part of Reassocition
Request frame (i.e., FT Protocol, not FT Resource Request Protocol).
wpa_supplicant can generate a test resource request when driver_test.c
is used with internal MLME code and hostapd can verify the FTIE MIC
properly with the included RIC Request.
The actual RIC Request IEs are not processed yet and hostapd does not
yet reply with RIC Response (nor would wpa_supplicant be able to
validate the FTIE MIC for a frame with RIC Response).
This is just there very first step on being able to do something with
wireless LAN on Vista. There is some example code for requesting a scan,
but it does not work in its current form. Anyway, this adds a wpa_printf
noting that Native 802.11 drivers are not yet supported.
This is done with wired interfaces to fix IEEE 802.1X authentication
when the authenticator uses the group address (which should be happening
with wired Ethernet authentication).
This allows wpa_supplicant to complete wired authentication successfully
on Vista with a NDIS 6 driver, but the change is likely needed for
Windows XP, too.
Do not use just the driver name for this since driver_ndis.c supports
both wired and wireless NDIS drivers and needs to indicate the driver
type after initialization.
These flags are used to mark which values (level, noise, qual) are
invalid (not available from the driver) and whether level is using dBm.
D-Bus interface will now only report the values that were available.
This does not actually send out separate scan requests for each SSID,
but the debug output can be used to test scan2() functionality with
multiple SSIDs.
This can be used to provide support for scanning multiple SSIDs at a
time to optimize scan_ssid=1 operations. In addition, Probe Request IEs
will be available to scan2() (e.g., for WPS PBC scanning).
For example, -Dnl80211,wext could be used to automatically select
between nl80211 and wext. The first driver wrapper that is able to
initialize the interface will be used.
This workaround was needed with some drivers that used WEXT, but there
is no known nl80211-enabled driver that would need this, so lets get rid
of the extra delay.
The driver wrappers can now inform wpa_supplicant how many SSIDs can
be used in a single scan request (i.e., send multiple Probe Requests
per channel). This value is not yet used, but it can eventually be used
to allow a new scan command to specify multiple SSIDs to speed up
scan_ssid=1 operations. In addition, a warning could be printed if
scan_ssid=1 is used with a driver that does not support it
(max_scan_ssids=0).
Some drivers (for example ipw2100) do not report signal level but only
signal quality. wpa_supplicant already uses the signal quality if no
level is reported and all other comparision parameters are equal to sort
the scan results. However, if two APs have different max rates and the
signal level does not differ much wpa_supplicant chooses the AP with the
higher max rate.
In case of ipw2100 no signal level is reported and thus wpa_supplicant
always takes the AP with higher max rate even if its signal quality is
really low. For example if AP1 (max rate 11Mb/s, 80% signal quality) and
AP2 (max rate 54 Mb/s, 20% signal quality) are found by a scan
wpa_supplicant would choose AP2.
Hence, if no signal level is reported depend on the signal quality if
max rate should be compared. A quality difference of 10% is considered
acceptable in favor of the higher max rate.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Really disassociate when tearing stuff down; drivers may sometimes
(legally) keep trying to reassociate unless the BSSID is unlocked. If
the SSID is unlocked too, under WEXT drivers are able to pick an SSID to
associate, so kill that behavior by setting a bogus SSID. Unfortunately
WEXT doesn't provide an easy method to say "stop whatever doing and just
idle".
Signed-off-by: Dan Williams <dcbw@redhat.com>
The madwifi driver has interface to set probe request ie.
Attached patch will enable the functionality.
I could see probe request includes WSC IE with this patch.
We can now handle up to 65535 byte result buffer which is the maximum
due to WEXT using 16-bit length field. Previously, this was limited to
32768 bytes in practice even through we tried with 65536 and 131072
buffers which we just truncated into 0 in the 16-bit variable.
This more or less doubles the number of BSSes we can received from scan
results.
I am terribly sorry, but because of a lack of testing equipment the
patch was submitted not properly tested.
Because the chipset documentation is not publicly available all
behaviour has to be found out by experimentation. The other day, I
made some incorrect assumptions based on my findings.
I do believe the attached patch does support the whole RoboSwitch line
(5325, 5350, 5352, 5365 and others). It is a drop-in substitution for
my previous submission.
The RoboSwitch driver of wpa_supplicant had one shortcoming: not
supporting the 5365 series. I believe the patch attached fixes this
problem.
Furthermore it contains a small readability rewrite. It basically is an
explicit loop-rollout so that the wpa_driver_roboswitch_leave style
matches that of wpa_driver_roboswitch_join.
This commit adds a new build option, CONFIG_IBSS_RSN=y, that can be used
to enable RSN support for IBSS. This links in RSN Authenticator code
from hostapd and adds code for managing per-peer information for IBSS. A
new wpa_cli command or driver event can be used to request RSN
authentication with an IBSS peer. New RSN Authenticator and Supplicant
will be allocated for each peer.
The basic state machine setup code is included in this commit, but the
state machines are not properly started yet. In addition, some of the
callback functions are not yet complete.
This is needed for airo driver to work correctly and no other driver
seems to care, so the change is safe to make. This has been in number of
distro releases for a long time and no issues have been reported.
