11 Jul
2018
11 Jul
'18
4:07 p.m.
### Description
We upgraded from Kamailio 4.4.5 to 5.1.4 today. We have a IPv6-to-v4 loadbalancer which
sends out NAT pings to keep the connection through routers alive. So it is not a real NAT
scenario.
Kamailio 4.4.5 sent out dummy 4-byte UDP packets. Kamailio 5.1.4 sends out SIP OPTIONS
although we didn't even configure sipping_from.
Our configuration:
```
loadmodule "nathelper.so"
modparam("nathelper", "received_avp", "$(avp(i:801))")
modparam("nathelper", "natping_interval" , 14)
modparam("nathelper", "ping_nated_only" , 0)
```
When looking into the code, Kamailio should not even be able to send out OPTIONS without
sipping_from being configured. It does anyhow. This results in broken keepalive packets.
```
OPTIONS sip:foobar@[2003:a:c6b:8400:204:aaaa:bbbb:cccc]:6060;transport=udp;line=s4cqtu
SIP/2.0.
Via: SIP/2.0/UDP [2001:AB7:0:0:0:0:0:1]:5060;branch=z9hG4bK9474521.
From: ;tag=uloc-5b2b6211-355f-81fc4-3f1f9b57-6a9dc2.
To: sip:foobar@[2003:a:c6b:8400:204:aaaa:bbbb:cccc]:6060;transport=udp;line=s4cqtu.
Call-ID: -6a9dc2-cac4404@2001:AB7:0:0:0:0:0:1.
CSeq: 1 OPTIONS.
Content-Length: 0.
.```
Those packets get rejected by some clients, bringing them offline, effectively.
After adding the sipping_from modparam, those OPTIONS get sent with a correct From
header.
### Troubleshooting
#### Reproduction
Our v4-only SIP proxies don't show the behavior, our v6-to-v4 loadbalancers do. I
don't know if this can be reproduced with a default installation on a IPv6 setup.
#### 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).
-->
```
(paste your log messages here)
```
#### 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
Setting the sipping_from parameter at least fixes the OPTIONS packet. But we found no way
to send those dummy UDP packets instead of full OPTIONS.
### Additional Information
Kamailio branch 5.1 pulled yesterday, 5.1.4
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.1.4 (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_LISTEN 16, 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.7.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 `uname -a`)
-->
```
Debian Wheezy, Linux hostname 3.2.0-5-amd64 #1 SMP Debian 3.2.96-3 x86_64 GNU/Linux
```
--
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/1587