25 Nov
2019
25 Nov
'19
3:37 p.m.
- fixed a defect reported from Coverity Scan - Concurrent data access
violations in spi_gen.c for spi_data->spi_val.
- added a new conf param - ipsec_reuse_server_port - reuse or not
PCSCF server port for UA Re-registration.
- added description for the new parameter in ims_ipsec_pcscf_admin.xml.
- in fill_contact() for Request messages set received host, port and
proto fro request uri if alias is presented.
- A new server port is used for Re-registration, depending on the new
parameter ipsec_reuse_server_port.
- in create_ipsec_tunnel() return -1 when unable to convert ip address.
- in ipsec_forward() add supported and require secagree headers only
for Register reply with code 200. Set SND_F_FORCE_SOCKET for
request messages.
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x
...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes
that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines
from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on
sr-dev mailing list -->
- [ ] Commit message has the format required by CONTRIBUTING guide
- [ ] Commits are split per component (core, individual modules, libs, utils, ...)
- [ ] Each component has a single commit (if not, squash them into one commit)
- [ ] 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
- [ ] 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:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that
apply -->
- [ ] PR should be backported to stable branches
- [ ] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2148
-- Commit Summary --
* ims_ipsec_pcscf: fixed warnings, added a new config param
-- File Changes --
M src/modules/ims_ipsec_pcscf/cmd.c (209)
M src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml (22)
M src/modules/ims_ipsec_pcscf/ims_ipsec_pcscf_mod.c (2)
M src/modules/ims_ipsec_pcscf/spi_gen.c (14)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2148.patch
https://github.com/kamailio/kamailio/pull/2148.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/2148
25 Nov
25 Nov
6:40 p.m.
Hello, thanks for the pull request.
Please separate the bugfixes (that needs to be backported) from functional additions next
time. I assume that the bugfix is in spi_gen.c and also one related to the log in int
add_supported_secagree_header(struct sip_msg* m) . After merging I can manually backport.
About the functional change:
* in ipsec_forward() add supported and require secagree headers only for Register reply
with code 200. Set SND_F_FORCE_SOCKET for request messages.
Two questions:
- Was the previous behaviour to apply it for all SIP methods wrong?
- Are there cases where one does not want to force the send socket for the messages?
I am just trying to sort out if the change might break other people configs and some
parameter needs to be added.
I have one general remark related to the locking in the module. It uses directly the
pthread function calls. Usually all modules should use the kamailio locking interface (in
core/locking.h). The simple lock is probably ok for this module. Would be great if you
could convert it to this in one of your next changes. You can look to e.g. to the
ims_usrloc* modules to have a look to the implementation.
--
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/2148#issuecomment-558286133
26 Nov
26 Nov
8:55 a.m.
Hi, thanks for the quick response!
For future pull requests I will strictly separate bug fixes and new
features.
For SND_F_FORCE_SOCKET - I am using ipsec functionality with UDP or TCP.
For TCP I need to force send to existing socket (in combination with
tcp_reuse_port=yes) to pass the Request message through existing ipsec
tunnel. I think that change will not reflect other user, because it's valid
only for PROTO_TCP and PROTO_WS in combination with ipsec_forward() (using
of ipsec tunnels). For ipsec and UDP that is not a problem. I can add an
option (ipsec_force_send_socket or something like this) to be clear when
force socket is used or not.
For Register reply with code 200 - supported and secagree headers are
needed only for that message.
For locking - I could do refactor in some of the next changes.
Cheers!
On Mon, 25 Nov 2019 at 20:40, Henning Westerholt <notifications(a)github.com>
wrote:
Hello, thanks for the pull request.
Please separate the bugfixes (that needs to be backported) from functional
additions next time. I assume that the bugfix is in spi_gen.c and also one
related to the log in int add_supported_secagree_header(struct sip_msg* m)
. After merging I can manually backport.
About the functional change:
- in ipsec_forward() add supported and require secagree headers only
for Register reply with code 200. Set SND_F_FORCE_SOCKET for request
messages.
Two questions:
- Was the previous behaviour to apply it for all SIP methods wrong?
- Are there cases where one does not want to force the send socket for
the messages?
I am just trying to sort out if the change might break other people
configs and some parameter needs to be added.
I have one general remark related to the locking in the module. It uses
directly the pthread function calls. Usually all modules should use the
kamailio locking interface (in core/locking.h). The simple lock is probably
ok for this module. Would be great if you could convert it to this in one
of your next changes. You can look to e.g. to the ims_usrloc* modules to
have a look to the implementation.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/kamailio/kamailio/pull/2148?email_source=notifications&email_token=ALKTZB45LFAJXW6DCGLXXDDQVQLZ7A5CNFSM4JRKYG72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFDMKNI#issuecomment-558286133>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALKTZB2Y2HGQDAYPZRHKXYDQVQLZ7ANCNFSM4JRKYG7Q>
.
--
Best Regards,
Aleksandar Yosifov
--
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/2148#issuecomment-558528872
8:47 p.m.
Thanks for the response as well.
Ok, about the SND_F_FORCE_SOCKET - it would be indeed good to make it configurable. I
assume that it is only used for the forward() function - so you could add an flag
parameter to the function to control this behaviour. Then it could be extended in the
future (as bitmask) if there are other extensions necessary.
Example:
- ipsec_forward("location"); # old behaviour
- ipsec_forward("location", "1"); new behaviour
- ipsec_forward("location", "0"); old 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/2148#issuecomment-558810581
3 Dec
3 Dec
9:59 a.m.
Hi,
Now I am working to split to different pull requests (bug fixes and new functional
changes). After that I am going to close this pull request.
--
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/2148#issuecomment-561091415
5 Dec
5 Dec
3:40 p.m.
- bugfix merged: #2163
- reuse port functional additions pull request: #2164
--
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/2148#issuecomment-562184581
3:41 p.m.
Keep it open for tracking, to be closed after integration of dedicated pull requests later
on.
--
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/2148#issuecomment-562184925
14 Jan
14 Jan
1:55 p.m.
This pull request can be closed. Dedicated pull requests already merged.
Thanks!
--
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/2148#issuecomment-574185292
2:38 p.m.
Closed #2148.
--
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/2148#event-2947307133
1646
days inactive
1696
days old
8 comments
3 participants
participants (3)
-
alexyosifov -
Henning Westerholt
-
Victor Seva