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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
