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>
On WPS init/deinit process, the hostapd clears it's own WPS IE
with 0 length WPS IE. But it fails. Because the parameter to
ioctl is too short. Then hostapd prints a below message.
ioctl[IEEE80211_IOCTL_SET_APPIEBUF]: Invalid argument
It looks like GnuTLS (at least newer versions) is using random padding
on the application data and the previously used 100 byte extra buffer
for tls_connection_encrypt() calls was not enough to handle all cases.
This resulted in semi-random authentication failures with EAP-PEAP and
EAP-TTLS during Phase 2.
Increase the extra space for encryption from 100 to 300 bytes and add an
error message into tls_gnutls.c to make it easier to notice this issue
should it ever show up again even with the larger buffer.
I tried PBC with the hostapd registrar.
I pushed the button with "hostap_cli WPS_PBC".
But hostapd registrar always sends Selected Registrar Config Methods
attribute=0x0000 in beacon/probe response.
wpa_supplicant should not send a dbus reply as response to a method call
if no reply was requested by the caller. Sending a reply even if not
requested is basically no problem but triggers dbus warnings like the
one below.
Feb 9 07:31:23 linux-gvjr dbus-daemon: Rejected send message, 2 matched
rules; type="error", sender=":1.129" (uid=0 pid=30228
comm="/usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wp")
interface="(unset)" member="(unset)" error
name="fi.epitest.hostap.WPASupplicant.InvalidInterface"
requested_reply=0 destination=":1.128" (uid=0 pid=30226
comm="/usr/sbin/NetworkManager "))
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Build EAP-WSC dynamically does not make much sense and with the
dependencies to WPS code from number of places resolving this is not
trivial. It is simpler to just remove this option.
Allow more than one pending PutWLANMessage data to be stored (M2/M2D
from multiple external Registrars) and drop pending M2/M2D messages when
the Enrollee replies with M3.
It looks like Intel wsccmd may send a bogus NewWLANEventMAC
(11:22:33:44:55:66) when acting as an wired external Registrar. Work
around this by going through all STAs if the address does not match and
pick the STA that is in an ongoing WPS registration.
Version attribute processing details are not described in the WPS spec,
but it is safer to allow minor version to change and only refuse to
process the message if major version is different from ours. This
matches with the behavior used in the Intel reference implementation.
It looks like we don't set correspondent Device Password ID attribute in
M2 message during PBC registration. Without it TG185n STA was not able
to connect to our AP in PBC mode. Attached patch fixes this.
If you don't choose OpenSSL as TLS implementation and choose to enable
CONFIG_EAP_TNC you have to link against libdl. The OpenSSL libraries
implicitly link against them, so this might be a reason why it wasn't
noticed yet. I assume the same applies to hostapd.
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.
If wpa_supplicant is started with -u but the DBus service is already
registered wpa_supplicant will bail out. However, it will segfault
in wpa_supplicant_deinit because global->drv_priv wasn't allocated
yet.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
This is based on a patch from Pavel Roskin <proski@gnu.org>, but with
the WIRELESS_DEV part removed instead of moved since it does not apply
anymore. Additional note on client MLME limitations was also added.
MadWifi is unlikely to be in ../head relative to hostapd or
wpa_supplicant, as it would be inside the hostap git repository.
MadWifi sources are more likely to be in a directory called "madwifi"
and residing outside the hostap repository. Using "madwifi" also
demonstrates that the top-level madwifi directory is needed.
Try to match PRI/SEC channel with neighboring 20/40 MHz BSSes per
IEEE 802.11n/D7.0 11.14.3.2. This is not yet complete implementation,
but at least some parts of the 40 MHz coex are improved.
40 MHz operation maybe rejected (i.e., fall back to using 20 MHz) or
pri/sec channels may be switched if needed.
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.
If the bind() on /tmp/wpa_ctrl_<pid>_<in-proc-counter> fails with
EADDRINUSE, there is an existing socket file with the name we are trying
to create. Since getpid() is unique, there cannot be another process
using that socket and we can just unlink the file and try again. This
can speed up client connection if wpa_cli is killed without allowing it
to clean up the socket file. [Bug 288]
I think that the "radius" pointer in the structure hostapd_config is
never used; when the configuration is parsed the related data is stored
in hostapd_bss_config's "radius" var.
This adds mostly feature complete external Registrar support with the
main missing part being proper support for multiple external Registrars
working at the same time and processing of concurrent registrations when
using an external Registrar.
This code is based on Sony/Saice implementation
(https://www.saice-wpsnfc.bz/) and the changes made by Ted Merrill
(Atheros) to make it more suitable for hostapd design and embedded
systems. Some of the UPnP code is based on Intel's libupnp. Copyrights
and licensing are explained in src/wps/wps_upnp.c in more detail.
We must not replace M1 with M2D as the last_msg since we need M1 to
validate a possible M2 after M2D. Since M2D and ACK/NACK replies do not
include Authenticator attribute, we can just ignore M2D as far as
updating last_msg is concerned.
