The vm-config in the subdirectory is less useful as it
will get removed by "git clean" and similar, so read a
config file from ~/.wpas-vm-config in addition.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If we already know the SSID of the P2P group we are trying to join, use
that SSID to limit scan responses and BSS selection since we do not
really look for any other network in this case. In addition, this can
fix cases where the peer has just changed its SSID (e.g., started a new
group) and there may be multiple BSS entries for the same BSSID.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
It looks like slow virtual machines may have issues to complete some EAP
authentication cases (e.g., EAP-EKE in ap_ft_eap) within the 10 second
timeout under load. Double the timeout to avoid incorrect test failures.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
It was possible for the previous test case to leave unexpected BSS or
P2P peer table entries if a scan was in progress when the FLUSH command
was used. This could result in test failures, e.g., when running
discovery_dev_type_go followed by discovery_group_client where a P2P
peer was discovered on another channel at the end of the former test
case from a scan that was running durign the FLUSH operation that was
supposed to remove all P2P peers. This could result in
discovery_group_client failing due to dev[2] trying to send the
discoverability frame on incorrect channel (the one learned in the
previous test case) since discover_peer() skipped a new device
discovery. Fix this by running FLUSH operation again if a pending scan
operation is detected during the first FLUSH operation.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
All te network blocks and credentials were already cleared, but
configurations blobs should also be cleared here, e.g., to get
more consistent behavior test cases using EAP-FAST PACs.
Signed-hostap: Jouni Malinen <j@w1.fi>
Some EAP methods can go through a step that is expected to fail and as
such, should not trigger temporary network disabling when processing
EAP-Failure or deauthentication. EAP-WSC for WPS was already handled as
a special case, but similar behavior is needed for EAP-FAST with
unauthenticated provisioning.
Signed-hostap: Jouni Malinen <j@w1.fi>
EAP-FAST requires pac_file to be configured, so make it clearer from the
debug output if missing configuration parameter was the reason for
EAP-FAST initialization failing.
Signed-hostap: Jouni Malinen <j@w1.fi>
The hash return buffer was previously left uninitialized in case
externally stored password ("password=ext:...") was used. This could
result in MSCHAPv2 failure if that uninitialized memory happened to be
something else than zero.
Signed-hostap: Jouni Malinen <j@w1.fi>
It is possible for the configuration to be temporarily invalid when
adding a new AP through SET commands followed by ENABLE. Avoid this
issue by using less strict validation on SET commands and perform full
configuration validation only on ENABLE. Use cases with configuration
file maintain their previous behavior, i.e., full validation after the
file has been read.
Signed-hostap: Jouni Malinen <j@w1.fi>
In addition, add the earlier tests in the new test_ssid.py file that was
forgotten from the previous commit
d78f33030d.
Signed-hostap: Jouni Malinen <j@w1.fi>
This reverts commit 792c8877c3
('P2P: Send GO Negotiation Confirm without wait').
Some drivers rely on the wait period for sending packets on the
off-channel. If the wait value is small, there's a race condition where
the driver ROC might complete before the packet was sent out. This
doesn't impede other drivers, as the wait is cancelled when a
Tx-completion arrives from the remote peer.
Signed-hostap: Arik Nemtsov <arik@wizery.com>
The missing call to scan_action_done() may keep us off-channel for 250
ms following sending GO Negotiation Response. In case the operating
channel is different from this channel and we're GO, a race could lead
to start beaconing while off-channel. This could potentially cause the
Beacon frames to go out on incorrect channel with some drivers.
Signed-hostap: Eyal Shapira <eyal@wizery.com>
The error path in bsd_init() on struct bsd_driver_data allocation was
jumping to location where drv is dereferenced. That will crash and it is
easier to just return from the function since no cleanup steps are
needed in this case.
Signed-hostap: Jouni Malinen <j@w1.fi>
Currently these three steps runs for each event.
1. get buffer size via system
2. allocate a memory for event
3. free the memory
The wpa_supplicant receives 4 events from boot to be connected.
So this patch prepare the event buffer at the init process.
I have tested wpa_supplicant on NetBSD 6.1.2.
But I could not tested hostapd because I do not have AP enabled device.
Signed-hostap: Masashi Honma <masashi.honma@gmail.com>
WPS-ER-AP-REMOVE event from the ER is sent before HTTP UNSUBSCRIBE has
been completed. As such, it was possible for the following scan
validation step to be started before the AP has had a chance to react to
the ER status change. Makes this less likely to fail by waiting 200 ms
before starting the last scan.
Signed-hostap: Jouni Malinen <j@w1.fi>
There is no need to wait for the 15 second group formation timeout to
clear the state if WPS failure is detected during P2P group formation.
Allow the WPS exchange steps (WSC_NACK and EAP-Failure) to be completed
and remove the group to get rid of the extra wait.
Signed-hostap: Jouni Malinen <j@w1.fi>
A TX status event could be received after the AP interface has already
been deinitialized. This needs to check for NULL pointer before trying
to indicate the event to AP functions.
Signed-hostap: Jouni Malinen <j@w1.fi>
Previously, only the last response data was kept in memory. This
increases that to hold up to two last responses to allow some more
parallel operations to be requested. In addition, the response data is
now freed as soon as the external program has fetched it.
Signed-hostap: Jouni Malinen <j@w1.fi>
Replace channel_switch_supported flag of the
wpa_driver_nl80211_data by WPA_DRIVER_FLAGS_AP_CSA inside
wpa_driver_capa.flags. It makes more sense and also can
be accessed by wpa_supplicant.
Signed-hostap: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
This is just like the same command in wpa_supplicant, i.e., "hostapd_cli
status driver" can be used to fetch information about the driver status
and capabilities.
Signed-hostap: Jouni Malinen <j@w1.fi>
