12 Jun
2019
12 Jun
'19
3:53 p.m.
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 <miconda(a)gmail.com>
*Sent:* Wednesday, June 12, 2019 1:36 PM
*To:* R, Rajkumar (Raj) <rajkumaradass(a)avaya.com>om>; Kamailio (SER) -
Users Mailing List <sr-users(a)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(a)gmail.com>
<mailto:miconda@gmail.com>
*Sent:* Wednesday, June 12, 2019 12:29 PM
*To:* R, Rajkumar (Raj) <rajkumaradass(a)avaya.com>
<mailto:rajkumaradass@avaya.com>; Kamailio (SER) - Users Mailing
List <sr-users(a)lists.kamailio.org>
<mailto:sr-users@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(a)lists.kamailio.org>
<mailto:sr-users-bounces@lists.kamailio.org> *On Behalf Of
*R, Rajkumar (Raj)
*Sent:* Friday, June 7, 2019 10:44 PM
*To:* miconda(a)gmail.com <mailto:miconda@gmail.com>;
Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org>
<mailto:sr-users@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(a)gmail.com
<mailto:miconda@gmail.com>>
*Sent:* Friday, June 7, 2019 6:14 PM
*To:* Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>; R, Rajkumar (Raj)
<rajkumaradass(a)avaya.com <mailto:rajkumaradass@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(a)lists.kamailio.org <mailto:sr-users@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=>
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda