03-29-2013 10:57 AM - edited 03-21-2019 10:01 AM
Hi,
I've a CISCO SPA112 with this error:
Mar 29 17:05:44 ***myip*** DNS fail -1; stun.twt.it
I've tried to set a stun server to get my ip address (stun.twt.it) but this not work!
DNS are sets well, also using Google and sip registration works well.
I've also stried to get an ip address instead of FQDN of stun server, but nothing...
Also tried to change stun server, with stun.ekiga.net or other, but nothing...
Firmware bug?
Thank you.
Simone.
03-29-2013 12:29 PM
Hi Simone,
You don't mention what your goal is and I don't know how advanced of a user you are, so my answers may be too basic for you...
You say that you've "... tried to set a stun server to get my ip address ..."
STUN typically does not provide an IP address to the ATA, this is the job for a DHCP server.
Take a look at the DNS servers configured on the ATA. It looks like the ATA is not able to resolve stun.twt.it to an IP address.
Take a look at the default router configured on the ATA, is the ATA able to get out via the gateway to access the DNS server?
Try replacing stun.twt.it with 82.113.193.63 and see how this works. You seem to be saying that you've done this, but you would not get a DNS error then, so just to be sure, try it again and see what messages syslog produces.
You mention that Google works. Do you mean that a computer connected to the same network as the SPA112 with the same DHCP settings [DNS, mask, gateway] as the SPA112 is able to properly perform searches? Have you tried replacing the CAT-5 cable between the SPA112 and the switch/router?
Do you really need to use STUN? You may be able to get away in a NAT environment with simply using the NAT Mapping Enable parameter.
Run Wireshark on the SPA112's subnet and verify that the network on the wire is what you're expecting. For example the SPA112 is ARPing for the gateway, sending the DNS lookup to the appropriate server, and so on. Many times what is configured on the SPA112 is not what the person intended and network packets make troubleshooting this easier.
Also, please verify that you're on the most current firmware release of 1.3.1(003) as of March 29 2013.
Regards,
Patrick---
04-02-2013 12:35 AM
Patrik Hello and thank you for your answer.
The adapter is configured correctly (ip and gateway) in fact the SIP account is registered properly. The problem is that the SIP registration is passed with the LAN IP address of the device and not the classic WAN IP address. Usually when this happens, is solved with the use of STUN. In fact, I tried to set stun.twt.it, but the adapter returns the following error (on syslog):
IPADDR *** *** DNS fail -1; stun.twt.it
If I try to put the ip address of the stun (77.72.174.163) I have this other error instead:
IPADDR *** *** Invalid IP address 77.72.174.163 in nal_dns_auto_refresh
The VoIP adapter is configured in the following way:
IP: 192.168.10.200
netmask: 255.255.255.0
GW: 192.168.100.1
DNS1: 62.48.51.6 (dns.texnet.it)
DNS2: 8.8.4.4
Everything looks correct but the stun does not work. Any suggestions?
04-02-2013 02:07 AM
Side note: based on responses from both DNS servers you are mentioned, the IP address of stun.twt.it is 82.113.193.63, not the 77.72.174.163 (tried on Tue Apr 2 11:02:40 2013 +0200)
Can you catch the device's packets on the wire to verify that DNS query for stun.twt.it is answered correctly by a DNS server ?
04-02-2013 06:24 AM
Ok, you're right. The IP is 82.113.193.63 stun.twt.it. The other IP address was another stun server (ekiga!?).
However, even setting the correct IP address, the adapter returns the same message (from syslog):
April 2 15:18:52 IPADDR *** *** Invalid IP address 82.113.193.63 in nal_dns_auto_refresh
Any other suggestions? My client begins to lose patience ...
Anyway, thank you for the prompt responses that you're giving me.
04-03-2013 12:33 AM
I tried to simulate the situation in my lab. Having a linux firewall I was able to make a more thorough sniff to see if and which packages were passed.
The only working configuration that I could run in the millions I've tried is as follows:
Since tcpdump these are the results.
The problem is that if the stun server changes the IP address, the adapter will not work as having manually set.
I hope that this bug will be recognized and solved in short, the use of the stun server with dns resolution is too important to the proper functioning of VoIP.
Thank you.
04-03-2013 12:51 AM
You need to supply full syslog/debug + SIP + DNS packets. Then you may hope that your complain will reach developpers.
By the way, I disagree with "use of the stun server with dns resolution is too important to the proper functioning of VoIP" somewhat. I have several phones behind NAT and I never used the STUN. It doesn't mean that bugs should not be fixed ...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide