[asterisk-bugs] [JIRA] (ASTERISK-21725) Asterisk 11 attempts IPv6 (with an insane address) when talking to an IPv4-only endpoint

Tue Dec 19 13:57:08 CST 2017

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240883#comment-240883 ] 

Joshua Colp commented on ASTERISK-21725:
----------------------------------------

[~traud] Any issues which I didn't think had been specifically fixed were tagged during JIRA cleanup.

> Asterisk 11 attempts IPv6 (with an insane address) when talking to an IPv4-only endpoint
> ----------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21725
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21725
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Netsock
>    Affects Versions: 11.3.0, 13.18.4
>         Environment: Asterisk 11.3.0 / Optware (current) / DD-wrt 17201 (2.6 kernel) on Linksys E3000. IPv6 & IPv4 configured and functional.
>            Reporter: Tony Hain
>         Attachments: issue_21725_logdate_20130430.txt
>
>
> Upgrade asterisk via uninstall 1.8.? (~dec '11) / install 11.3.0
> Migrate jabber to motif for Gvoice 
> Calls to/from Gvoice working again. Calls from 3102 working. Calls to 3102 fail.
> The most polite thing I can say about the Asterisk 11 IPv6 implementation is that "the developer can't read". The incoming call from Xlite on OSX works fine over IPv6 or IPv4, then the dialplan points to a name that resolves IPv4-only for the 3102. The IPv4 address for the 3102 is acquired correctly from DNS, because it shows up in the most significant 32 bits of the subsequent IPv6 connect attempt (even in the cases of the incoming call from X-lite being IPv4). At best, the IPv4 address should be stored in IPv6 format as a "mapped" address in the form ::ffff:IPv4/96, and that format should not appear in the outer header on the wire, but could be passed as data. The entire point of that format was to allow for internal storage of 128 bit values for IPv4-only endpoints, so it would make sense if that address format showed up in a log somewhere. What should never happen is that the IPv4 address would be on-the-wire as the most significant 32 bits of an address. That implies that the implementation is 'unaware' of the fact that the answer it got from DNS was IPv4, and just jammed the answer plus random crap into the address field. The flip side of that lack of awareness would be that an IPv6-only answer came back from DNS and the 128 bits was jammed into a buffer meant for 32 bits, so something ends up overwritten. Snippets of the SIP debug output:
> {noformat}
> <--- Reliably Transmitting (no NAT) to 172.16.144.46:43968 --->
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 172.16.144.46:43968;branch=z9hG4bK-d8754z-f553c96682293764-1---d8754z-;received=172.16.144.46;rport=43968
> From: "Tony"<sip:X-lite at fqdn>;tag=1bf0cd06
> To: <sip:123 at fqdn>;tag=as3755e173
> Call-ID: YjM3MzVmYWFkMDRmZTU4ZmI2N2UxMmE3MzA4MjI2Mzc
> CSeq: 1 INVITE
> Server: HGC PBX
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
> Supported: replaces, timer
> Contact: <sip:123 at 172.16.144.62:5060>
> Content-Type: application/sdp
> Content-Length: 289
> v=0
> o=root 604546809 604546809 IN IP4 172.16.144.62
> s=Asterisk PBX 11.3.0
> c=IN IP4 172.16.144.62
> ......
> ACK sip:123 at 172.16.144.62:5060 SIP/2.0
> Via: SIP/2.0/UDP 172.16.144.46:43968;branch=z9hG4bK-d8754z-2f015734fce4183e-1---d8754z-;rport
> Max-Forwards: 70
> Contact: <sip:X-lite at 172.16.144.46:43968>
> To: <sip:123 at fqdn>;tag=as3755e173
> From: "Tony"<sip:X-lite at fqdn>;tag=1bf0cd06
> Call-ID: YjM3MzVmYWFkMDRmZTU4ZmI2N2UxMmE3MzA4MjI2Mzc
> CSeq: 1 ACK
> User-Agent: X-Lite release 4.5 stamp 69608
> Content-Length: 0
> <------------->
> --- (10 headers 0 lines) ---
> Audio is at 15364
> Video is at [2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:10006
> Adding codec 100003 (ulaw) to SDP
> Adding codec 100002 (gsm) to SDP
> Adding codec 100004 (alaw) to SDP
> Adding codec 100017 (testlaw) to SDP
> Adding video codec 200002 (h263) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (no NAT) to [ac10:903c:989d:bf7a::800:0]:5060:
> INVITE sip:3102FXS at 3102.fqdn SIP/2.0
> Via: SIP/2.0/UDP [2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:5060;branch=z9hG4bK65197241
> Max-Forwards: 70
> From: "Tony" <sip:X-lite@[2001:abc:def:7000:6a7f:74ff:fe9e:8e71]>;tag=as6bae6195
> To: <sip:3102FXS at 3102.fqdn>
> Contact: <sip:X-lite@[2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:5060>
> Call-ID: 6a0a34a2594ff7e57d81a13e14aadd3d@[2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:5060
> CSeq: 102 INVITE
> .....
> ---
> Retransmitting #1 (no NAT) to [ac10:903c:989d:bf7a::800:0]:5060:
> INVITE sip:3102FXS at 3102.fqdn SIP/2.0
> Via: SIP/2.0/UDP [2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:5060;branch=z9hG4bK65197241
> Max-Forwards: 70
> From: "Tony" <sip:X-lite@[2001:abc:def:7000:6a7f:74ff:fe9e:8e71]>;tag=as6bae6195
> To: <sip:3102FXS at 3102.fqdn>
> Contact: <sip:X-lite@[2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:5060>
> Call-ID: 6a0a34a2594ff7e57d81a13e14aadd3d@[2001:abc:def:7000:6a7f:74ff:fe9e:8e71]:5060
> CSeq: 102 INVITE
> .....
> {noformat}
> Maybe X-lite is doing something stupid, but the only change between working and not was to upgrade Asterisk from 1.8 to 11, so Asterisk would have to be feeding X-lite something different. Even then, the IPv6 address in the INVITE is for an interface on the Asterisk box. 
> Maybe it is possible that whoever built the Optware image (Asterisk 11.3.0 built by slug @ imitron on a i686 running Linux on 2013-04-24 19:39:03 UTC) had something misconfigured, but even so there are clearly no sanity checks in the core code to make sure the address length matches the protocol being spoken. There is no AAAA record for the 3102, so there should never be an attempt to connect to it using IPv6, and particularly with a malformed address. There never was an attempt to connect over IPv4, just retransmits on IPv6 until the call timed out and closed.
> Issue ASTERISK-16545 claims "DNS lookups in chan_sip.c are diligent enough to properly filter which family of address to lookup", but that is clearly not the case. That issue was the flipped scenario (IPv6-only target) on 1.8. In any case, there is no way a 32 bit answer from DNS should get jammed into the upper part of an IPv6 address. 

--
This message was sent by Atlassian JIRA
(v6.2#6252)