sr-dev June 2022

sr-dev@lists.kamailio.org

20 participants
283 discussions

[kamailio/kamailio] Path MTU handling; implicit IPv4 assumption, suggested solution for IPv6 (Issue #3119)
by vanrein 26 Aug '22

26 Aug '22

### Description Larger SIP frames get dropped when sent over UDP and IPv6. The sending side has MTU 1500 and the receiving side has MTU 1492. This is an IPv6-only setup, so this is problematic. Also, pulling down the MTU of a general server for a tunneled peer would smear like an oil stain. The suggestion to fallback on TCP feels like a hack. ### Troubleshooting #### Reproduction Send a SIP message to a network interface with a lower MTU than the submitted frame size. #### Debugging Data None, transmission works fine. #### Log Messages None, transmission works fine. #### SIP Traffic Irrelevant. #### Code Investigation I explored the Kamailio source code for MTU handling. https://github.com/kamailio/kamailio/blob/81265e41b52cfda9a284233c93683522a… * This defaults to switching off the Don't Fragment bit on IPv4 frames, to allow them to be broken up downstream. * This should check for an IPv4 socket, because (at least) Linux has a separate symbolic value `IPV6_MTU_DISCOVER` * Note that IPv6 is never broken up by routers; they always return ICMPv6 message Packet Too Big * Note that IPv6 Path MTU discovery by the kernel is automatic only for connected UDP sockets * Since Kamailio uses unconnected UDP sockets, Path MTU issues cause packets to be dropped * Note that such packet drops depend on a somewhat dynamic SIP message size, causing random behaviour * I therefore suggest that Kamailio is lacking in some of its IPv6 logic https://github.com/kamailio/kamailio/blob/81265e41b52cfda9a284233c93683522a… * This enables the reporting of ICMP errors, including Path MTU but also other useful things like Host Not Found * This should check for an IPv4 socket, because (at least) Linux has a separate symbolic value `IPV6_RECVERR` * Note that the same behaviour is available on BSD, so it need not be specific to Linux * Note that handling errors is done with `recvmsg()` with a flag `MSG_ERRQUEUE`, which is not used in Kamailio * Note that the ancillary data from `recvmsg()` holds data to cleverly handle ICMP or ICMPv6 responses * I therefore suggest that Kamailio is lacking a fair chunk of its ICMP and ICMPv6 logic * I expect that this may bring efficiency gains due to faster closing of transactions ### Possible Solutions I have been thinking about ways to lower MTU values only for some peers. 1. Using connected sockets might work, possibly as an alternative when Path MTU problems arise. It might not scale however. 2. Every socket could have an extra sending socket set to a lower MTU. The use of `SO_REUSEADDR` seems to allow for that. 3. Before falling back on an extra socket, the desired MTU could be set. Alternatively, as for IPv6, an MTU of 1280 might be considered in many cases: - *If you can carry 6 out of 8 coffee mugs from the kitchen, you need to walk twice, and 4+4 is easier than 6+2* - Anything over the MTU splits into at least 2 frames - The headers added are 40 bytes IPv6 header and 8 bytes Fragment Extension Header - 2 frames can hold a single frame of 2*1280-40-8 = 2512 bytes - Up to 2512 bytes original MTU, breakup in 1280 byte frames will be fine - 3 frames are going to be useful for larger frames, then a similar style can be used - This might help to decide whether 1280 or a higher MTU is most desirable ### Additional Information ``` Kamailio 5.2.1 from Debian stable ``` * **Operating System**: ``` Linux Debian stable on kernel 4.19.0 ``` (I don't suppose it matters, this code has been around for ages. I used permalinks for stable reference). -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3119 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3119(a)github.com>

3 12

[kamailio/kamailio] dispatcher: socket atribute usage for initial OPTIONS (#2853)
by sergey-safarov 26 Aug '22

26 Aug '22

### Description I use TCP sockets to relay calls to backend servers. Also, I have enabled `tcp_reuse_port` and enabled `socket` attribute in dispatcher settings. INVITE messages to backend servers are now properly send from port 5060. ### Expected behavior For all messages are used the same TCP socket and same source port for all messages (including OPTIONS). #### Actual observed behavior But initial OPTIONS (before the first call send) uses a random source port. ### Additional Information * **Kamailio Version** - output of `kamailio -v` used current c503d2bd31a580138a67f1d4a265ccde5791d271 with small customization. * **Operating System**: aarch64 ``` [root@sbc-a0 ~]# cat /etc/os-release NAME="CentOS Linux" VERSION="8" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="8" PLATFORM_ID="platform:el8" PRETTY_NAME="CentOS Linux 8" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:8" HOME_URL="https://centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-8" CENTOS_MANTISBT_PROJECT_VERSION="8" ``` -- 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/2853

2 2

[kamailio/kamailio] dialog: set context iuid for CANCEL requests (PR #3096)
by descartin 26 Aug '22

26 Aug '22

set context iuid for CANCEL requests to let isflagset function return the right value in case a dialog flag was previously set on the call   #### 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 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:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Using kamailio 5.4 version, we have seen that dlg_isflagset is not detecting a dialog flag set in the request route for the initial INVITE, when a CANCEL request arrives. We have applied this change to set the dialog context unique ide for this request. Since it's done on dlg_onreply, dlg_onroute and dlg_ontimeout functions. This way, dlg_get_by_iuid(&dctx->iuid) in the function ki_dlg_isflagset is not NULL and dialog flags are detected. Is this change correct? Or can it generate any kind of issues? thanks a lot and regards David You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3096 -- Commit Summary -- * dialog: set context iuid for CANCEL requests to let isflagset function return the right value in case a dialog flag was previously set on the call -- File Changes -- M src/modules/dialog/dlg_handlers.c (3) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3096.patch https://github.com/kamailio/kamailio/pull/3096.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3096 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3096(a)github.com>

3 6

[kamailio/kamailio] Path MTU discovery for IPv6 (PR #3141)
by vanrein 21 Aug '22

21 Aug '22

#### Pre-Submission Checklist - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] 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) - [X] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [ ] PR should be backported to stable branches (no, it is a requirement to use UDP/IPv6 with everyone) - [X] Tested changes locally (same results as before with the Kamailio test framework) - [ ] Related to issue #3119 #### Description The IPv6 support for Path MTU discovery is absent, but IPv6 has no DF flag to allow downstream fragmentation. See Issue #3119 for my discovery / learning path. In short, unconnected UDP sockets do not learn Path MTU problems, so a message dropped once will be dropped again on resend. Using `IPV6_PMTUDISC_WANT`, any knowledge in the kernel can be used to fragment the message at sending time, as intended for IPv6. These patches actually correct two IPv6-related things in the `core/udp_server.c`, 1. Benefit from any kernel knowledge about Path MTU for IPv6 2. The same option to learn from UDP_ERRORS is now available for IPv6 Do note that the last has not been implemented for IPv4 or IPv6. It is more useful for IPv6, allowing instant "tm" resends for Path MTU, but not "sl" I think. I cannot do that work, but this brings IPv6 to the same level as IPv4. ``` commit 0f90cff05c1a448eb2f85f83b4c087ab32ede11 Author: Rick van Rein <rick(a)openfortress.nl> Date: Sat Jun 11 10:57:32 2022 +0000 core: Issue 3119. Handling ICMPv6 Packet too Big - This was only defined for IPv4 under flag UDP_ERRORS - IPv6 has no toggle DF to clear for en-route fragmentation - Kamailio currently does not collect with recvmsg(...,MSG_ERRQUEUE) - The benefits of adding that can be instant resends for "tm" messages - Note that "sl" messages will have been forgotten at this point commit 6b404b5f9807174177bee36eaf3543be0794f55e Author: Rick van Rein <rick(a)openfortress.nl> Date: Sat Jun 11 10:44:27 2022 +0000 core: Issue #3119. Path MTU kernel info for IPv6 - For IPv4, DF is an option; for IPv6 it is always active - This makes pmtu_discover an IPv4-only option - This means that we should set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_WANT - Unconnected UDP sockets can now learn from ICMPv6 "Packet too Big" - As a result, hitting a Path MTU upper bound is a learning process - This should stop consistent SIP packet drops due to Path MTU ``` You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3141 -- Commit Summary -- * core: Issue #3119. Path MTU kernel info for IPv6 * core: Issue 3119. Handling ICMPv6 Packet too Big -- File Changes -- M doc/misc/NEWS (2) M src/core/udp_server.c (44) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3141.patch https://github.com/kamailio/kamailio/pull/3141.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3141 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3141(a)github.com>

3 13

[kamailio/kamailio] [stirshaken] add identity header in reply messages or to a separate variable (#2770)
by sergei lavrov 14 Aug '22

14 Aug '22

### Description I'm unable to add the generated `Identity` value to reply message when `kamailio` acts as a redirect server and replies with `302 Moved Temporarily` instead of relaying `INVITE`. This code doesn't work, i.e. no `Identity` header in `302 Moved Temporarily` message: ``` if (stirshaken_add_identity($var(x5u), $var(attest), $var(origtn_val), $var(desttn_val), $var(origid)) == 1) { append_branch("sip:$rU@127.0.0.1:6060"); sl_send_reply("302", "Moved Temporarily"); exit; } ``` ### Expected behavior It would be nice if the `stirshaken_add_identity_*` functions would add the generated `Identity` header to the reply messages too, or store the generated `Identity` header in a separate variable, like `$identity`, for the future processing. -- 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/2770

4 10

[kamailio/kamailio] secfilter: Wrong format on RPC response data (Issue #2992)
by Olle E. Johansson 12 Aug '22

12 Aug '22

secfilter RPC functions to get statistics use a console format to printing data, suitable for **kamcmd** but not for any RPC method. This should be converted to a machine-parsable data structure (much like dispatcher, usrloc and htable data dumps). -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2992 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/2992(a)github.com>

2 3

[kamailio/kamailio] Add 5.6 branch packages for Ubuntu 22.04 (Issue #3147)
by compuwizz 09 Aug '22

09 Aug '22

Is it possible to add the 5.6 branch deb/ubuntu packages to https://deb.kamailio.org/ for Ubuntu 22.04? I see Ubuntu 22.04 native repos have kamailio 5.5 in them but I'd like to use 5.6. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3147 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3147(a)github.com>

4 7

Releasing v5.6.1
by Daniel-Constantin Mierla 14 Jul '22

14 Jul '22

Hello, I am considering to release Kamailio v5.6.1 (out of branch 5.6) on Wednesday, July 6, 2022 -- in about 1 week and a half from now. If anyone is aware of issues not yet on the bug tracker, report them there asap in order to have a better chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022 * https://www.asipto.com/sw/kamailio-advanced-training-online/

6 8

(Off-topic) Vienna, meeting
by Henning Westerholt 09 Jul '22

09 Jul '22

(Off-topic) Hello, In about two weeks I will be a few days in Vienna (12h - 14th July). If you want to meet for a drink to chat about Kamailio and other topics, just contact me off-list. Thanks, and regards, Henning

1 1

[kamailio/kamailio] Location for git submodules in the source tree (Issue #3164)
by Daniel-Constantin Mierla 08 Jul '22

08 Jul '22

With the introduction of an external project reference via git submodule by `tls_wolfssl`, I am opening this to discuss where it would be the _best_ place for them. Now it is in the folder of the tls_wolfssl module, but I noticed that many projects have a dedicated folder like `vendor` (or `extern`, `import`), and I would somehow that approach more because it is easier to locate the external code and figure out its implications in licensing, dependencies, etc ... Moreover, it can happen that many modules would need to use that external project/repo. For example, now crypto uses libssl, but for someone that wants to get rid of it and use only libwolfssl may contribute an alternative of that module. Then two modules would need same external repo and having it inside another module would not be straightforward to manage. Given the above, I would suggest to place them in a folder like `misc/vendor` or similar inside the `misc/` directory, not to get back into growing the root folder. I would like to keep `src/` folder only for Kamailio specific code. If someone has other suggestions, propose them in comments and let's try to get to a decision soon. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3164 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3164(a)github.com>

4 7

← Newer
1
...
8
9
10
11
12
13
14
...
29
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2022