|Summary:||ASTERISK-16618: Unable to use IPv4 addresses for a TCP host when using IPv6|
|Reporter:||Leif Madsen (lmadsen)||Labels:|
|Date Opened:||2010-08-25 10:26:00||Date Closed:||2012-06-29 10:35:28|
|Description:||This is kind of a weird edge case, and I think I might know why it's not working.|
I'm trying to "front end" my 126.96.36.199 Asterisk instance with Asterisk 1.8.0-beta4 for testing purposes and to allow IPv6 connectivity.
This is done on the same box.
The error I'm getting is the following:
..........SIP channel loading...
[2010-08-25 11:19:44] ERROR: netsock2.c:245 ast_sockaddr_resolve: getaddrinfo("127.0.0.1", "(null)", ...): Address family for hostname not supported
[2010-08-25 11:19:44] WARNING: acl.c:564 resolve_first: Unable to lookup '127.0.0.1'
If I switch host=[some_ipv6_address] on the peer, the error goes away. When using an IPv4 address, I get that error.
I've disabled srvlookup=yes and dnsmgr without success.
****** STEPS TO REPRODUCE ******
On the same box, I'm instantiating to instances of Asterisk, one being 188.8.131.52, the other being 1.8.0-beta4.
| +----------+ +---------+ |
| | 184.108.40.206 | | 1.8.0b4 | |
| | |<-TCP->| | |
| +----------+ +---------+ |
Peer configuration on both boxes:
|Comments:||By: Leif Madsen (lmadsen) 2010-08-25 10:33:08|
Also of note, if I use an IP address that is not a localhost loopback, it does the same thing (i.e. 220.127.116.11)
By: David Vossel (dvossel) 2010-08-25 11:43:14
What is your UDP bind address? IPv4 or IPv6?
By: Leif Madsen (lmadsen) 2010-08-25 11:57:43
It depends which instance of Asterisk it is. 1.8.0-beta4 is UDP bound to the IPv6 address, and 18.104.22.168 is bound to the IPv4 address.
Look at the bullet notes in the "Steps To Reproduce" section.
Uploading the sip.conf files per mmichelson.
By: Simon Perreault (sperreault) 2010-08-26 08:07:19
If I understand this right, the 1.8 instance will be talking over IPv6 to the outside world, and over IPv4 to the 1.6 instance, right?
Therefore, it cannot be bound to just an IPv6 address. This would prevent it from talking to the 1.6 instance over IPv4.
As indicated in the comments in sip.conf.sample, you need to set bindaddr=:: to be able to use IPv4 and IPv6 simultaneously.
Can you please try that and report back?
By: Leif Madsen (lmadsen) 2010-09-07 15:18:22
* 1.8 would be talking to the outside world via IPv6 using UDP
* 1.6.2 would be talking to the outside world via IPv4 using UDP
* 1.8 would be talking to 1.6.2 via IPv4 via the loopback interface (127.0.0.x) via TCP
So as you can see, I don't want to use IPv4 and IPv6 simultaneously really. The TCP connections will interact via IPv4, and the 1.8 box only interacts via IPv6 on the UDP interface.
Hopefully that makes it more clear.
By: Simon Perreault (sperreault) 2010-09-07 15:29:13
I understand. What you want is multiple SIP sockets. On your 1.8 box, one socket would be IPv6-only and bound to an external address, while another would be IPv4-only and bound to the loopback interface.
Sadly, the current chan_sip architecture doesn't allow this. We can only ever have a single SIP socket. To lift this limit would require a *major* architectural change.
This is also unrelated to IPv6.
By: Russell Bryant (russell) 2010-09-09 15:48:49
Well, for the scenario he's trying to implement, chan_sip already supports multiple sockets (1 per transport). It has one bindaddr for UDP and another for TCP. He's trying to bind UDP to IPv6 and TCP to IPv4. That seems like something that should work to me. What am I missing?
By: Simon Perreault (sperreault) 2010-09-09 15:55:20
You're right, I had not noticed the use of different transports.
I think the problem is the following:
We're using the address family of the UDP socket to filter name lookups. (I'm not sure off the top of my head if this includes address literals like "127.0.0.1".) So if you bind your UDP socket to an IPv6 address, Asterisk will only try to resolve names to IPv6 addresses. This info is in the sample sip.conf.
We're doing this so that if you're bound to IPvX you don't try to reach foo.com over IPvY.
We're aware that this is a hack, and would like to have a better solution.