This avoids an invalid D-Bus call during interface initialization.
The wpa_state change can happen before the D-Bus interface is set up,
so we must be preparted to handle this early event signal. In theory,
it should be possible to reorder initialization code to make sure
D-Bus signals are ready, but that would likely require quite a bit of
code restructuring, so it looks like a safer option for now is to just
skip the early event.
Previous version driver_bsd.c switches the channel in
wpa_driver_bsd_associate(). This patch changes it to use set_freq().
I have tested this patch on FreeBSD 8.0/NetBSD 5.0.2 with hostapd,
wpa_supplicant(AP) and wpa_supplicant(STA).
The wpa_supplicant compilation with CONFIG_AP option and without
CONFIG_IEEE80211R, CONFIG_WPS, NEED_SME, CONFIG_CLIENT_MLME options
results in following messages.
../src/ap/drv_callbacks.o: In function `hostapd_notif_assoc':
../src/ap/drv_callbacks.c:59: undefined reference to
`ieee802_11_parse_elems'
gmake: *** [wpa_supplicant] Error 1
Add a new wpa_supplicant state: interface disabled. This can be used
to allow wpa_supplicant to be running with the network interface even
when the driver does not actually allow any radio operations (e.g.,
due to rfkill).
Allow driver_nl80211.c and driver_wext.c to start while rfkill is in
blocked state (i.e., when ifconfig up fails) and process rfkill
events to block/unblock WLAN.
Use regular expression matches to see if input is not the (now translated?)
string "Select any network" and is a "<network id>: <ssid>" string or the
"all" keyword where that is applicable.
Signed-off-by: Kel Modderman <kel@otaku42.de>
Vendor-specific IEs are supposed to be in the end of the frame, so move
WMM into the end of Beacon, Probe Response, and (Re)Association Response
frames. In addition, move HT IEs to be later in (Re)Association
Response to match the correct order.
hostapd_eid_wpa() adds multiple IEs and the end result may not always be
correct. If WPA is enabled, WPA IE (vendor-specific) gets added in the
middle of the frame and not in the end. This would require a larger
change to spliut the IEs from WPA module into separate locations when
constructing Beacon and Probe Response frames. This is not yet addressed.
Commit 83935317a7 added forced
disconnection in case of 4-way handshake failures. However, it should
not have changed the case where the supplicant is requesting fallback
to full EAP authentication if the PMKID in EAPOL-Key message 1/4 is
not know. This case needs to send an EAPOL-Start frame instead of
EAPOL-Key message 2/4.
This works around a problem with APs that try to force PMKSA caching
even when the client does not include PMKID in (re)association request
frame to request it. [Bug 355]
Commit c02d52b405 removed direct calls
to the WPA authenticator, but the change here was incorrect.
EAPOL_SM_USES_WPA was supposed to be set based on sta->wpa_sm being
set, i.e., no need to check for PMKSA entries for that.
While this could potentially change EAPOL Key TX state machine behavior,
no clear problems have been identified so far. Anyway, better fix this
to get the correct flags set for EAPOL authenticator state machine.
When using WPS, we may end up here if the STA manages to re-associate
without the previous STA entry getting removed. Consequently, we need to
make sure that the WPA state machines gets initialized properly at this
point.
62477841a1 tried to address fragmentation
issues, but it did not address the case where the final EAP-TNC
message gets fragmented. Move the state update to the correct place
to address this case, too.
There are no subdirectories in any of these directories or plans
for adding ones. As such, there is no point in running the loop
that does not do anything and can cause problems with some shells.
Both the wildcard VLAN entry and the statically configured VLAN
interfaces should behave in the same way. Initializing the
full dynamic VLAN code before adding the statically configured VLAN
interfaces allows the same processing to be applied to both statically
and dynamically added VLAN interface (i.e., also the statically
configured ones will be added to a bridge).
This allows wpa_supplicant to be started quickly with an empty
configuration. If an external program wants to fetch scan results
from wpa_supplicant, it will need to request a scan explicitly
in this type of case.
The WPS IE was overriding the WPA/RSN IE in driver based MLME case
(hostapd_notif_assoc), but the MLME code here was not using WPS IE
correctly, i.e., it allowed the WPA/RSN IE override the operation.
The returned buffer length was hardcoded to be the prime length
which resulted in shorter results being padded in the end. However,
the results from DH code are supposed to be unpadded (and when used
with WPS, the padding is done in WPS code and it is added to the
beginning of the buffer). This fixes WPS key derivation errors
in about 1/256 of runs ("WPS: Incorrect Authenticator") when using
the internal crypto code.
