[Home]

Summary:ASTERISK-16545: [patch] IPv6: System configured for only IPv4 tries sending to IPv6
Reporter:Olle Johansson (oej)Labels:
Date Opened:2010-08-11 05:13:07Date Closed:2012-02-27 14:35:05.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/IPv6
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) suppress_warnings.diff
Description:Running on a dual stack system, with a bind address set to 0.0.0.0 (indicating only IPv4 support), placing a call to a domain that only resolves into an IPv6 server, Asterisk tries to send anyway with poor results. This indicates a few things to me:
- Something is wrong in the code, since it doesn't act as documented in sip.conf. (bindaddr 0.0.0.0 should only get IPv4 support)
- Many log messages are wrong
- Again, like in another issue, Asterisk tries sending SIP messages to a NULL address. This is a bug in itself.

I have modified the host names in the log, can provide programmer with proper addresses for testing.

****** ADDITIONAL INFORMATION ******

From the log:

   > ast_get_srv: SRV lookup for '_sip._udp.test6.edvina.net' mapped to host skrep.edvina.net, port 5060
[Aug 11 12:02:07] ERROR[80381]: netsock2.c:245 ast_sockaddr_resolve: getaddrinfo("skrep.edvina.net", "(null)", ...): nodename nor servname provided, or not known
[Aug 11 12:02:07] WARNING[80381]: chan_sip.c:5011 create_addr: No such host: test6.edvina.net
[Aug 11 12:02:07] DEBUG[80381]: chan_sip.c:5015 create_addr: Not an IPv4 nor IPv6 address, cannot set port.
[Aug 11 12:02:07] DEBUG[80381]: chan_sip.c:5025 create_addr: Not an IPv4 nor IPv6 address, cannot get port.
[Aug 11 12:02:07] DEBUG[80381]: chan_sip.c:5028 create_addr: Not an IPv4 nor IPv6 address, cannot set port.
[Aug 11 12:02:07] WARNING[80381]: acl.c:693 ast_ouraddrfor: Cannot connect
[Aug 11 12:02:07] DEBUG[80381]: chan_sip.c:3224 ast_sip_ouraddrfor: Setting SIP_TRANSPORT_UDP with address [fe80::225:ff:fe44:74ec%en1]:5060
[A

The "Not an IPv4 nor IPv6 address" is obviously wrong.
Then proceeding with the IPv6 address that was not configured (the fe80:: address) is bad. Later on:

-----
Audio is at 5060
Lets set up the text sdp
Text is at [fe80::225:ff:fe44:74ec%en1]:5060
Adding codec 0x4 (ulaw) to SDP
Adding text codec 0x8000000 (t140) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

---- Then this: ----
Reliably Transmitting (no NAT) to (null):
INVITE sip:olle@skrep.edvina.net SIP/2.0
Via: SIP/2.0/UDP [fe80::225:ff:fe44:74ec%en1]:5060;branch=z9hG4bK2a360055
Max-Forwards: 2
From: "olle" <sip:olle@[fe80::225:ff:fe44:74ec%en1]>;tag=as74078f0d
To: <sip:olle@ipv6.edvina.net>
Contact: <sip:olle@[fe80::225:ff:fe44:74ec%en1]:5060>
Call-ID: 4edcade011367dd47a791cbd53e27e79@[fe80::225:ff:fe44:74ec%en1]:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX SVN-branch-1.8-r281650
Date: Wed, 11 Aug 2010 10:02:07 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 368

v=0
o=root 1460731631 1460731631 IN IP6 fe80::225:ff:fe44:74ec%en1
s=Asterisk PBX SVN-branch-1.8-r281650
c=IN IP6 fe80::225:ff:fe44:74ec%en1
t=0 0
m=audio 16382 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
m=text 19976 RTP/AVP 106
a=rtpmap:106 T140/1000
a=sendrecv

---- Then this ---
[Aug 11 12:02:07] WARNING[80381]: chan_sip.c:3086 __sip_xmit: sip_xmit of 0x101a20a00 (len 1003) to (null) returned -1: Invalid argument
   -- Called olle@ipv6.edvina.net

When sip_xmit failes, the call should fail. Here it seems like it proceeds.After six retransmits to NULL, the call finally fails.

We should propably define a new hangup cause or another variable that indicates that this call was sent to the wrong address family.
Comments:By: Marc Blanchet (blanchet) 2010-08-11 08:14:56

note to self: this was tested on MacOSX.
By: Olle Johansson (oej) 2010-08-11 08:20:42

Exactly. I can test on Linux too... I didn't realize that could mean a difference, but based on our earlier discussions I SHOULD have guessed that.
By: Simon Perreault (sperreault) 2010-08-16 10:28:38

I am unable to reproduce this on Linux. I tried with the 4 possible combinations of dnsmgr={on,off} and srvlookup={yes,no}. All I manage to get is this, which seems pretty normal:

   -- Executing [1@default:1] Dial("SIP/pjsua-00000002", "SIP/peer") in new stack
[Aug 16 11:26:46] DEBUG[19053]: chan_sip.c:24775 sip_request_call: Asked to create a SIP channel with formats: 0x4 (ulaw)
[Aug 16 11:26:46] DEBUG[19053]: chan_sip.c:7151 sip_alloc: Allocating new SIP dialog for 05a21454272720671bc31bc05497adc1@[::1]:0 - INVITE (No RTP)
[Aug 16 11:26:46] DEBUG[19053]: chan_sip.c:24877 sip_request_call: Cant create SIP call - target device not registered
[Aug 16 11:26:46] DEBUG[19053]: chan_sip.c:5542 sip_destroy: Destroying SIP dialog 05a21454272720671bc31bc05497adc1@[::1]:0
[Aug 16 11:26:46] WARNING[19053]: app_dial.c:2031 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Unknown)
 == Everyone is busy/congested at this time (1:0/0/1)
[Aug 16 11:26:46] DEBUG[19053]: app_dial.c:2705 dial_exec_full: Exiting with DIALSTATUS=CHANUNAVAIL.
   -- Auto fallthrough, channel 'SIP/pjsua-00000002' status is 'CHANUNAVAIL'
By: Simon Perreault (sperreault) 2010-08-16 10:30:51

I uploaded suppress_warnings.diff, which should take care of a few unnecessary warnings.
By: Jason Parker (jparker) 2010-08-25 16:12:41

Punt.

After considering this a bit, I believe this is far more complicated than I'm up to.  In order to do this, it seems like you'd need some global variable to say whether you do/do not want to try IPv6 addresses - and you'd have to check this variable in a lot of places (pretty much anywhere that would initiate a connection).  ast_ouraddrfor() is doing exactly what it should - it's finding the address that we would be sending a packet from, if we were to send one.
By: Russell Bryant (russell) 2010-09-02 10:17:25

I have an Asterisk 1.8.0-beta4 instance running on Linux with a public IPv4 and IPv6 address.  I tried reproducing this and was unable to.  When calling another PBX that has a AAAA record, it would only attempt to send to the IPv6 address if I had configured Asterisk with bindport=::.  It would _not_ attempt to send to that address with bindport=0.0.0.0.

So, this is looking like it may be a mac specific issue.  If that is the case, I don't consider it a 1.8.0 release blocker, so I'm going to update Mantis to reflect that.
By: Mark Michelson (mmichelson) 2012-01-12 15:50:20.764-0600

This issue never got closed and somehow got miscategorized, leading to it being rediscovered by me today. I want to get this resolved.

My problem is, I don't know exactly what the issue here is. Here are the things that are clear to me:

1. The system has both an IPv4 and an IPv6 address on it.
2. The user agent we attempt to call resolves to an IPv6 address.
3. Asterisk's SIP configuration has been configured to bind to an IPv4 address.

Now here's where I'm unclear:

1. Were we attempting to call a configured peer or were we dialing a SIP URI directly in the dialplan? It looks like you are dialing configured peers, but I'd like to make sure about this.
2. If you are dialing a peer, is it one that registers with Asterisk or is it one that has an IP address configured statically in its config? I would suspect you're using a peer that is configured statically, because I think that the endpoint would be unable to register if it tried.

And most importantly, since this has not been looked at in over a year, is this still an issue? The 1.8 code has changed a lot since this issue was filed, and I'd like to make absolutely sure this is still a problem before taking the time to try to fix it.

If this is still a problem, I think the way to go about fixing is the following:
1. If a peer is configured with an IPv6 address, but we are going to bind to an IPv4 address, then print a warning and do not add the peer to the peer list.
2. Modify dnsmgr or srv code so that we can filter out AAAA records if we can only send to IPv4 addresses. In the case where only AAAA records are available, then that would be treated the same as if we could not resolve a host.

Does this sound reasonable?
By: Richard Mudgett (rmudgett) 2012-01-12 20:38:37.274-0600

v1.8 -r345976 May have a bearing here for the dnsmgr.
By: Olle Johansson (oej) 2012-01-13 01:50:42.749-0600

Mark. Thanks for taking the time to come back to this issue. As you say it was a long time ago. I had time allocated by Uninet back then to try stuff like this out, but did not get many responses back. That was then, not now. And I don't remember details about this either. If you want to I can propably restore some DNS records for you to play with. If I have time over the weekend, I'll try to see if I can find the configuration.

Again thanks. We need to sort out all the issues with IPv6 and take them seriously.
By: Mark Michelson (mmichelson) 2012-02-20 10:48:18.586-0600

So, I keep coming back to this, and my problem is that every time I start looking at the code, I keep feeling as though this may have already been fixed. Specifically, it seems as though all address resolution done in chan_sip.c in current 1.8+ will make sure to filter address families properly based on the family of the bindaddr. I really need confirmation that this is still an issue before I am going to try to actually fix it.
By: Mark Michelson (mmichelson) 2012-02-27 14:35:05.599-0600

I'm making a bold decision here. I'm closing this issue.

The reason is that, as I stated in my last comment, it appears that all DNS lookups in chan_sip.c are diligent enough to properly filter which family of address to lookup. Combine this with the fact that this issue was filed prior to many many changes in chan_sip.c with regards to this specific issue, plus the fact that several commenters on this issue say they can't reproduce it, and I feel like closing it is the proper way to go. Please feel free to re-open this issue if you can demonstrate that this is still a problem in current 1.8 code.