TCP reset behavior

List overview All Threads
Download

newer

older

Best practises for websocket...

Setting the probing state failed

R, Rajkumar (Raj)

6 Jun 2019 6 Jun '19

4:53 p.m.

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

Attachments:

attachment.html (text/html — 4.3 KB)

Show replies by date

Daniel-Constantin Mierla

7 Jun 7 Jun

12:44 p.m.

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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

R, Rajkumar (Raj)

5:13 p.m.

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@gmail.com Sent: Friday, June 7, 2019 6:14 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; R, Rajkumar (Raj) 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,

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:

thanks, raj

_______________________________________________

Kamailio (SER) - Users Mailing List

sr-users@lists.kamailio.orgmailto: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.comhttps://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/micondahttps://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/micondahttps://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=

R, Rajkumar (Raj)

11 Jun 11 Jun

5:56 a.m.

Did the shared tcp stats help? Awaiting your inputs on this.

thanks, raj

From: sr-users sr-users-bounces@lists.kamailio.org On Behalf Of R, Rajkumar (Raj) Sent: Friday, June 7, 2019 10:44 PM To: miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] TCP reset behavior

Hi Daniel,

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:

thanks, raj

From: Daniel-Constantin Mierla <miconda@gmail.commailto:miconda@gmail.com> Sent: Friday, June 7, 2019 6:14 PM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org>; R, Rajkumar (Raj) <rajkumaradass@avaya.commailto: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,

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:

thanks, raj

_______________________________________________

Kamailio (SER) - Users Mailing List

sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org

Daniel-Constantin Mierla

10:17 a.m.

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@lists.kamailio.org *On Behalf Of *R, Rajkumar (Raj) *Sent:* Friday, June 7, 2019 10:44 PM *To:* miconda@gmail.com; Kamailio (SER) - Users Mailing List 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@gmail.com mailto:miconda@gmail.com> *Sent:* Friday, June 7, 2019 6:14 PM *To:* Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>; R, Rajkumar (Raj) <rajkumaradass@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@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 www.twitter.com/miconda -- www.linkedin.com/in/miconda

Daniel-Constantin Mierla

12 Jun 12 Jun

6:58 a.m.

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@lists.kamailio.org *On Behalf Of *R, Rajkumar (Raj) *Sent:* Friday, June 7, 2019 10:44 PM *To:* miconda@gmail.com; Kamailio (SER) - Users Mailing List 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@gmail.com mailto:miconda@gmail.com> *Sent:* Friday, June 7, 2019 6:14 PM *To:* Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org>; R, Rajkumar (Raj) <rajkumaradass@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@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 www.twitter.com/miconda -- www.linkedin.com/in/miconda

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

R, Rajkumar (Raj)

7:57 a.m.

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@gmail.com Sent: Wednesday, June 12, 2019 12:29 PM To: R, Rajkumar (Raj) rajkumaradass@avaya.com; Kamailio (SER) - Users Mailing List 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@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@gmail.commailto:miconda@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org Subject: Re: [SR-Users] TCP reset behavior

Hi Daniel,

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:

thanks, raj

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,

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:

thanks, raj

_______________________________________________

Kamailio (SER) - Users Mailing List

sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org

Daniel-Constantin Mierla -- www.asipto.comhttps://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/micondahttps://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/micondahttps://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.comhttps://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/micondahttps://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/micondahttps://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

8:05 a.m.

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@gmail.com *Sent:* Wednesday, June 12, 2019 12:29 PM *To:* R, Rajkumar (Raj) rajkumaradass@avaya.com; Kamailio (SER) - Users Mailing List 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@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@gmail.com <mailto:miconda@gmail.com>; Kamailio
    (SER) - Users Mailing List <sr-users@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@gmail.com
    <mailto:miconda@gmail.com>>
    *Sent:* Friday, June 7, 2019 6:14 PM
    *To:* Kamailio (SER) - Users Mailing List
    <sr-users@lists.kamailio.org
    <mailto:sr-users@lists.kamailio.org>>; R, Rajkumar (Raj)
    <rajkumaradass@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@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 www.twitter.com/miconda -- www.linkedin.com/in/miconda

R, Rajkumar (Raj)

11:20 a.m.

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@gmail.com Sent: Wednesday, June 12, 2019 1:36 PM To: R, Rajkumar (Raj) rajkumaradass@avaya.com; Kamailio (SER) - Users Mailing List sr-users@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.

thanks, raj +918067153382

From: Daniel-Constantin Mierla miconda@gmail.com mailto:miconda@gmail.com Sent: Wednesday, June 12, 2019 12:29 PM To: R, Rajkumar (Raj) rajkumaradass@avaya.com mailto:rajkumaradass@avaya.com; Kamailio (SER) - Users Mailing List sr-users@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

Hi Daniel,

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:

thanks, raj

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,

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:

thanks, raj

_______________________________________________

Kamailio (SER) - Users Mailing List

sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org

Daniel-Constantin Mierla -- www.asipto.comhttps://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/micondahttps://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/micondahttps://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.comhttps://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/micondahttps://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/micondahttps://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.comhttps://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/micondahttps://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/micondahttps://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

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

2087

Age (days ago)

2093

Last active (days ago)

sr-users@lists.kamailio.org

9 comments

2 participants

tags (0)

participants (2)

Daniel-Constantin Mierla
R, Rajkumar (Raj)