[Freeswitch-dev] Issue around IPv6

[Tamas]

Hello,

we have tracked down the issue. It had nothing to do with IPv6, but the
DNS resolver.
In resolv.conf we had 2 DNS servers, the 1st one was OK, but the 2nd was
bad.
It had happened that the 1st one responded very slowly so the box
started to ask the 2nd one which didn't give back right records. It did
that till the 2nd DNS server was late so the REGISTER suddenly started
working. I hope fixing resolv.conf will solve all the issues.

What I still don't know is why the resolver used the wrong DNS server,
however. Is this a linux DNS resolver issue or maybe FS udns lib issue?
Just curious...

So a very important point: have correct DNS resolving on FS box :)

Regards,
    Tamas

Michael Jerris írta:
> could be a lot of things, icmp failure?  Other side just not  
> responding, eventually we give up trying to reg over and over and if  
> you have it setup we send options pings to see when it wakes up.
>
> Mike
>
> On Dec 4, 2008, at 6:59 AM, Tamas wrote:
>
>   
>> Hi,
>>
>> I was looking for the strace and found that probably I was wrong with
>> the inference.
>>     
>>> From strace I see (now) that ipv4 try was OK, thus something else  
>>> might
>>>       
>> block the sip register packets.
>> Any idea?
>>
>> Regards,
>>    Tamas
>>
>> Tamas írta:
>>     
>>> Hello,
>>>
>>> My original issue was that after some time (unable to find a rule  
>>> when)
>>> registering gateway stopped suddenly working and went to status  
>>> DOWN and
>>> state was FAIL_WAIT.
>>> In the logs I saw that it was trying to register continuously, but  
>>> there
>>> were no REGISTER packet sent out anymore. Clients registering to this
>>> box were able to register, just it was not able to register to the
>>> upstream box (FreeSWITCH too). Registering scheme:
>>> clients--->FS local---(NAT)--->FS public
>>>
>>> When I've caught such a case again, I was stracing FS processes and
>>> found this:
>>> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2393, ...}) = 0
>>> futex(0x2ac3092ead94, 0x85 /* FUTEX_??? */, 1) = 1
>>> futex(0x2ac3092ead40, 0x81 /* FUTEX_??? */, 1) = 1
>>> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 34
>>> setsockopt(34, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
>>> connect(34, {sa_family=AF_INET, sin_port=htons(4242),
>>> sin_addr=inet_addr("82.45.148.209")}, 16) = 0
>>> getsockname(34, {sa_family=AF_INET, sin_port=htons(32824),
>>> sin_addr=inet_addr("192.168.1.38")}, [1451698946064]) = 0
>>> close(34)                               = 0
>>> socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 34
>>> connect(34, {sa_family=AF_INET6, sin6_port=htons(4242),
>>> inet_pton(AF_INET6, "2001:503:ba3e::2:30", &sin6_addr),  
>>> sin6_flowinfo=0,
>>> sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
>>> close(34)                               = 0
>>> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2393, ...}) = 0
>>> futex(0x2ac3092ead94, 0x85 /* FUTEX_??? */, 1) = 1
>>> futex(0x2ac3092ead40, 0x81 /* FUTEX_??? */, 1) = 1
>>>
>>> From this I guess, my issue relates to IPv6. That is right that the  
>>> box
>>> has IPv6 address on the eth interface (ubuntu default), but this has
>>> worked for some days or some hours (varies) without this issue. So
>>> something might happen for which FS suddenly started using the IPv6
>>> interface address (which is not configured well).
>>>
>>> I've found tha given public IP (82.45.148.209) in  
>>> switch_find_local_ip
>>> function and have found that this is a root DNS server and the role  
>>> of
>>> this function is to find the local IP address. As I was looking for  
>>> the
>>> source, probably something sent wrong family to this function  
>>> (AF_INET6
>>> in place of AF_INET). Maybe this is a trivial issue for the  
>>> experts...
>>>
>>> I'm sure that if I remove the ipv6 things from my system it will be  
>>> OK,
>>> however I had similar issue on a box with no ipv6 address to. I'm not
>>> sure if it is the same/similar issue or not, but the symptoms looks
>>> similar. Unfortunately we had to restart that box (production) and  
>>> since
>>> that the problem disappeared (that was maybe fixed - the case  
>>> happened
>>> about 2 weeks ago).
>>>
>>> I think some users - mainly on test systems like I have - might  
>>> face to
>>> this issue so it might be worth to take a look, why had FS suddenly
>>> tried to send packets on ivp6. This could be a system issue too -
>>> something crazy with Xen or Ubuntu?
>>>
>>> Thanks in advance!
>>>
>>> Regards,
>>>    Tamas
>>>
>>> ps: FreeSwitch Version 1.0.trunk (10567M)
>>> Ubuntu Hoary (8.04) under Xen
>>>
>>>       
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>