<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
module: tm
kemi proto relay functions fails on TLS:
- ki_t_relay_to_proto
- ki_t_relay_to_proto_addr
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
13(19) ERROR: {1 1 REGISTER 184193281845942-18001879945554(a)192.168.1.135} tm [tm.c:2934]: ki_t_relay_to_proto(): bad protocol specified <TLS>
13(19) ERROR: {1 1 REGISTER 184193281845942-18001879945554(a)192.168.1.135} sl [sl_funcs.c:414]: sl_reply_error(): stateless error reply used: I'm terribly sorry, server error occurred (1/SL)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
It's missing an equal zero (== 0) on TLS test.
Code: tm.c
if (strncasecmp(sproto->s, "UDP", 3) == 0) {
proto = PROTO_UDP;
} else if (strncasecmp(sproto->s, "TCP", 3) == 0) {
proto = PROTO_TCP;
} else if (strncasecmp(sproto->s, "TLS", 3)) {
proto = PROTO_TLS;
} else {
LM_ERR("bad protocol specified <%s>\n", sproto->s);
return E_UNSPEC;
}
Fix:
if (strncasecmp(sproto->s, "UDP", 3) == 0) {
proto = PROTO_UDP;
} else if (strncasecmp(sproto->s, "TCP", 3) == 0) {
proto = PROTO_TCP;
} else if (strncasecmp(sproto->s, "TLS", 3) == 0) {
proto = PROTO_TLS;
} else {
LM_ERR("bad protocol specified <%s>\n", sproto->s);
return E_UNSPEC;
}
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.5.0 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 4.9.2
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.11 (jessie)
Release: 8.11
Codename: jessie
Linux routersip 4.18.0-348.el8.0.2.x86_64 #1 SMP Sun Nov 14 00:51:12 UTC 2021 x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3111
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3111(a)github.com>
(sr-dev on CC)
Hello,
I am not aware of a special handling of MTU discovery regarding IPv6 UDP traffic in Kamailio core. But of course, we have a lot of code.
You find the implementation of the MTU handling in the src/core/udp_server.c file. Its just setting the appropriate socket option right now.
Cheers,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com
-----Original Message-----
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Rick van Rein
Sent: Thursday, May 12, 2022 1:31 PM
To: sr-users(a)lists.kamailio.org
Subject: [SR-Users] Path MTU issues over UDP/IPv6
Hello,
IPv6 routers never fragment packets. Rather, they drop a packet that is too large for a (local) MTU and send back ICMPv6 "Packet Too Big".
This seems to cause loss of larger SIP messages when an ISP tunnels their IPv6 at the expense of the MTU.
The pmtu_discovery flag sets Don't Fragment in IPv4 traffic; in IPv6 this is an implied property. Does Kamailio learn a lower MTU from any "Packet Too Big" for IPv6 even if pmtu_discovery is not set?
Future resends can then be fragemented appropriately.
The udp_mtu setting diverts to another protocol, but that would be a setting as low as the worst peer, impacting all. It would be a weird struggle with a telco serving many. PMTU would be better to rely on, but how does it work in Kamailio?
Details on
https://www.rfc-editor.org/rfc/rfc3542#section-11.3https://stackoverflow.com/questions/38817837/how-does-mtu-retransmission-wo…
Thanks,
-Rick
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<!-- 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 -->
We've come into the rare issue when a kamailio process used the old $var() value for the current request message and messed some things up.
LOG_WARN when $var() is used uninitialized in config. I can also just LOG_NOTICE this.
Can this be brought to 5.6?
Thank you,
Stefan
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3114
-- Commit Summary --
* pv: log uninit ()
-- File Changes --
M src/modules/pv/pv_core.c (9)
M src/modules/pv/pv_svar.h (1)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3114.patchhttps://github.com/kamailio/kamailio/pull/3114.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3114
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3114(a)github.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 -->
- [ ] PR should be backported to stable branches
- [s] Tested changes locally
#### Description
Add functions to get and set a dlg_var from outside that dialog using call-ID, from-tag and to-tag to select the desired one
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3109
-- Commit Summary --
* dialog: dlg_get_var(ci, ft, tt, key, dst_var)
* dialog: dlg_set_var(callid, ft, tt, key, value)
-- File Changes --
M src/modules/dialog/dialog.c (213)
M src/modules/dialog/doc/dialog_admin.xml (96)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3109.patchhttps://github.com/kamailio/kamailio/pull/3109.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3109
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3109(a)github.com>