[SR-Users] TCP reset behavior

R, Rajkumar (Raj) rajkumaradass at avaya.com
Wed Jun 12 13:20:12 CEST 2019


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 <miconda at gmail.com>
Sent: Wednesday, June 12, 2019 1:36 PM
To: R, Rajkumar (Raj) <rajkumaradass at avaya.com>; Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
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 <miconda at gmail.com><mailto:miconda at gmail.com>
Sent: Wednesday, June 12, 2019 12:29 PM
To: R, Rajkumar (Raj) <rajkumaradass at avaya.com><mailto:rajkumaradass at avaya.com>; Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org><mailto:sr-users at lists.kamailio.org>
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 <sr-users-bounces at lists.kamailio.org><mailto:sr-users-bounces at lists.kamailio.org> On Behalf Of R, Rajkumar (Raj)
Sent: Friday, June 7, 2019 10:44 PM
To: miconda at gmail.com<mailto:miconda at gmail.com>; Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org><mailto:sr-users at lists.kamailio.org>
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 <miconda at gmail.com<mailto:miconda at gmail.com>>
Sent: Friday, June 7, 2019 6:14 PM
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>>; R, Rajkumar (Raj) <rajkumaradass at avaya.com<mailto:rajkumaradass at avaya.com>>
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

sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>

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=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190612/c0f1d842/attachment.html>


More information about the sr-users mailing list