[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
Mon Oct 10 14:56:01 CDT 2016
[ https://issues.asterisk.org/jira/browse/ASTERISK-26430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=232628#comment-232628 ]
Nir Simionovich (GreenfieldTech - Israel) commented on ASTERISK-26430:
----------------------------------------------------------------------
Well,
According to ngrep, our HEP packets looks like this:
{noformat}
U 45.76.0.142:59365 -> 178.62.4.230:9060
HEP3.V............................2......
W......
.
../.............
.........
WE~......
.........&yFOfLs.zxlm-3NLnPiV64mTXZJCEm7hN......{"ssrc":1304398795,"type":200,"report_blocks":[],"report_count":0,"sender_information":{"ntp_timestamp_sec":"1476128929","ntp_timestamp_usec":"4281174200","rtp_timestamp":286317630,"packets":0,"octets":0}}
U 45.76.0.142:59365 -> 178.62.4.230:9060
HEP3........
.............2..............
W......
.
..-.............
.....................................................&yFOfLs.zxlm-3NLnPiV64mTXZJCEm7hN.....U{"ssrc":909466674,"type":200,"report_blocks":[{"lsr":"1864485015","ia_jitter":260,"fraction_lost":0,"source_ssrc":1304398795,"dlsr":327614,"packets_lost":0,"highest_seq_no":6528}],"report_count":1,"sender_information":{"ntp_timestamp_sec":"1476128936","ntp_timestamp_usec":"535743","rtp_timestamp":236160,"packets":247,"octets":29408}}
U 45.76.0.142:59365 -> 178.62.4.230:9060
HEP3..............................2......
W......
.
...(............
.........
WE~......
.........&yFOfLs.zxlm-3NLnPiV64mTXZJCEm7hN.....Z{"ssrc":1304398795,"type":200,"report_blocks":[{"lsr":"1864927526","ia_jitter":108,"fraction_lost":0,"source_ssrc":909466674,"dlsr":79745,"packets_lost":0,"highest_seq_no":2570}],"report_count":1,"sender_information":{"ntp_timestamp_sec":"1476128936","ntp_timestamp_usec":"4287618111","rtp_timestamp":286636446,"packets":333,"octets":4691}}
U 45.76.0.142:59365 -> 178.62.4.230:9060
HEP3........
.............2..............
W......
.
../,............
.....................................................&yFOfLs.zxlm-3NLnPiV64mTXZJCEm7hN.....U{"ssrc":909466674,"type":200,"report_blocks":[{"lsr":"1864920259","ia_jitter":194,"fraction_lost":0,"source_ssrc":1304398795,"dlsr":220659,"packets_lost":0,"highest_seq_no":6779}],"report_count":1,"sender_information":{"ntp_timestamp_sec":"1476128941","ntp_timestamp_usec":"536218","rtp_timestamp":476160,"packets":497,"octets":59296}}
U 45.76.0.142:59365 -> 178.62.4.230:9060
HEP3..............................2......
W......
.
...^............
.........
WE~......
.........&yFOfLs.zxlm-3NLnPiV64mTXZJCEm7hN.....[{"ssrc":1304398795,"type":200,"report_blocks":[{"lsr":"1865255237","ia_jitter":114,"fraction_lost":0,"source_ssrc":909466674,"dlsr":57835,"packets_lost":0,"highest_seq_no":2801}],"report_count":1,"sender_information":{"ntp_timestamp_sec":"1476128941","ntp_timestamp_usec":"4294901858","rtp_timestamp":286857206,"packets":563,"octets":10196}}
{noformat}
Now, if I extract the JSON data only, it looks like this:
{noformat}
{
"ssrc": 1304398795,
"type": 200,
"report_blocks": [],
"report_count": 0,
"sender_information": {
"ntp_timestamp_sec": "1476128929",
"ntp_timestamp_usec": "4281174200",
"rtp_timestamp": 286317630,
"packets": 0,
"octets": 0
}
}
{
"ssrc": 909466674,
"type": 200,
"report_blocks": [
{
"lsr": "1864485015",
"ia_jitter": 260,
"fraction_lost": 0,
"source_ssrc": 1304398795,
"dlsr": 327614,
"packets_lost": 0,
"highest_seq_no": 6528
}
],
"report_count": 1,
"sender_information": {
"ntp_timestamp_sec": "1476128936",
"ntp_timestamp_usec": "535743",
"rtp_timestamp": 236160,
"packets": 247,
"octets": 29408
}
}
{noformat}
As far as I can tell, the HEP3 protocol has nothing to do with the actual IP addresses, and is mostly reliant
on the call-id for the RTCP correlation - which makes much sense to me.
Regardless of the above, the question of:
{quote}
Why is it an IPv6 address when it should be an IPv4. That's the core of the problem. It should be IPv4. That's the real bug, HEP just exposed it because it uses it. That's what ultimately needs to be determined here.
{quote}
is for sure the right question, but I believe that providing a means of bypassing the issue for stage 1 will be sufficient, as the true cause of the issue is being investigated. Sure, it's a little hacky, but I think it's a step forward.
> 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, Resources/res_rtp_asterisk
> Affects Versions: GIT
> Reporter: Nir Simionovich (GreenfieldTech - Israel)
> Assignee: Unassigned
>
> 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