Add CIFuzz workflow action to have fuzzers build and run on each PR.
This is a service offered by OSS-Fuzz, on which Kamailio already runs.
Signed-off-by: David Korczynski <david(a)adalogics.com>
<!-- 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 -->
- [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
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [x ] 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 -->
- [x ] PR should be backported to stable branches
- [x ] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
Add CIFuzz Github action to build and run fuzzers on pull requests.
This will run the fuzzers for 600 seconds (split between all the fuzzers) in the CI when a pull request is made and is a service by OSS-fuzz. It can help with catching bugs early and catch regressions.
Documentation for CIFuzz can be found here: https://google.github.io/oss-fuzz/getting-started/continuous-integration/
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2903
-- Commit Summary --
* <a href="https://github.com/kamailio/kamailio/pull/2903/commits/f10ba5c9e81f0ae0f2f6…">github/workflow: add CIFuzz integration</a>
-- File Changes --
A .github/workflows/cifuzz.yml (26)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2903.patchhttps://github.com/kamailio/kamailio/pull/2903.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/2903
Hi guys,
We are quite newby about Kamailio and we are trying to use it as a load
balancer. While installing certificates we started having problems.
We use Kamailio (vers. 5.5) deployed on a VM (Ubuntu, 20.04 LTS).
We cannot connect via TLS Kamailio VM with clients or other TCP VM.
Our Kamailio currently exposes only port 5060 in UDP and TCP.
Even doing a port scan on localhost, port 5061, used for the TLS protocol,
is instead closed.
There are 3 things worth noting:
- All ports for all protocols are open on the firewall;
- Before we set the disable_tcp option to "no", the 5060 was only reachable
in UDP;
- Even if you put a non-existent certificate, the system does not return an
error so we cannot understand if the goodness of the certificates affects
the opening of the door. Furthermore, we did not find any different
behavior when switching from crt format (key for the private key) to PEM.
If someone can help us would be very appreciated.
Thank you very much
Here is our tls configuration:
kamailio.cfg
#!define WITH_TLS 1
...
disable_tcp=no
auto_aliases=no
….
loadmodule "sl.so"
loadmodule "tls.so"
...
modparam("tls", "private_key", "/etc/kamailio/key.pem")
modparam("tls", "certificate", "/etc/kamailio/crt.pem")
modparam("tls", "ca_list", "/etc/kamailio/ca.pem")
enable_tls=yes
tls.config
[server:default]
method = TLSv1.2+
verify_certificate = no
require_certificate = no
private_key = /etc/kamailio/kamailio-selfsigned.key
certificate = /etc/kamailio/kamailio-selfsigned.pem
#ca_list = /etc/kamailio/tls/cacert.pem
#crl = /etc/kamailio/tls/crl.pem
[client:default]
#method = TLSv1.2+
verify_certificate = no
require_certificate = no
*Sent with Shift
<https://tryshift.com/?utm_source=SentWithShift&utm_campaign=Sent+with+Shift…>*
Module: kamailio
Branch: master
Commit: 01434fa89bac3174ff68c08cf776dc73abb2eb2d
URL: https://github.com/kamailio/kamailio/commit/01434fa89bac3174ff68c08cf776dc7…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2021-10-25T19:23:08+02:00
textopsx: docs - fixed title for sections
---
Modified: src/modules/textopsx/doc/functions.xml
---
Diff: https://github.com/kamailio/kamailio/commit/01434fa89bac3174ff68c08cf776dc7…
Patch: https://github.com/kamailio/kamailio/commit/01434fa89bac3174ff68c08cf776dc7…
---
diff --git a/src/modules/textopsx/doc/functions.xml b/src/modules/textopsx/doc/functions.xml
index 3de3a6c8e6..7500cbaa85 100644
--- a/src/modules/textopsx/doc/functions.xml
+++ b/src/modules/textopsx/doc/functions.xml
@@ -559,11 +559,11 @@ hf_iterator_end("i1");
</section>
<section id="textopsx.f.hf_iterator_next">
<title>
- <function moreinfo="none">textopsx.f.hf_iterator_next(iname)</function>
+ <function moreinfo="none">hf_iterator_next(iname)</function>
</title>
<para>
Move the iterator to the next header. It must
- be called also after bl_iterator_start() to get the first
+ be called also after hf_iterator_start() to get the first
header.
</para>
<para>
@@ -594,7 +594,7 @@ hf_iterator_end("i1");
</section>
<section id="textopsx.f.hf_iterator_prev">
<title>
- <function moreinfo="none">textopsx.f.hf_iterator_prev(iname)</function>
+ <function moreinfo="none">hf_iterator_prev(iname)</function>
</title>
<para>
Move the iterator to the previous header. It must
@@ -757,7 +757,7 @@ bl_iterator_end("b1");
</section>
<section id="textopsx.f.bl_iterator_next">
<title>
- <function moreinfo="none">textopsx.f.bl_iterator_next(iname)</function>
+ <function moreinfo="none">bl_iterator_next(iname)</function>
</title>
<para>
Move the iterator to the next line in the body. It must
Hi!
I just stumbled into a hard-to-find problem with Kamailio.
The symtom was that Kamailio simply did not read a lot of incoming messages, so they did not get any response. We saw traffic coming in on the interface with tcpdump, but not in the kamailio logs. Restarting Kamailio solved the problem for a while, then it started again.
I noticed there was something related to the DB, so for testing I disabled all db-based functions, but missed siptrace that connected and operated in the background by the config settings, nothing in the routing script.
I finally traced the problem to the siptrace module. The db table had grown way too big (due to attacks) and adding new records to it took way too much time. During that time, with SIPtrace waiting for confirmation, the process locked and packets where dropped.
Kamailio still handled calls, but a lot of calls was dropped.
I will solve this shortly by setting up a parallell smaller Kamailio that logs to database instead of running siptrace with DB in a production server.
But in order for others not to find themselves in this very hard to find situation, is there something that can be done to the siptrace code so it doesn’t execute in the same process that listens for incoming SIP messages? It would be a huge improvement to just block a background process so that siptrace doesn’t work, instead of blocking a listen process and drop traffic.
I don’t think I can write that code. Sorry. Otherwise it would have been a high priority, because these problems in production drove me almost insane. Restarting - all works fine. After a few hours the first packets are lost. Calls getting through for some customers all of the time.
Sorry for a long post, but I want this in the archives to help others.
Regards,
/O