28 Apr
2020
28 Apr
'20
2:30 p.m.
#### Pre-Submission Checklist
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [x] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
If kamailio is behind a NAT only return connection if port matches. We observed this issue
on an instance after ~10h of operation.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2307
-- Commit Summary --
* core: do not return connection if port does not match
-- File Changes --
M src/core/tcp_main.c (11)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2307.patch
https://github.com/kamailio/kamailio/pull/2307.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2307
28 Apr
28 Apr
3:43 p.m.
That part of code gets the connection by its ID, which is unique, and matching address or
port should no longer be considered.
Can you give an example where you got issues with the existing behaviour?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2307#issuecomment-620616552
5 May
5 May
4:32 p.m.
When an INVITE comes in, we instruct Kamailio to query a http service to know which
clients should receive the INVITE message. If multiple of these
"receiver"-clients are running on the same machine (same IP address, but
different source port), we see that Kamailio forwards multiple INVITE to one single client
(although the clients are listening on different ports!). The problem happens (strangely)
only when we run Kamailio in AWS (Fargate) behind a load balancer, we have not observed
the issue by using vanilla docker containers.
I am not 100% sure the code in this PR is indeed fixing the issue at the right place but
with the patch above everything works fine.
The above estimation of ~10h is an estimation error on our side, the issue is always
reproducible.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2307#issuecomment-624091095
4:44 p.m.
What global parameters did you set for kamailio?
If the issue is reproducible, can you list the tcp connections with:
```
kamctl rpc core.tcp_list
```
and see if what is listed there matches the connection expected to be used?
Also, I understand this happens when forwarding requests, not for routing back replies?
Given that tcp connection id is unique, it would mean that the connection is not found if
the search matches on id but not on port, so a new connection is created?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2307#issuecomment-624098104
5:39 p.m.
among others, we have:
enable_tls=yes
tcp_accept_haproxy=yes
tcp_connection_match=1
tcp_accept_unique=0
The issue only happens when forwarding requests. Running `kamctl` in AWS Fargate is not a
straightforward task but I will give it a try.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2307#issuecomment-624130872
7 May
7 May
1:29 p.m.
I am not having access to AWS Fargate, so testing is not going to be easy.
If you say it helps, we can extend the use `tcp_connection_match` to have different layers
of matching, but considering its value as flags.
So `tcp_connection_match=1` does like now (which is the first flag `1<<0`), then for
matching the port along with connection id, the 2nd flag `1<<1` has to be set,
`tcp_connection_match=3`.
The idea is to be able to set the behaviour via parameters, so what fixes in this case is
not breaking for others not using same infrastructure.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2307#issuecomment-625197640
25 May
25 May
1:57 p.m.
We have run some additional tests over the last weeks with the latest version from master
and fortunately (or unfortunately?) we are not able to reproduce the issue anymore. I
would propose to skip this fix for the moment. Thanks anyhow for the support!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2307#issuecomment-633536311
5 Jun
5 Jun
10:12 a.m.
Closed #2307.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2307#event-3410195280
1434
days inactive
1472
days old
7 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Donato Sciarra