#### 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: - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description As a local IP address for TCP sending operation the Kamailio service is taking the same network_interface/IP_address, which is used by the service for TCP listening.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3925
-- Commit Summary --
* core: local TCP socket is bound on listening address
-- File Changes --
M src/core/tcp_main.c (24)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3925.patch https://github.com/kamailio/kamailio/pull/3925.diff
@sergey-safarov pushed 1 commit.
73a7150bd5efacb2e210d788aa7d68f863de1459 core: local TCP socket is bound on listening address
@sergey-safarov pushed 1 commit.
7a796717a8a0354b0f94ed2f900c6d842dcc8dd9 core: local TCP socket is bound on listening address
Can you explain in more details what is happening now and how it changes with this PR?
Also, I noticed that instead of a reference in an output parameter, now it makes a hard copy:
``` - *from = &si->su; + memcpy(*from, &si->su, sockaddru_len(si->su)); ```
A reference has the size of a pointer, but the commit is copying data of size `sockaddru_len(si->su)`. Is it really correct and what you wanted to do?
This PR is for a use case when Kamailio is listening `dummy` network interface and `tcp_reuse_port` is not used. In this case, a new TCP connection will be sent from an IP address not listened by Kamailio.
But if you enable `tcp_reuse_port=yes` in this case new outbound TCP connection will be from the correct IP address.
This PR allows create a new TCP connection from the IP address listened by the Kamailio. In case when Kamailio listens on "dummy" interface.
@ivanuschak could comment about ``` - *from = &si->su; + memcpy(*from, &si->su, sockaddru_len(si->su)); ```
@miconda regarding this change: ``` - *from = &si->su; + memcpy(*from, &si->su, sockaddru_len(si->su)); ```
At [this line](https://github.com/kamailio/kamailio/pull/3925/files#diff-aee8567648ae9f54ea...) the port is changed for the `*from`, which is the pointer to the object of `union sockaddr_union`. If we don't use a hard copy and just use pointers then the port for `si->su` will be re-written to zero, and then at [this line](https://github.com/kamailio/kamailio/pull/3925/files#diff-aee8567648ae9f54ea...) it will be re-written with new port, which linux kernel has allocated for this sockaddr_union as a result of [this bind invocation](https://github.com/kamailio/kamailio/pull/3925/files#diff-aee8567648ae9f54ea...), but `si->su` is the `sockaddr_union` object for kamailio listening socket. So if we don't use hard copy here then we will replace `sockaddr_union` object for listening socket with the data for another socket.
As for `sockaddru_len` usage - If I'm not wrong this macro reflects the size of `union sockaddr_union` ``` /* len of the sockaddr */ #ifdef HAVE_SOCKADDR_SA_LEN #define sockaddru_len(su) ((su).s.sa_len) #else #define sockaddru_len(su) \ (((su).s.sa_family == AF_INET6) ? sizeof(struct sockaddr_in6) \ : sizeof(struct sockaddr_in)) #endif /* HAVE_SOCKADDR_SA_LEN*/ ``` Please let us know if you suggest to get the size by some other approach.
@ivanuschak - related to:
``` - *from = &si->su; + memcpy(*from, &si->su, sockaddru_len(si->su)); ```
What I wanted to comment about is that the size are different between the pointer to a structure and the structure itself. A pointer is 4 bytes on 32bit CPU and 8 bytes on 64bit CPU. So the `&si->su` is a pointer (address), being 4/8bytes, `*from` is written with 4/8 bytes.
The change makes the `*from` to be written with `sockaddru_len(si->su)` bytes. Is this correct in the way that `*from` has the proper reserved/allocated size? For me it feels incorrect, the `struct sockaddr_in6` is more than 8 bytes:
- https://man7.org/linux/man-pages/man7/ipv6.7.html
@miconda regarding to this change ``` - *from = &si->su; + memcpy(*from, &si->su, sockaddru_len(si->su)); ```
This change is made within the function `find_listening_sock_info`. The function declaration looks as follows: ``` inline static int find_listening_sock_info( int s, union sockaddr_union **from, int type) ``` The `from` param is a pointer to pointer. It's presumed that at the moment when `find_listening_sock_info` is called the memory for `from` param should be already allocated. This function is called in only a single place in the source code - [here](https://github.com/kamailio/kamailio/pull/3925/files#diff-aee8567648ae9f54ea...) - and `*from` pointer refers to the `my_name` variable, which is a variable allocated on the stack. So this `memcpy` function is copying the memory from `si->su` structure object into the `my_name` variable allocated on the stack. I do not see here anything incorrect. However, maybe the passing of the `from` param as a pointer to pointer (`union sockaddr_union **from`) can be changed to passing as a pointer (`union sockaddr_union *from`) - to exclude a confision.
This PR is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
This PR is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
@Vonssgh approved this pull request.
Please fix. I'm not receiving messages
This PR is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #3925.
Reopened #3925.