The connection timeout duration configured for WebSocket is not taking effect.

[JamesLebron]

Dear author,

Hello.

Recently, we have observed that the timeout duration for connecting to the WebSocket seems not to align with the expected configuration results. Below are some brief logs.

LOG_DEBUG << "connect websokect -connectionTimeout = " << m_stack_config.connectionTimeout().count()
              << " -retryInterval = " << m_stack_config.retryInterval().count()
              << " -webSocketPingInterval = " << m_ocpp_config.webSocketPingInterval().count();
    m_reconnect_scheduled = false;
    return m_rpc_client->start(connection_url,
                               iface,
                               credentials,
                               m_stack_config.connectionTimeout(),
                               m_stack_config.retryInterval(),
                               m_ocpp_config.webSocketPingInterval());



[ DEBUG ] - [2024-01-12 18:59:42.405] - ChargePoint.cpp:1228 - connect websokect -connectionTimeout = 180000 -retryInterval = 1000 -webSocketPingInterval = 10
[2024/01/12 18:59:42:4690] N: lws_create_context: LWS: 4.3.2-a1c9db4, NET CLI SRV H1 H2 WS ConMon IPv6-absent
[2024/01/12 18:59:42:4723] N: __lws_lc_tag:  ++ [wsi|0|pipe] (1)
[2024/01/12 18:59:42:5365] N: __lws_lc_tag:  ++ [vh|0|default|eth1|eth1|-1] (1)
[2024/01/12 18:59:44:6463] N: __lws_lc_tag:  ++ [wsicli|0|WS/h1/default/192.168.10.10] (1)
[ ERROR ] - [2024-01-12 19:00:04.468] - ChargePoint.cpp:933 - Connection failed with Central System
[ INFO  ] - [2024-01-12 19:00:04.517] - ChargePoint.cpp:942 - Last registration status was accepted, offline actions are allowed7
[2024/01/12 19:00:04:6147] N: __lws_lc_untag:  -- [wsicli|0|WS/h1/default/192.168.10.10] (0) 20.702s
[2024/01/12 19:00:06:5030] N: __lws_lc_tag:  ++ [wsicli|1|WS/h1/default/192.168.10.10] (1)
[2024/01/12 19:00:26:5121] N: __lws_lc_untag:  -- [wsicli|1|WS/h1/default/192.168.10.10] (0) 20.009s
[2024/01/12 19:00:27:6334] N: __lws_lc_tag:  ++ [wsicli|2|WS/h1/default/192.168.10.10] (1)
[2024/01/12 19:00:47:6367] N: __lws_lc_untag:  -- [wsicli|2|WS/h1/default/192.168.10.10] (0) 20.003s
[2024/01/12 19:00:48:7002] N: __lws_lc_tag:  ++ [wsicli|3|WS/h1/default/192.168.10.10] (1)
[2024/01/12 19:01:08:7188] N: __lws_lc_untag:  -- [wsicli|3|WS/h1/default/192.168.10.10] (0) 20.018s
[2024/01/12 19:01:09:8496] N: __lws_lc_tag:  ++ [wsicli|4|WS/h1/default/192.168.10.10] (1)
[2024/01/12 19:01:29:8662] N: __lws_lc_untag:  -- [wsicli|4|WS/h1/default/192.168.10.10] (0) 20.016s
[2024/01/12 19:01:31:0347] N: __lws_lc_tag:  ++ [wsicli|5|WS/h1/default/192.168.10.10] (1)

Additionally, we have consulted the libwebsockets API and found a parameter named connect_timeout_secs. We attempted to replace timeout_secs with connect_timeout_secs. However, after conducting actual tests, we found that the timeout duration still does not meet our expected time.

Could you please provide some guidance?

[c-jimenez]

Hi,

Indeed the "connect_timeout_secs" was the right parameter to handle connection timeout.
I didn't test this parameter with values greater than 20s and it worked well in this case.
I will make a fix in the develop branch today for this.
But for very long timeouts like the one you are setting (180s), you may have to configure your Linux TCP stack : there is a system limit in the numbers of TCP retries.
On my Debian 11 system, its 6 retries: cat /proc/sys/net/ipv4/tcp_syn_retries
This means that you cannot exceed a system wide configured connection timeout value.
Here are the corresponding wireshark traces which shows the 6 retries before failing :

Regards

[c-jimenez]

Fixed in #176