This could have been using an uninitialized variable instead of
purposefully random value in picking up the channel. There is not
much of a difference for the use case here, but anyway, we may
as well do what was initially planned here and.
The destination address for p2p_serv_disc_resp must always be set
to an individual MAC address unlike p2p_serv_disc_req which may use
00:00:00:00:00:00 to indicate wildcard query. As such, we should not
try to check for this special case here.
drivers.mak is shared between hostapd and wpa_supplicant and
compiling them together may create "wrong" flags.
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
We are not actually interested in the PD Response in join-a-group
case, so there is no point in trying to send PD Request until the
response is received. This avoids an extra PD getting started after
a join-a-group operation in some cases.
The ieee80211_sta_free_hw_features() function is now used outside
the MLME code, so better make sure it gets included in the build
to avoid leaking memory.
This is needed to avoid problems with other applications setting and
leaving the interface to IF_OPER_DORMANT state. In AP mode, the interface
is ready immediately after the keys are set, so we better make sure the
DORMANT state does not prevent normal operations after that.
This is needed to avoid issues with APs that restart their UPnP,
e.g., when ER reconfigures them. The previously known settings are
now cached and taken into use if an AP is detected to leave
(ssdp:byebye) and then return.
Verify that the UUID given to wps_er_pbc command is known and only
activate PBC mode on the matching AP. The UUID can be that of the
AP or the station/Enrollee.
Add a new driver event, EVENT_INTERFACE_UNAVAILABLE, for indicating
that the driver is not able to continue operating the virtual
interface in its current mode anymore, e.g., due to operating
channel for GO interface forced to a DFS channel by another virtual
interface.
When this happens for a P2P group interface, the P2P group will
be terminated and P2P-GROUP-REMOVED event shows the reason for
this as follows:
P2P-GROUP-REMOVED wlan0 GO reason=UNAVAILABLE
Replacing the BSSID with 'any' has never worked with wps_reg
command, so better not claim it could work. In addition, reject
this is wpa_supplicant to make it clearer that the operation
fails.
A new configuration parameter, p2p_group_idle, can now be used to set
idle timeout value for P2P groups in seconds (0 = no timeout). If set,
this values is used to remove P2P group (both GO and P2P client)
interfaces after the group has been idle (no clients/GO seen) for the
configuration duration.
The P2P-GROUP-REMOVED event is now indicating the reason for group
removal when known. For example:
P2P-GROUP-REMOVED wlan0 GO reason=REQUESTED
P2P-GROUP-REMOVED wlan1 client reason=IDLE
Some driver wrappers may end up indicating a disassociation or
deauthentication event without the address of the station, e.g.,
based on a previous non-AP mode event. Avoid crashing hostapd
by verifying that the require address parameter is available in
the event before processing it.
In order to avoid confusing the driver with a new remain-on-channel
request, delay sending of a new Action frame if the driver indicates
Action frame RX diromg a scan.
This is needed to optimize response to GO Negotiation Request frames.
The extra remain-on-channel cancel followed by new remain-on-channel for
the same channel takes too much time with some driver/firmware
designs for the response to go out quickly enough to avoid peer
timing out while waiting for our response.
The driver wrapper may indicate EVENT_CHANNEL_LIST_CHANGED before
completing init(). This would likely result in segfault when driver
channel list is being read as part of processing this event when
P2P is enabled.
This command can be used to enroll a network based on a local
network configuration block instead of having to (re-)learn the
current AP settings with wps_er_learn.
This test command is supposed to change the WPS version number in all
places immediately, so make sure that the IEs used in management
frames get updated immediately.
This is not supposed to happen, but in theory, the GO may end up
changing its channels at some point. While it would be reasonable
to use one of the common channels, GO may be forced to use another
channel. The most likely reason for this would be if the P2P client
is enforcing only a single channel to be used (e.g., to avoid
multi-channel concurrent operations).
The P2P group component is now tracking of associated stations
in the group and the Group Limit bit in the Group Capabilities
is updated based on whether there is room for new clients in
the group.
This driver capability limit was supposed to indicate limit on
how many stations can associate with us in the AP mode, not how
many P2P peers are stored in the peer table.
The workaround to ignore no ctrl::ack received for GO Negotiation
Confirmation frame was only supposed to be used when the frame was
actually transmitted and just the ack was not received. However, due
to the way the driver failure on transmitting the frame were reported,
this ended up getting applied for all failures in sending the GO
Negotiation Confirmation frame.
Improve this by providing a mechanism to indicate whether send_action
operations fail locally before the frame was actually transmitted or
because of not receiving ack frame after having transmitted the frame.
This is needed to work around cases where the pending interface gets
removed, e.g., due to failed GO Negotiation. In such case, we may still
accept new GO Negotiation to be completed, but the interface did not
get created without a separate p2p_connect command.
The current implementation is not ideal since the re-created interface
may, at least in theory, get incorrect interface addrees. Though, this
would likely require that the driver supported more than one P2P group
interface and that the previous one was already taken into use for
another group.
UPnP event subscriptions are not supposed to be dropped based on
whether events can be delivered quickly enough. Leave dropping to
happen only based on failed deliveries to avoid issues with a burst
of events kicking out still active subscribers.
Do not send more than five Probe Request WLANEvent notifications
per second. Even though the limit should in theory apply to all
WLANEvents, it is better not to drop EAP notifications because
of Probe Request frames and really, the only real reason for
event bursts is Probe Request frames.
Instead of queuing all events for a subscriber, only queue more
important events if delivery of event notifications starts failing.
This allows more time for the subscriber to recover since the maximum
queue length if not reached because of Probe Request frames only.
