[sr-dev] [kamailio] inline function suip2a() (ip_addr.h) not working for ipv6 (#379)
topotomaso
notifications at github.com
Fri Oct 23 14:47:03 CEST 2015
I observed that the inline function suip2a() (ip_addr.h) contains a silly bug and therefor does not work for IPv6 conversions. This silly bug is preventing sip_trace() to work in the onsend_route block for IPv6 sip messages.
Rem.: The function suip2a() is used only by the siptrace module.
Test background (just for understanding the use case):
- using kamailio 4.1.3 (with an additional patch to let onsend_route be called also for replies taken from kamailio 4.2.x)
- kamailio is used as loadbalancer in stateless mode (using forward() only)
- sip tracing is used by explictly calling sip_trace() in onsend_route, route and onreply routing block to be able to implement an interface specific sip tracing (no SIP transaction based sip tracing is applied by using the siptrace's trace_flag)
The silly bug:
In suip2a() the function ip6tosbuf() is called with an odd buffer length argument of value "sizeof(buf)-4" which is equal to "IP6_MAX_STR_SIZE -1". ip6tosbuf() however needs at least a buffer length of IP6_MAX_STR_SIZE (otherwise it returns immediately without writing anything into the buffer).
So regarding IPv6 adresses the ascii output of suip2a() is alway an empty IPv6 reference ([]).
```
static inline int ip6tosbuf(unsigned char* ip6, char* buff, int len)
{
int offset;
register unsigned char a,b,c;
register unsigned char d;
register unsigned short hex4;
int r;
#define HEXDIG(x) (((x)>=10)?(x)-10+'A':(x)+'0')
offset=0;
if (unlikely(len<IP6_MAX_STR_SIZE))
return 0;
...
}
#define SUIP2A_MAX_STR_SIZE (IP6_MAX_STR_SIZE + 2 /* [] */ + 1 /* \0 */)
/* returns an asciiz string containing the ip
* (<ipv4_addr> or [<ipv6_addr>])
*/
static inline char* suip2a(union sockaddr_union* su, int su_len)
{
static char buf[SUIP2A_MAX_STR_SIZE];
int offs;
if (unlikely(su->s.sa_family==AF_INET6)){
if (unlikely(su_len<sizeof(su->sin6)))
return "<addr. error>";
buf[0]='[';
offs=1+ip6tosbuf((unsigned char*)su->sin6.sin6_addr.s6_addr, &buf[1],
sizeof(buf)-4);
buf[offs]=']';
offs++;
}else
if (unlikely(su_len<sizeof(su->sin)))
return "<addr. error>";
else
offs=ip4tosbuf((unsigned char*)&su->sin.sin_addr, buf, sizeof(buf)-2);
buf[offs]=0;
return buf;
}
```
A possible verfied patch looks like this (using this patch sip_trace() is working now as expected in this use case).
```
--- ip_addr.h 2014-04-24 12:02:35.000000000 +0200
+++ ip_addr.h 2015-10-22 18:48:40.553177206 +0200
@@ -737,14 +737,14 @@
return "<addr. error>";
buf[0]='[';
offs=1+ip6tosbuf((unsigned char*)su->sin6.sin6_addr.s6_addr, &buf[1],
- sizeof(buf)-4);
+ IP6_MAX_STR_SIZE);
buf[offs]=']';
offs++;
}else
if (unlikely(su_len<sizeof(su->sin)))
return "<addr. error>";
else
- offs=ip4tosbuf((unsigned char*)&su->sin.sin_addr, buf, sizeof(buf)-2);
+ offs=ip4tosbuf((unsigned char*)&su->sin.sin_addr, buf, IP4_MAX_STR_SIZE);
buf[offs]=0;
return buf;
}
```
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/379
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20151023/9e2bc59e/attachment-0001.html>
More information about the sr-dev
mailing list