> Thanks! Is it still work in progress? I noticed pushing commit updates, just
> to know when to consider merging.
Hi @miconda — it is done; I was rebasing to master occasionally.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
@aalba6675 pushed 1 commit.
0aebfb2e9568fdf7fcc2c763180e80e89e330792 tls: fix OpenSSL engine in child
processes
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/kamailio/kamailio/pull/2840/files
@aalba6675 pushed 1 commit.
9f247309eb39bbdb5e726db15cdcaf152ad0f00d tls: fix OpenSSL engine in child
processes
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/kamailio/kamailio/pull/2840/files
tls_init.c calls OPENSSL_init_ssl(); this initializes the
global engine linked-list and this cannot be reset in the child.
To avoid linked-list corruption we manually instantiate
the engine object required for loading private keys instead of
relying on CONF_modules_load_file().
Updates to doc/.
Background:
Our current code running in child:
```C
ENGINE_load_builtin_engines();
OPENSSL_load_builtin_modules();
if (strncmp(tls_engine_settings.engine_config.s, "NONE", 4)) {
err =
### Description
When using HSM keys (via OpenSSL engine) the engine and private keys are loaded
in the child processes since PKCS#11 modules rarely survive `fork()`.
With OpenSSL 1.1.1 and the call to `OPENSSL_init_ssl()` in `tls_init.c` the
engine linked-list is now initialized in the master
Closed #2577.
--
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/issues/2577#event-4075151200___
Kamailio (SER) - Development Mailing List
I think it is due to my misconfiguration.
--
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/issues/2577#issuecomment-739117686___
Kamailio (SER)
### Description
Different behaviour of rtpengine_manage depending on where it is called
1. Response 180 **is not** sent to rtpengine :12221 using only reply_route
1. Response 180 **is sent** to rtpengine :12221 using
`onreply_route[MANAGE_REPLY]`
Scenario 1 - reply_route only
- call
Thanks @miconda ! There is one more string (in error message) that probably
should be changed as well.
```
LM_ERR("t_relay_to_proto2 failed, bad protocol specified <%s>\n", sproto->s);
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
The use in KEMI should be
```
# without host,port
t_relay_to_proto("UDP")
t_relay_to_proto("TCP")
t_relay_to_proto("TLS")
# with host,port
t_relay_to_proto2("UDP", "5.6.7.8", 5060)
t_relay_to_proto("TCP", "5.6.7.8", 5060)
t_relay_to_proto("TLS", "5.6.7.8", 5061)
```
--
You are receiving this
@aalba6675 pushed 1 commit.
93b2c03eca373831d895f392b790b28973c8e30e tm: KEMI expose
t_relay_to_(host, port) functions
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/kamailio/kamailio/pull/2563/files
@aalba6675 pushed 1 commit.
c5b63818f419a54bb9c7936ab2e95852ccf63d6b tm: KEMI expose
t_relay_to_(host, port) functions
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/kamailio/kamailio/pull/2563/files
!-- 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
!-- 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
1. Does your routing script use threading or indirectly via python modules
which use threading?
2. Can you reproduce this if you modify the logic to only initialize the
threading bits after fork i.e. rank>0?
3. Don't initialize logic that uses threading pre fork().
--
You are receiving this
LGTM
--
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/1568#issuecomment-398624475___
Kamailio (SER) - Development Mailing List
Merged #1484.
--
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/1484#event-1563652574___
Kamailio (SER) - Development Mailing List
Thanks will squash and merge.
--
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/1484#issuecomment-379719270___
Kamailio (SER) - Development
1. Yes - HSM private keys are stored in worker local memory and are not
referenced in old structures during SIP connections. We make one reference
during mod_child: we install it into the shmem SSL_CTX structure once (proc_no
== 0) just to check the the private key corresponds to the cert;
Packaging is here:
stretch: https://packages.debian.org/stretch/softhsm2
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks for the comments - I have replaced malloc/free in the mapping utilities
with `pkg_malloc()/pkg_free()`. Re: "I did not fully understand why you need
this here, maybe you can
elaborate a bit on the requirements of the HSM child_init."
Background: For soft keys, we initialize the SSL_CTX
@aalba6675 pushed 1 commit.
c802024 tls: use pkg_* functions
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/kamailio/kamailio/pull/1484/files/956d0f72a970ce7c826e394c9d1431da6f167b36..c802024442fd8c3ec5190382e84430d4dd4260a0
@aalba6675 pushed 1 commit.
064689c tls: add documentation for engine params
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/kamailio/kamailio/pull/1484/files/5d5aae2826db9635d29a5db5be688fc8caf02e5e
The feature set is generally complete now with the last commit. Just leaving
the documentation of the directives TODO
* support for OpenSSL engine and HSM keys for TLS server and client domains
* HSM private keys are stored in worker-local memory - probably this is the
most intrusive change;
@aalba6675 pushed 1 commit.
5d5aae2 tls/tls_server.c: add HSM key support in outbound connections
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/kamailio/kamailio/pull/1484/files/4c5d1e6cb7d55c4f2f7f61cc95ca9c8a66aee059
@aalba6675 pushed 1 commit.
6966c9f proof-of-concept: implement process-local storage for HSM keys
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/kamailio/kamailio/pull/1484/files/b9b3a3247a312f5f406b40b637fbafed8b25
* The current implementation assumes a single global engine, and per profile
private key: via the syntax `private_key: /engine:HSMPRIVATEKEY`. This is an
expedient workaround as the parser treats strings not starting with `/` as
relative PEM files. The magic prefix `/engine:` is meant for the
@aalba6675 pushed 1 commit.
2b90923 revert editor whitespace changes
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/kamailio/kamailio/pull/1484/files/67fe8f07f12660fa61c5602556a4ba5e3fcf3fd7..2b909237ecc525b93f627b36e94c1ed8b743d45f
You will notice that the PR moves HSM private keys loading to child (after
fork()). Some further explanation is in order:
Engines like AWS CloudHSM(SafeNet "gem" and "LunaCA3" engines) are wrappers
around their PKCS 11 implementations. Some of these libraries do not behave
predictably after
Thanks for the comments, I summarize actionable items at the bottom as the
conversation develops. I can push further commits, and do the final squash when
it can be accepted.
1. Preprocessor defines `OPENSSL_NO_ENGINE` - followed nginx and HAProxy where
they use this to omit compile-time code
Documentation updates will followed after feedback on this PR.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
- add support for OpenSSL engine and loading private keys from HSM
- for when kamailio is a TLS edge proxy and needs to use HSM
- currently we initialize the engine in worker processes as PKCS#11
libraries are not guaranteed to be fork() safe
- new config params
- engine: name the OpenSSL
Yes - I think that is a good idea.
--
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/1475#issuecomment-371460960___
Kamailio (SER) -
Pre-Submission Checklist
- [ ] 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
In a pure KEMI script environment, printing `onsend_rt.rlist` gives
```
Breakpoint 5, run_onsend (orig_msg=0x7f622816c8b0, dst=0x7ffe78d13560,
buf=0x7f622816fcf8 "ACK
sip:conf-095ed1b8-a768-4af4-8ba8-a56bc139574c@10.13.20.20:5090;transport=udp
SIP/2.0\r\nVia: SIP/2.0/UDP
### Description
KEMI onsend_route is not called unless there is a placeholder/dummy routing
block.
```
## without this block, core will never call KEMI->onsend_route
onsend_route {
## do nothing
}
```
### Troubleshooting
Reproduction
1. In KEMI create ksr_onsend_route(). Observe that this
Pre-Submission Checklist
- [ ] 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
Yes, indeed - thanks for fixing it so fast. Much appreciated.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The following attempted workaround also fails:
1. don't use DTLS=off, force transport
rtpengine_manage("ICE=remove transport-protocol=RTP/SAVP");
2. rtpengine side use dtls-passive
rtpengine --dtls-passive
For some reason this also doesn't work, as rtpengine after rewritng SDP adds
@rfuchs hoping you can take a look at this. The merge to master and backport
to 5.1.2 has broken my use of rtpengine_manage("DTLS=off") since the DTLS key
is removed from the ng-protocol messaged and not processed by rtpengine.
It is needed specifically for FreeSWITCH in SDES (who for some
@rfuchs this commit has broken my use of `rtpengine_manage(DTLS=off)`. Now the
key DTLS is not passed to rtpengine but hijacked to set transport.
Without DTLS=off rtpengine adds two lines to SDP
a=setup:actpass
a=fingerprint:xxx
This seems harmless, but FreeSWITCH
### Description
rtpengine module is hijacking the DTLS key
rtpengine_manage("DTLS=off")
DTLS=off is a valid command to rtpengine, but the module uses that flag
to set transport as UDP/TLS/RTP/SAVP
Unfortunately even though the transport can be fixed by RTP/SAVP, the lines
outputted by
This should probably go into `/usr/lib/tmpfiles.d/kamailio.conf`. rtpproxy does
this:
```
/cat /usr/lib/tmpfiles.d/rtpproxy.conf
d /var/run/rtpproxy 0755 rtpproxy rtpproxy
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Pre-Submission Checklist
- [ ] 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
Pre-Submission Checklist
- [ ] 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
Committed to master in a new module app_python3.
--
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/issues/544#issuecomment-369451154___
Kamailio
Closed #544.
--
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/issues/544#event-1498098488___
Kamailio (SER) - Development Mailing List
The intent is for
1.
https://github.com/kamailio/kamailio/blob/master/misc/examples/kemi/kamailio-basic-kemi.cfg
1.
https://github.com/kamailio/kamailio/blob/master/misc/examples/kemi/kamailio-basic-kemi-python.py
to work out of the box.
--
You are receiving this because you are subscribed to
OMG @miconda you are so fast. I just filed this ticket. Anyway the commits
have fixed the issue in my testing. Thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
### Description
Use KEMI cfgutils.lock() and cfgutils.unlock().
Expect native behaviour of lock() unlock().
Instead segfault.
### Troubleshooting
The KEMI wrappers do not have leading sip_msg_t* argument.
Wrapper for lock() is cfg_lock()
Prototype for cfg_lock() is static int
Pre-Submission Checklist
- [ ] 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
Fixed and squashed - kindly check again.
--
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/1450#issuecomment-367125522___
Kamailio (SER) -
Going to fix this then squash (--force push)
--
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/1450#issuecomment-367119426___
Kamailio (SER)
- update documentation and python_examples/ to reflect the new module name
- fix typo arg->args in python_examples/handler.py
Pre-Submission Checklist
- [ ] Commit message has the format required by CONTRIBUTING guide
- [ ] Commits are split per component (core, individual modules,
Thanks @miconda! I'll wait until it is merged to rebase and follow-up.
The immediate tasks will be to fix documentation, and have a go at reload.
Will gather more developer and community feedback before proposing any
refactoring.
--
You are receiving this because you are subscribed to this
- use same symbols names as app_python so these two modules cannot be used
together
- use GIL for thread management
Pre-Submission Checklist
- [ ] Commit message has the format required by CONTRIBUTING guide
- [ ] Commits are split per component (core, individual modules, libs,
Squash and rebase
--
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/1447#issuecomment-366516955___
Kamailio (SER) - Development Mailing List
@aalba6675 pushed 1 commit.
fecdde8 use GIL for thread management
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/kamailio/kamailio/pull/1447/files/3dffbe048e2b9f90d156c308fb543ab4d0a59a7d..fecdde85b60cb5321eca11ee9977b7c2c22fc097
First attempt at porting app_python to app_python3.
Mostly symbols names are the same as app_python so these two
modules cannot be loaded together. Exported functions are identical so
in theory scripts need not change.
TODO: reenable thread management
Pre-Submission Checklist
- [ ]
The are separate and orthogonal
Option 1:
```
rtpengine_manage('record-call=on')
## will start recoridng no need for start_recording()
```
Option 2:
```
rtpengine_manage()
### sometime later in route script
start_recording()
```
--
You are receiving this because you are subscribed to this
### Description
Document record-call option in rtpengine module
### Troubleshooting
rtpengine module has an undocumented option in rtpengine_manage and
rtpengine_offer
```
rtpengine_manage("record-call=on")
```
The use case is to start the recording immediately so the recording structures
62 matches
Mail list logo
