[06/21] dpp: fix retransmits if on operating channel

Commit Message

James Prestwood Oct. 12, 2023, 8:01 p.m. UTC

DPP configurators are running the majority of the protocol on the
current operating channel, meaning no ROC work. The retry logic
was bailing out if !dpp->roc_started with the assumption that DPP
was in between requesting offchannel work and it actually starting.
For configurators, this may not be the case. The offchannel ID also
needs to be checked, and if no work is scheduled we can send the
frame.
---
 src/dpp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Denis Kenzior Oct. 17, 2023, 3:36 p.m. UTC | #1

Hi James,

On 10/12/23 15:01, James Prestwood wrote:
> DPP configurators are running the majority of the protocol on the
> current operating channel, meaning no ROC work. The retry logic
> was bailing out if !dpp->roc_started with the assumption that DPP
> was in between requesting offchannel work and it actually starting.
> For configurators, this may not be the case. The offchannel ID also
> needs to be checked, and if no work is scheduled we can send the
> frame.
> ---
>   src/dpp.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied, thanks.

Regards,
-Denis

Patch

diff --git a/src/dpp.c b/src/dpp.c
index a5bc2e0a..52adda9a 100644
--- a/src/dpp.c
+++ b/src/dpp.c
@@ -2186,7 +2186,7 @@  static void dpp_frame_timeout(struct l_timeout *timeout, void *user_data)
 	 * send. Just bail out now and the roc_started callback will take care
 	 * of sending this out.
 	 */
-	if (!dpp->roc_started)
+	if (dpp->offchannel_id && !dpp->roc_started)
 		return;
 
 	dpp_frame_retry(dpp);