[asterisk-bugs] [JIRA] (ASTERISK-26430) res_hep: will fail, when an IPv6 interface is enabled on the installed server
Nir Simionovich (GreenfieldTech - Israel) (JIRA)
noreply at issues.asterisk.org
Thu Oct 6 05:41:01 CDT 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-26430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=232564#comment-232564 ]
Nir Simionovich (GreenfieldTech - Israel) commented on ASTERISK-26430:
----------------------------------------------------------------------
Here is the information:
{noformat}
[root at vultr ~]# cat /etc/issue
CentOS release 6.8 (Final)
Kernel \r on an \m
[root at vultr ~]# uname -a
Linux vultr.guest 2.6.32-642.4.2.el6.x86_64 #1 SMP Tue Aug 23 19:58:13 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
{noformat}
Currently using chan_sip, not chan_pjsip - simply because it's a simple machine.
The code is applied with the patch from issue ASTERISK-26427, which corrects support for chan_sip and homer.
I'm using vultr.com vitrual host for this test, and my current platform shows:
{noformat}
[root at vultr ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Virtual CPU 714389bda930
stepping : 1
microcode : 1
cpu MHz : 3499.996
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc up rep_good xtopology unfair_spinlock pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm arat xsaveopt fsgsbase bmi1 avx2 smep bmi2 erms invpcid
bogomips : 6999.99
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
[root at vultr ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 56:00:00:38:2b:53 brd ff:ff:ff:ff:ff:ff
inet 45.76.0.142/23 brd 255.255.254.0 scope global eth0
inet6 fe80::5400:ff:fe38:2b53/64 scope link
valid_lft forever preferred_lft forever
{noformat}
> res_hep: will fail, when an IPv6 interface is enabled on the installed server
> -----------------------------------------------------------------------------
>
> Key: ASTERISK-26430
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-26430
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_hep
> Affects Versions: GIT
> Reporter: Nir Simionovich (GreenfieldTech - Israel)
> Assignee: Nir Simionovich (GreenfieldTech - Israel)
>
> When trying to utilize res_hep, while the server has an IPv6 IP address defined, the HEP report will fail, notifying the console:
> [Oct 1 13:56:37] NOTICE[14719]: res_hep.c:466 hep_queue_cb: Unable to send packet: Address Family mismatch between source/destination
> Additional information:
> In order to investigate, I've added a couple of ast_log entries, in order to ascertain the actual discrepancy. The following is observed when the issue arises:
> {noformat}
> [Oct 1 13:56:37] NOTICE[14719]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 2
> [Oct 1 13:56:37] NOTICE[14719]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
> [Oct 1 13:56:37] NOTICE[14719]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 16
> [Oct 1 13:56:37] NOTICE[14719]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
> [Oct 1 13:56:37] NOTICE[14719]: res_hep.c:467 hep_queue_cb: Sending from: 1
> [Oct 1 13:56:37] NOTICE[14719]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 10
> [Oct 1 13:56:37] NOTICE[14719]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
> [Oct 1 13:56:37] NOTICE[14719]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 28
> [Oct 1 13:56:37] NOTICE[14719]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
> [Oct 1 13:56:37] NOTICE[14719]: res_hep.c:468 hep_queue_cb: To server: 0
> {noformat}
> The above was generated using:
> {code:java|borderStyle=solid}
> int ast_sockaddr_is_ipv4(const struct ast_sockaddr *addr)
> {
> ast_log(AST_LOG_NOTICE, "My address family is: %d\n", addr->ss.ss_family);
> ast_log(AST_LOG_NOTICE, "My address family should be: %d\n", AF_INET);
> ast_log(AST_LOG_NOTICE, "My address length is: %d\n", addr->len);
> ast_log(AST_LOG_NOTICE, "My address length should be: %u\n", sizeof(struct sockaddr_in));
> return addr->ss.ss_family == AF_INET &&
> addr->len == sizeof(struct sockaddr_in);
> }
> {code}
> Now, if I disable IPv6 on the machine, using the following:
> {noformat}
> sysctl -w net.ipv6.conf.all.disable_ipv6=1
> sysctl -w net.ipv6.conf.default.disable_ipv6=1
> {noformat}
> Now, the Asterisk output is as following:
> {noformat}
> [Oct 1 14:07:25] NOTICE[14975]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 2
> [Oct 1 14:07:25] NOTICE[14975]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
> [Oct 1 14:07:25] NOTICE[14975]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 16
> [Oct 1 14:07:25] NOTICE[14975]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
> [Oct 1 14:07:25] NOTICE[14975]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 2
> [Oct 1 14:07:25] NOTICE[14975]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
> [Oct 1 14:07:25] NOTICE[14975]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 16
> [Oct 1 14:07:25] NOTICE[14975]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
> {noformat}
> So, this is somewhat of an issue, as most cloud providers these day will enable by-default IPv6 addressing on the servers, making the module unusable till it's disabled - which is somewhat counter productive.
> In order to validate potential configuration issues, I've tried changing my HEP server from IP:PORT combo, to only IP address - that caused Asterisk to go completely nuts. Recommendation, separate host ip and port to two separate configuration items, to avoid confusion.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list