PATCH: inform upper over layers which peer has accepted config

[Jouni Malinen]

On Tue, Aug 02, 2022 at 03:16:08PM +0200, Eliot Lear wrote:
> This patch might require some discussion and some edits.  It is possible that two or more
> devices might get configured at the same time.  In this case, the upper layers may wish > to the status of respective devices.  I have tested the dpp_tcp.c code.  I have NOT
> unit tested the dpp_supplicant code (I don't have a test setup for that).

This way of identifying a peer is problematic since there is no separate
bootstrapping information entry for a peer when acting as a DPP
Responder (well, ignoring the mutual authentication case here) since no
QR Code (etc.) was actually read on the Responder device. As such, the
upper layers would not really have any context for determining what the
particular peer bootstrapping information identifier might be in such
cases. Furthermore, this is problematic for the particular
implementation:

> diff --git a/src/common/dpp_tcp.c b/src/common/dpp_tcp.c
> @@ -248,7 +248,8 @@ static void dpp_controller_gas_done(struct dpp_connection *conn)
>                 return;
>         }
> -       wpa_msg(conn->msg_ctx, MSG_INFO, DPP_EVENT_CONF_SENT "conf_status=%d",
> +       wpa_msg(conn->msg_ctx, MSG_INFO, DPP_EVENT_CONF_SENT "peer=%d conf_status=%d",
> +               auth->peer_bi->id,
>                 auth->conf_resp_status);

That auth->peer_bi would be NULL in the case I describe above and this
would crash due to dereferencing a NULL pointer.. This could obviously
be avoided, but it would still be unclear how exactly the Configurator
as the Responder cases should be identified to upper layers.

-- 
Jouni Malinen                                            PGP id EFC895FA