[PATCH 3/3] DPP: prevent processing dpp action frames when stopped

[Jouni Malinen]

On Mon, Feb 08, 2021 at 03:32:07PM +0000, Michal Kazior wrote:
> DPP configurator params can be configured per
> interface. DPP listening can also be started and
> stopped per interface.
> 
> However DPP rx processing was always doomed to
> process incomming frames even on interfaces which
> were not explicitly started to do DPP listen. This
> happened because not only the initial value but
> also because the dpp_allowed_roles could never be
> reset to 0.

This is not really the way the DPP_LISTEN was designed for hostapd
originally. The expectation was the AP side does not need an explicit
DPP_LISTEN command to receive DPP frames on the operating channel, i.e.,
DPP_LISTEN would only be needed to do an off-channel listen operation.
Only later extensions to being able to configure parameters and HW RX
filters brought in cases where the DPP_LISTEN command might be needed.

> This would result in random failures in
> configuring Enrollees when running multiple AP
> interfaces if some of these APs happened to not
> have DPP configurator params set.

Can you please provide more details on where you are seeing issues from
this? The Responder should ignore the incoming DPP messages if they are
not targeting it (have a match in the bootstrapping key).

> diff --git a/src/ap/dpp_hostapd.c b/src/ap/dpp_hostapd.c

>  void hostapd_dpp_listen_stop(struct hostapd_data *hapd)
>  {
> +	hapd->dpp_allowed_roles = 0;

This might be a reasonable thing to do on an explicit DPP_LISTEN_STOP
operation.

>  int hostapd_dpp_init(struct hostapd_data *hapd)
>  {
> -	hapd->dpp_allowed_roles = DPP_CAPAB_CONFIGURATOR | DPP_CAPAB_ENROLLEE;
> +	hapd->dpp_allowed_roles = 0;

But this is the part that I'm a bit worried about since it changes the
past expectation of not requiring an explicit DPP_LISTEN command in some
cases.
 
-- 
Jouni Malinen                                            PGP id EFC895FA