Another puzzler from my asterisk system: For reference, here is my basic setup: -Asterisk (latest CVS as of this afternoon (3/19/2003) -All clients are Cisco ATA 186 units -Public IP for Asterisk server -All clients behind NAT firewalls Everything was working fine with my Asterisk system until I added a client behind a firewall that has three numbers in the final octet of its public IP number. For instance: A client behind a firewall with public IP of 63.77.102.4 would be fine A client behind a firewall with public IP of 63.77.102.221 would fail The failure does not present itself until an INVITE is issued (registration works fine). When the INVITE happens to or from such an IP, though, Asterisk segfaults. After studying the output of sip debug, I noticed that somehow the Contact: field is getting messed up. The field should look like: Contact: <sip:3117000@63.91.19.135:5060;user=phone;transport=udp> Instead, it looks like: Contact: <sip:3117000@63.91.19.0:5060;user=phone;transport=udp> I checked the settings in the ATA, and they are all correct, with no reference whatsoever to '63.91.19.0'. The ATA is on the same firmware as all of my working units. I can only assume that Asterisk is somehow losing that last octet when it deals with a NAT client behind a firewall which has a three-digit number at the end. Does this seem accurate, or am I missing something here? I have attached an excerpt of sip debug output showing this problem (line 22). Any suggestions that anyone could offer for troubleshooting/fixing this problem would be greatly appreciated. Thanks! -Matt -- Matthew Farley <asterisk@wheatstate.net> -------------- next part -------------- sip show peers Name/username Host Mask Port Status 3116001/3116001 63.91.19.8 (D) 255.255.255.255 61342 Unmonitored 3116000/3116000 63.91.19.8 (D) 255.255.255.255 61342 Unmonitored 3115004/3115004 208.222.40.6 (D) 255.255.255.255 65038 Unmonitored 3115003/3115003 (Unspecified) (D) 255.255.255.255 0 Unmonitored 3117001/3117001 63.91.19.135 (D) 255.255.255.255 64622 Unmonitored 3117000/3117000 63.91.19.135 (D) 255.255.255.255 64622 Unmonitored 3115002/3115002 208.222.40.6 (D) 255.255.255.255 65040 Unmonitored 3115001/3115001 208.222.40.6 (D) 255.255.255.255 65040 Unmonitored 3115000/3115000 208.222.40.6 (D) 255.255.255.255 65038 Unmonitored iconnecthere/63 213.137.73.178 255.255.255.255 5060 Unmonitored 8 headers, 0 lines Sip read: INVITE sip:3115000@208.222.40.225;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.3.200:5060 From: <sip:3117000@208.222.40.225;user=phone>;tag=1890095068 To: <sip:3115000@208.222.40.225;user=phone> Call-ID: 1099999641@192.168.3.200 CSeq: 2 INVITE Contact: <sip:3117000@63.91.19.0:5060;user=phone;transport=udp> User-Agent: Cisco ATA v2.15 ata18x (020927a) Expires: 300 Content-Length: 249 Content-Type: application/sdp v=0 o=3117000 15763 15763 IN IP4 192.168.3.200 s=ATA186 Call c=IN IP4 63.91.19.0 t=0 0 m=audio 10000 RTP/AVP 0 4 8 101 a=rtpmap:0 PCMU/8000/1 a=rtpmap:4 G723/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 11 headers, 11 lines Using latest request as basis request Sending to 192.168.3.200 : 5060 (NAT)
If you run asterisk with -vvvgc you can force Asterisk to dump core when it crashes. then you can run: gdb ./asterisk core.<foo> . . . (gdb) bt And that will give you a backtrace of where the crash occured. Even just the backtrace will give some useful information, but if you have even a vague idea of how to use gdb, you can use it to get more detailed information by changing the frame and looking at specific data elements. Remember, the core file is useless except on the system where you compiled it, so DON'T SEND ME A CORE FILE, but *do* send the backtrace results. Mark On 19 Mar 2003, Matthew Farley wrote:> Another puzzler from my asterisk system: > > For reference, here is my basic setup: > -Asterisk (latest CVS as of this afternoon (3/19/2003) > -All clients are Cisco ATA 186 units > -Public IP for Asterisk server > -All clients behind NAT firewalls > > Everything was working fine with my Asterisk system until I added a > client behind a firewall that has three numbers in the final octet of > its public IP number. > > For instance: > > A client behind a firewall with public IP of 63.77.102.4 would be fine > A client behind a firewall with public IP of 63.77.102.221 would fail > > The failure does not present itself until an INVITE is issued > (registration works fine). When the INVITE happens to or from such an > IP, though, Asterisk segfaults. After studying the output of sip debug, > I noticed that somehow the Contact: field is getting messed up. > > The field should look like: > Contact: <sip:3117000@63.91.19.135:5060;user=phone;transport=udp> > > Instead, it looks like: > Contact: <sip:3117000@63.91.19.0:5060;user=phone;transport=udp> > > I checked the settings in the ATA, and they are all correct, with no > reference whatsoever to '63.91.19.0'. The ATA is on the same firmware as > all of my working units. > > I can only assume that Asterisk is somehow losing that last octet when > it deals with a NAT client behind a firewall which has a three-digit > number at the end. Does this seem accurate, or am I missing something > here? > > I have attached an excerpt of sip debug output showing this problem > (line 22). Any suggestions that anyone could offer for > troubleshooting/fixing this problem would be greatly appreciated. > > Thanks! > -Matt > > > -- > Matthew Farley <asterisk@wheatstate.net> >