PATCH: Don't close DPP TCP connection for duplicate Presence Announcements

[Eliot Lear]

Hi Jan,

Thanks for the mail.  It's possible I am missing something. Below is my 
logic.

On 23.06.22 17:00, Jan Ceuleers wrote:
>
> Without having read the code you are modifying (beyond the above patch,
> that is), I would just like to point out that the return value is
> different: it was -1 in the hunk that is being removed, and it is 0 in
> the added-one. Just checking that this is intentional.

Yes, this is intentional.  The -1 is what closes the connection, and 0 
keeps it open.

This is in dpp_controller_rx_presence_announcement(), which is the 
return value from dpp_controller_rx_action(), which is called below in 
dpp_controller_rx():

	case WLAN_PA_VENDOR_SPECIFIC:
                 if (dpp_controller_rx_action(conn, pos + 1,
                                              wpabuf_len(conn->msg) - 1) < 0)
                         dpp_connection_remove(conn);
	        break;

So a -1 value leads to dpp_connection_remove(), which in turn blows away 
the state that we need.

Eliot


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x87B66B46D9D27A33.asc
Type: application/pgp-keys
Size: 5052 bytes
Desc: OpenPGP public key
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20220623/fbaf251c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/hostap/attachments/20220623/fbaf251c/attachment.sig>