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> *On Behalf Of
*R, Rajkumar (Raj)
*Sent:* Friday, June 7, 2019 10:44 PM
*To:* miconda(a)gmail.com; Kamailio (SER) - Users Mailing List
<sr-users(a)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=>