[asterisk-bugs] [JIRA] (ASTERISK-21784) Asterisk 11 attempts IPv6 (with an insane address) when talking to an IPv4-only endpoint
Rusty Newton (JIRA)
noreply at issues.asterisk.org
Mon May 13 18:48:38 CDT 2013
Rusty Newton created ASTERISK-21784:
---------------------------------------
Summary: Asterisk 11 attempts IPv6 (with an insane address) when talking to an IPv4-only endpoint
Key: ASTERISK-21784
URL: https://issues.asterisk.org/jira/browse/ASTERISK-21784
Project: Asterisk
Issue Type: Bug
Security Level: None
Components: Core/Netsock
Affects Versions: 11.3.0
Environment: Asterisk 11.3.0 / Optware (current) / DD-wrt 17201 (2.6 kernel) on Linksys E3000. IPv6 & IPv4 configured and functional.
Reporter: Tony Hain
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list