[HELP] TCP IP KeepAlive config parameters are not applied correctly on Nuttx 12.6 STM32H7

[EduardNiesner]

Description

We are using Nuttx 12.6 and STM32H743II MCU for our application and we are trying to configure the KeepAlive feature.
We configured TCP_KEEPIDLE=3000 ms, TCP_KEEPINTVL=5000ms and the parameters seems to not take efect, to validate the keep alive feature, we monitored the network using WireShark and the keep alive probes are not sent at the configured interval.
We added some printf statements in the nuttx/net/tcp/tcp_timer.c at near line 700 to check what are the conn->keeptimer and hsec values at runtime. The following observations are made: conn->keeptimer=72000 and hsec=3. The conn->keeptimer value is set by default in the nuttx/net/tcp/tcp_conn.c at line 788, and it cannot be changed by a call to setsockopt.

Is there any other way to change the values? Any help is appreciated!

Verification

• I have verified before submitting the report.

[acassis]

@wengzhe could you please help on this?

[wengzhe]

I'm not sure which commit you're on, so I checked out nuttx-12.6.0-RC1 to do a test with the example in apps/examples/netloop/lo_main.c with TCP_KEEPIDLE=3s and TCP_KEEPINTVL=5s on sim, and got conn->keeptimer finally updated to 30 after setsockopt. Though I don't have an STM32 board, I think this behavior shouldn't differ between the sim and the actual board.

But there did be a problem here, I found the TCP_KEEPIDLE and TCP_KEEPINTVL options are setting time as dsec into conn->keep* (e.g. 3s->30, code), but conn->keeptimer is used as hsec later(30->15s, code). It seems that we've mixed dsec and hsec since d8b97d7 and maybe we need to fix it later.

[vladsomai]

Hello Weng,

It looks like we used the SOL_SOCKET when calling setsockopt and that made the call to be ignored when setting the keep alive options. The examples helped us fix the issue where the timer was stuck to 72000, thank you!

We are subscribed to this issue so please post here when you come with a fix. We would like to pull the changes into our code.

Regards,
Vlad

[wengzhe]

We are subscribed to this issue so please post here when you come with a fix. We would like to pull the changes into our code.

Hi @vladsomai , we've made a fix here #13589, would you have a try?

[acassis]

@wengzhe @zs39 it is important to give a quick explanation in the commit log message, I saw the issue was just the timeout value was 5x big (need to be divided by DSEC_PER_HSEC), but it is important to use the commit message to explain and to let it be used as a guidance for someone looking this PR in the future.