Kamailio just sets the keepalive options to the socket, sending and
handling of the response (or lack of) is done at OS/kernel layer.
Kamailio is notified if the connection changes the state.

Check the sysctl values for tcp keepalive and try to change them there
to see if if makes any difference.

Cheers,
Daniel

On 12.06.19 13:20, R, Rajkumar (Raj) wrote:
>
> The scenario here is the other end’s RESET/connection closure will
> never reach Kamailio, as the client has lost it’s network connectivity.
>
> In such case expected Kamailio to reset the TCP connection after
> 120seconds  based on the TCP keepalive  config params mentioned
> earlier. From wireshark capture observe, Kamailio  keeps resending TCP
> keepalive packets at varying intervals for varying duration
> length(like 6mins, 14mins..)  before resetting the TCP connections.
>
>  
>
> thanks,
>
> raj
>
>  
>
> *From:*Daniel-Constantin Mierla <[email protected]>
> *Sent:* Wednesday, June 12, 2019 1:36 PM
> *To:* R, Rajkumar (Raj) <[email protected]>; Kamailio (SER) -
> Users Mailing List <[email protected]>
> *Subject:* Re: [SR-Users] TCP reset behavior
>
>  
>
> If it is established, then the other side didn't actually requested
> the close of the connection. It should be in close-wait state when the
> remote peer sent the close request.
>
> Look at the traffic of the connection with wireshare, it shows also
> the tcp control packets.
>
> On 12.06.19 09:57, R, Rajkumar (Raj) wrote:
>
>     It remained in ‘ESTABLISHED’ state only. Please find netstat
>     output below.
>
>      
>
>     # netstat -natlp
>
>     Active Internet connections (servers and established)
>
>     Proto Recv-Q Send-Q Local Address           Foreign
>     Address         State       PID/Program name
>
>     tcp        0      0 0.0.0.0:5060           
>     0.0.0.0:*               LISTEN      20/kamailio
>
>     tcp        0      0 0.0.0.0:80             
>     0.0.0.0:*               LISTEN      -
>
>     tcp        0      0 0.0.0.0:411            
>     0.0.0.0:*               LISTEN      -
>
>     tcp        0      0 0.0.0.0:8443           
>     0.0.0.0:*               LISTEN      -
>
>     tcp        0      0 0.0.0.0:5056           
>     0.0.0.0:*               LISTEN      20/kamailio
>
>     tcp        0   3777 10.1.4.55:5060         
>     10.27.117.55:38115      ESTABLISHED 20/Kamailio
>
>      
>
>      
>
>      
>
>     thanks,
>
>     raj
>
>     +918067153382
>
>      
>
>     *From:*Daniel-Constantin Mierla <[email protected]>
>     <mailto:[email protected]>
>     *Sent:* Wednesday, June 12, 2019 12:29 PM
>     *To:* R, Rajkumar (Raj) <[email protected]>
>     <mailto:[email protected]>; Kamailio (SER) - Users Mailing
>     List <[email protected]>
>     <mailto:[email protected]>
>     *Subject:* Re: [SR-Users] TCP reset behavior
>
>      
>
>     Hello,
>
>     the connection state is OK in all outputs, so not seen as closed
>     by Kamailio.
>
>     Can you get the output of the netstat for that connection after is
>     supposed to be closed to see its state there?
>
>     Cheers,
>     Daniel
>
>     On 11.06.19 12:17, Daniel-Constantin Mierla wrote:
>
>         Hello,
>
>         I didn't get the time to look at. It was a long weekend in
>         Germany, with Monday being public holiday. Not sure if I get
>         to it today, but hope to get time in the next few days.
>
>         Cheers,
>         Daniel
>
>         On 11.06.19 07:56, R, Rajkumar (Raj) wrote:
>
>             Did the shared tcp stats help?  Awaiting your inputs on this.
>
>              
>
>             thanks,
>
>             raj
>
>              
>
>              
>
>             *From:*sr-users <[email protected]>
>             <mailto:[email protected]> *On Behalf Of
>             *R, Rajkumar (Raj)
>             *Sent:* Friday, June 7, 2019 10:44 PM
>             *To:* [email protected] <mailto:[email protected]>;
>             Kamailio (SER) - Users Mailing List
>             <[email protected]>
>             <mailto:[email protected]>
>             *Subject:* Re: [SR-Users] TCP reset behavior
>
>              
>
>             Hi Daniel,
>
>              
>
>             Please find attached stats output captured every 2 seconds
>             for the entire duration of test (i.e., Start of
>             registration from client till the connection towards
>             client is reset by kamailio after 17mins approximately). I
>             had used ‘kamcmd’ instead of ‘kamctl’ for same command
>             arguments.
>
>              
>
>             Setup:
>
>              
>
>             10.27.117.55 (Client) --- Kamailio (10.1.4.55) ----
>             Backend server (10.2.8.70)
>
>              
>
>             Summary of events executed/observed during the test:
>
>              
>
>               * Once the client is registered successfully to the
>                 backend, turned off WiFi connection at the client side
>                 (time 13:07.05 UTC 2019).
>               * After OPTIONS msg time out for response from the
>                 client, backend closes the TCP connection towards
>                 kamailio ( around time 13:10:39),
>               * TCP connection towards client side is reset at
>                 13:24:30 (i.e., 17 minutes since the WiFi is turned off)
>               * In wireshark, see re-transmission of a TCP packet from
>                 kamailio for about 15 minutes until connection release.
>
>              
>
>              
>
>              
>
>             thanks,
>
>             raj
>
>              
>
>             *From:*Daniel-Constantin Mierla <[email protected]
>             <mailto:[email protected]>>
>             *Sent:* Friday, June 7, 2019 6:14 PM
>             *To:* Kamailio (SER) - Users Mailing List
>             <[email protected]
>             <mailto:[email protected]>>; R, Rajkumar (Raj)
>             <[email protected] <mailto:[email protected]>>
>             *Subject:* Re: [SR-Users] TCP reset behavior
>
>              
>
>             Hello,
>
>             can you reproduce the case and then get the output of the
>             next commands:
>
>             kamctl rpc core.tcp_list
>
>             kamctl rpc core.tcp_options
>
>             kamctl rpc core.tcp_info
>
>             Cheers,
>             Daniel
>
>             On 06.06.19 18:53, R, Rajkumar (Raj) wrote:
>
>                 Hi All,
>
>                  
>
>                 In our setup running kamailio (alpine image) in
>                 stateless mode and have following TCP config set.
>                 After client registers to the backend see two TCP
>                 connections created – one towards the client and the
>                 other towards the backendserver.  If there’s a abrupt
>                 network disconnect either at the client side or at the
>                 backend side, do not see TCP reset happening from
>                 kamailio as per the config. Per below config expected
>                 after 120seconds( = [tcp_keepidle] + ( [tcp_keepintvl
>                 * tcp_keepcnt] ) instead it keeps resending TCP
>                 keepalive packets at varying intervals for varying
>                 duration length(like 6mins, 14mins..)  before
>                 resetting the TCP connections.  Also want to mention
>                 that we are not using TCPOPS module here.
>
>                  
>
>                 I am trying to achieve consistent duration for TCP
>                 reset in kamailio. Could you please point me if I have
>                 missed anything here?
>
>                  
>
>                 */Setup:/*
>
>                  
>
>                 Client ---- Kamailio (stateless mode) ---- Backend
>                 server  
>
>                  
>
>                  
>
>                 *TCP Config:*
>
>                 * *
>
>                 *tcp_connection_lifetime = 3600*
>
>                 tcp_accept_aliases = no
>
>                 tcp_async = yes
>
>                 tcp_connect_timeout = 10
>
>                 tcp_crlf_ping = yes
>
>                 *tcp_keepalive = yes*
>
>                 *tcp_keepcnt = 3*
>
>                 *tcp_keepidle = 30*
>
>                 *tcp_keepintvl = 30           # Total 2 mins -
>                 30+(30*3)=120 sec*
>
>                 tcp_linger2 = 30
>
>                 tcp_rd_buf_size = 65536
>
>                 tcp_send_timeout = 10
>
>                  
>
>                 thanks,
>
>                 raj
>
>                  
>
>                  
>
>                 _______________________________________________
>
>                 Kamailio (SER) - Users Mailing List
>
>                 [email protected] 
> <mailto:[email protected]>
>
>                 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.kamailio.org_cgi-2Dbin_mailman_listinfo_sr-2Dusers&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=m1fGDJFl23Vq-awSnjgML3TymzSQRBOSTCALAsyAHNM&s=lQLR6IfVOO2CWDL4iEDldpjFjZfxQFyfKeFd1pGZkoY&e=>
>
>             -- 
>
>             Daniel-Constantin Mierla -- www.asipto.com 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.asipto.com&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=m1fGDJFl23Vq-awSnjgML3TymzSQRBOSTCALAsyAHNM&s=2-7juQBEXrjA_PjfpiIZ0JvAZxWKngyC0vcVyP1GmUs&e=>
>
>             www.twitter.com/miconda 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_miconda&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=m1fGDJFl23Vq-awSnjgML3TymzSQRBOSTCALAsyAHNM&s=_qINzlBw2yRKQ3ke2UwXsjTQ7lKWI25XpjOlzw9gPqA&e=>
>  -- www.linkedin.com/in/miconda 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_miconda&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=m1fGDJFl23Vq-awSnjgML3TymzSQRBOSTCALAsyAHNM&s=TsFAXfvNfu1k1Kw-F4937svidQSEfPMgK4VmorRPn54&e=>
>
>         -- 
>
>         Daniel-Constantin Mierla -- www.asipto.com 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.asipto.com&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=OCP_rR5_9SQpkMRB1w_kOQYN3ooVOlU65du-BxCLfdM&s=UMaxn1Owy1eHi2eAw29Y1v44igz-iYzUksNhxkR7em8&e=>
>
>         www.twitter.com/miconda 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_miconda&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=OCP_rR5_9SQpkMRB1w_kOQYN3ooVOlU65du-BxCLfdM&s=nLdsS8oJ8kD-DcfH79nsBCyj95290vEG4AifFckLDcM&e=>
>  -- www.linkedin.com/in/miconda 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_miconda&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=OCP_rR5_9SQpkMRB1w_kOQYN3ooVOlU65du-BxCLfdM&s=lb0Xu4UZ9vgK9ovbzSApy8zFMVF67L6Hh2-rHcEGtt0&e=>
>
>     -- 
>
>     Daniel-Constantin Mierla -- www.asipto.com 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.asipto.com&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=OCP_rR5_9SQpkMRB1w_kOQYN3ooVOlU65du-BxCLfdM&s=UMaxn1Owy1eHi2eAw29Y1v44igz-iYzUksNhxkR7em8&e=>
>
>     www.twitter.com/miconda 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_miconda&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=OCP_rR5_9SQpkMRB1w_kOQYN3ooVOlU65du-BxCLfdM&s=nLdsS8oJ8kD-DcfH79nsBCyj95290vEG4AifFckLDcM&e=>
>  -- www.linkedin.com/in/miconda 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_miconda&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=OCP_rR5_9SQpkMRB1w_kOQYN3ooVOlU65du-BxCLfdM&s=lb0Xu4UZ9vgK9ovbzSApy8zFMVF67L6Hh2-rHcEGtt0&e=>
>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.asipto.com&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=4Ir7EzpigornPG5nIqPd6gt8_t8XTDJYOUR2UmwPjdk&s=i6DE7_KD6kIHLqHWtqMJQ6uNlWBkQyizhdR1Q8_vrTk&e=>
> www.twitter.com/miconda 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_miconda&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=4Ir7EzpigornPG5nIqPd6gt8_t8XTDJYOUR2UmwPjdk&s=TL4A8Sp38pb4_DQjx_0ojc8-TMKtaMO9ujATPs2Hfik&e=>
>  -- www.linkedin.com/in/miconda 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_miconda&d=DwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=LDE-f1bLxMPmcrsp8ONITcznNqEIlhe9ffKEZPeB7EI&m=4Ir7EzpigornPG5nIqPd6gt8_t8XTDJYOUR2UmwPjdk&s=0XaBVrYfnAMsdKSTrTizX2MzPJJiIpLCGQRENRMqm2M&e=>

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda

_______________________________________________
Kamailio (SER) - Users Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to