|Summary:||ASTERISK-14545: IAX does not bind to multiple virtual IP's correctly|
|Reporter:||Nik Middleton (middletn)||Labels:|
|Date Opened:||2009-07-27 16:31:40||Date Closed:||2011-06-07 14:08:24|
|Description:||This is a resurection of 0007315 which seems to have come back post 1.4.19|
Versions of Asterisk past 1.4.19 don't appear to bind correctly to multiple IP's, only the first listed. Having searched the docs, I can't find anything that's really changed. Even setting the IP to 0.0.0.0 doesn't help
netstat -aln |grep 4569 reports:
udp 0 0 192.168.20.251:4569 0.0.0.0:*
udp 0 0 192.168.20.219:4569 0.0.0.0:*
udp 0 0 192.168.20.218:4569 0.0.0.0:*
If I NAT a public IP to 20.251 via a PIX it works, the remaining two do not work.
The remote * reports the host as UNREACHABLE
I do not have this issue with anything prior to 1.4.22
That said, registrations DO work just fine.
It seems that Asterisk only binds to the first IP listed in IAX.conf
As a quick test I loaded 18.104.22.168, same config, and it WORKS! I can only assume therefore that post this version IAX on multiple virtual IP's is broken.
|Comments:||By: Nik Middleton (middletn) 2009-07-28 15:18:51|
Guy's, I know everyone's busy, but could I get some feedback on this issue? I have a book comming out next month on advanced Asterisk methods with a forward by Mark S. no less. It has a big section on some methods to increase call capacity (using broadband) and it relies on this (multiple IP's) working. I really don't want to put a big message saying 'THIS IS BROKE PAST 19.2!' It's not going to look good, and besides don't we want users to use the most up to date version?
By: David Vossel (dvossel) 2009-08-20 17:33:35
How can this be a resurrection if 0007315 was resolved as "not fixable"?
*edit I think I may know where you are coming from. I didn't test this yet, but I did a quick code comparison and I couldn't find any changes that would have affected this.
By: Tilghman Lesher (tilghman) 2009-08-24 00:23:15
As far as I know, this has always depended upon your routing table to work. Asterisk queries the routing table, based upon destination IP, in order to figure out what source IP it should place within the packet.
By: Leif Madsen (lmadsen) 2009-09-17 14:58:27
We will need a configuration setup that is experiencing this so it can be reproduced, and the 'iax2 debug' will potentially be useful as well. If you can provide a PCAP trace of this issue happening, I think that would also be handy.
By: Nik Middleton (middletn) 2009-09-17 15:22:23
No probs, I'll endeavor to work up a test server this weekend and send the results
By: Leif Madsen (lmadsen) 2009-09-30 10:04:35
Just pinging this issue!
By: Leif Madsen (lmadsen) 2009-10-26 09:53:32
Closed due to lack of feedback. If the reporter is able to provide the requested information, please reopen this issue. Thanks!