<!-- 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
when using kamailio with mod siptrace in trace mode, option pings from nathelper module and tls encrypted packets do not get duplicated
### Troubleshooting
#### Reproduction
<!-- If the issue can be reproduced, describe how it can be done. -->
version: kamailio 5.1.6 (x86_64/linux)
modparam("nathelper", "ping_nated_only", 0) modparam("siptrace", "trace_mode", 1) modparam("siptrace", "duplicate_uri", "sip:10.1.1.1:5888")
when listening on sip:10.1.1.1:5888 all the duplicated sip packets arrive except option pings from nathelper and tls encrypted traffic (which should then be already decrypted by kamailio)
### Possible Solutions
<!-- If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix. -->
seems that core triggers are not evaluated when using tls or nathelper option pings
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` version: kamailio 5.1.6 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_BLACKLIST, 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 6.3.0 ```
* **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 `uname -a`) -->
``` Linux AT1LKAM04 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux
```
Add some more context from the discussion on the list: The nathelper module uses a low level core function (udp_send or send_raw) to send out the OPTION ping. This low level function does not contains the callbacks that are responsible for transferring the message to e.g. the siptrace module. This is the reason for this behavior.
Are you getting any error log when sending out via TLS. The same function is executed for sending over UDP and TCP, so there is no reason not to duplicate it.
For nathelper, what Henning said applies, the module has low level functions for nat pings, having some variants where it can spoof source IP address. So C coding is needed, that being more an enhancement, while the TLS traffic should be there and if doesn't work is a bug.
sorry, siptrace module was not enabled on the tls machine. siptrace "trace_mode" "on" works fine with tls.
@miconda we would like to contribute some work for this, but it would be great to get some advice if it could actually work. And if it would work, is it wise to go through core triggers? I can imagine that this could stress kamailio unnecessarily.
@rdissauer The SREV_NET_DATA_OUT event is already used in in the msg_send_buffer, so this is ok performance wise. The main reason that this logic is placed in msg_send_buffer() is that it saves duplicated code - otherwise this logic needs to be added to the different protocol sending low level functions. But it can be pushed one level down to udp_send(), tcp_send, and sctp_core_msg_send(). The logic for sending websocket is implemented with another event, this needs some more investigation.
@rdissauer Any update from your side regarding this issue or the implementation?
Closing old feature request. If someone still has interest, the best is to make directly a PR.
Closed #1722.
-
Daniel-Constantin Mierla -
Henning Westerholt
-
Roman Dissauer