[sr-dev] [kamailio/kamailio] nathelper always sends SIP pings in IPv6 scenario (#1587)

[Sebastian Damm]

### 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20180711/e133adb4/attachment.html>