Changing DNS server on WiFi connection is ignored by csipsimple

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Turn on wifi
2. Run csipsimple
3. Connect account

What is the expected output? What do you see instead?
Expected a successful connection, but the connection fails with a timeout error 
after a long wait.

What version of the product are you using? On what device / operating
system?
Android 4.2.2 on Samsung i9192 (Galaxy S4 mini) with lastest version of 
csipsimple from market

Please provide any additional information below.
On 3G connection csipsample uses external DNS server and external address of 
sip server, it works without any problem.

When connecting to wifi AP all programs detects DNS server change to local, but 
only csipsample continues to use the old DNS server from 3G connection and gets 
invalid sip server address that unaccessable from localnet.

Original issue reported on code.google.com by repairma...@gmail.com on 3 Dec 2013 at 8:00

[GoogleCodeExporter]

Hi,

Did you enable the DNS SRV option in csipsimple settings (in settings > 
network).

Depending on this setting the DNS resolution is made very differently by the 
app.

Also, normally, when network changes, the app should stop existing 
registrations and try to re-register. Is it the case for you? Does the 
csipsimple icon in notification bar disapears?

Original comment by r3gis...@gmail.com on 5 Dec 2013 at 7:13

• Changed state: Need-Details

[GoogleCodeExporter]

Hi,
Sorry for bad English. I do not speak English and use machine translation
from Russian.

No, its currently disabled.
I experimented with options. I created the SRV records on the local DNS
server (dnsmasq), try to include this option, but the same result. My
DNS/DHCP server has long served local network without problems.

Yes, accounts are restarted.
On wifi start in Android system settings I see local ip, local dns server,
etc received by dhcp.
Sip account on external service (sipnet.ru) restarted successfully and work
fine on wifi, but local account (to my local asterisk), that just worked
via 3G - failed to start on wifi. In csipsimple logs I see that connections
tryed to external ip of my server, not to local. Asterisk logs is empty, no
connections attempts is tryed.

From this I concluded that there is a problem with DNS resolving.

After many experiments, I realized that the problem was more global.
Neither party sip client did work with a local sip server on my andriod via
wifi. I tried csipsimple, linphone, sipdroid, etc. Only native android sip
client (SIPAUA) works without problems from both the outside world and from
the LAN. (I disabled SIPAUA during experiments with csipsimple  that it
does not create conflicts.)

Same problem occures with LG G2 (andriod 4.2.2), which does not have native
sip client, but problem NOT occured with Galaxy S Plus (android 2.3), which
works with any sip client, from any net, without any problems .

Now I tend to think that the reason somewhere within the system. Then must
be massive complaints from owners android 4.2.2, but I do not see them.
My system is: GT-I9192, Android 4.2.2, firmware I9192XXUBMK4, kernel
3.4.0-1961802

Everything looks very strange, I ran out of assumptions about the cause of
what is happening.
I like your program, but after the change of the smartphone I can not use
it.

Original comment by repairma...@gmail.com on 6 Dec 2013 at 6:50

[GoogleCodeExporter]

Thanks a lot for the details !

So if DNS SRV is not enabled, the DNS resolution is made by android system 
itself. CSipSimple uses platform resolution. It's confirmed by the fact you 
have the same on some other apps. And it's probably not particular to SIP 
actually. It's possible that on the ROM of this device there is a bug : just 
after network changes, the internal android system does not resolve properly 
DNS names.

What you can try is to enable DNS SRV option. This way, CSipSimple will do the 
DNS resolution by itself instead of relying on the Android OS. If the problem 
is only internal and the DNS servers settings are correctly immediately updated 
by this device, it should do the trick.

Can you test and tell me how it goes with DNS SRV option enabled?

Thanks !

Original comment by r3gis...@gmail.com on 6 Dec 2013 at 9:39

[GoogleCodeExporter]

Strangeness that other applications (web browser, email client, xmpp
client, etc.) get the correct address of the local server in wifi
connection. The problem somehow relates only to sip clients.

Returns "Service Unavailable" after 2-3 secs of waiting.

My android xmpp client (xabber) also uses the SRV record from same DNS
server, jabberd2 (xmpp server) running on same server as a asterisk, but
xabber works fine - instant smooth connection, csipsimple is not.

Asterisk runs on 10.0.2.251 5060/UDP
nslookup output from local machine:
---

Server: 10.0.2.251
Address: 10.0.2.251#53

_sip._udp.xxxxx.xx service = 0 0 5060 mx.xxxxx.xx.

Server: 10.0.2.251
Address: 10.0.2.251#53

Name: mx.xxxxx.xx
Address: 10.0.2.251

Original comment by repairma...@gmail.com on 6 Dec 2013 at 10:15

[GoogleCodeExporter]

csipsimple log for "Service Unavailable" with SRV enabled is attached.

Alarming phrases: *Failed to resolve 'delfos.ru <http://delfos.ru>'.
Err=320046 (No working DNS nameserver (PJLIB_UTIL_EDNSNOWORKINGNS))*

2013/12/6 Dmitry Hide <repairmansan@gmail.com>

Original comment by repairma...@gmail.com on 6 Dec 2013 at 11:20

[GoogleCodeExporter]

I looked at the tcpdump (sniffer) log running on DNS server, and saw an
unexpected thing - from the device absolutely No packets to the DNS server
while csipsimple is connecting.
That is, either all outgoing DNS packets are blocked inside android or
packets go somewhere else, but not to the DNS server.

I would be glad if my information will help cure the problem.

2013/12/6 Dmitry Hide <repairmansan@gmail.com>

Original comment by repairma...@gmail.com on 6 Dec 2013 at 11:25

[GoogleCodeExporter]

Ok, the "No working DNS nameserver (PJLIB_UTIL_EDNSNOWORKINGNS)" indicates the 
DNS server given by android system at the moment network change notification is 
sent by android system is probably something invalid. And as consequence, no 
DNS request packet is sent by the app.
Maybe a problem with synchronization of android system on this device : when 
they send the fact network changed, the DNS SRV is not yet internally set up in 
android database. Could be only few milliseconds, but those will make a 
difference for the sip app that will immediately try to re-register without 
waiting (maybe stock android client wait a little bit before re-registering or 
they get better internal notification of the android system to restart when dns 
value is finally changed).

To test if this assumption is true, can you try the following :
 - Reproduce the problem.
 - Go in csipsimple dialer, and then go in settings and press back.
This will restart the sip stack (exactly the same way it does when it receive a 
network change event from android system). If it register using the good dns 
server this time, it means that the problem is with timing when network change 
event from android system arrives.

Original comment by r3gis...@gmail.com on 7 Dec 2013 at 2:05

[GoogleCodeExporter]

Returns "Service Unavaliable".

I found the cause of the error .
csipsimple (Android?) for reasons unknown to me sends DNS requests to
default router (internet gateway), but device, DNS server and sip server
are on the same local /24 network , and default router must NOT be used .
In same LAN always used direct connections between computers. Gateway is
forbidden to make local loops.

Next tcpdump output taken from the Internet gateway (10.0.2.254).
10.0.2.213 - android ip
10.0.2.251 - local dns, local sip server ip

Router prohibited route 10.0.2.0/24 -> 10.0.2.0/24 as meaningless and, of
course, DNS server does not receive requests.
---------
$ sudo tcpdump -i eth1 host 10.0.2.213
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
08:41:27.114210 IP 10.0.2.213.39577 > 10.0.2.251.domain: 1+ SRV? _sip._
udp.delfos.ru. (37)
08:41:29.160829 IP 10.0.2.213.39577 > 10.0.2.251.domain: 1+ SRV? _sip._
udp.delfos.ru. (37)
08:41:31.216319 IP 10.0.2.213.39577 > 10.0.2.251.domain: 1+ SRV? _sip._
udp.delfos.ru. (37)
08:41:33.199751 IP 10.0.2.213.39577 > 10.0.2.251.domain: 1+ SRV? _sip._
udp.delfos.ru. (37)
08:41:35.226500 IP 10.0.2.213.39577 > 10.0.2.251.domain: 1+ SRV? _sip._
udp.delfos.ru. (37)
08:41:37.251575 IP 10.0.2.213.39577 > 10.0.2.251.domain: 2+ A? delfos.ru.
(27)
08:41:39.298468 IP 10.0.2.213.39577 > 10.0.2.251.domain: 2+ A? delfos.ru.
(27)

Original comment by repairma...@gmail.com on 9 Dec 2013 at 6:08

[GoogleCodeExporter]

Once again summarize what is happening:

csipsimple works correctly, except for one configuration when the DNS
server is on the same local network as the Android device.

Running the program simultaneously or separately with wifi, restart,
manually, automatic etc. - Do not bring any result.

The reason is that the DNS requests go to the default gateway, despite the
fact that the device and the DNS server are in the same / 24 network.

2013/12/9 Dmitry Hide <repairmansan@gmail.com>

Original comment by repairma...@gmail.com on 9 Dec 2013 at 6:23

[GoogleCodeExporter]

Thanks a lot for your investigations.
The IP packet routing is not made by csipsimple, but by the OS. So it tends to 
confirms the fact the problem is with the android system ROM.
If you have adb usb debugger tool installed on your pc and able to connect your 
device using adb, I would advise to run following command on the android device 
(run adb shell on your pc to connect the android device shell)

cat /proc/net/route

Maybe "cat /proc/net/arp" will also be instructive.

Original comment by r3gis...@gmail.com on 9 Dec 2013 at 9:49

[GoogleCodeExporter]

An interesting fact is that the xmpp client ( like the rest of the software
) has no problems with DNS resolution on the same device, at same time, in
the same environment.

IMHO, this DNS error on this version of Android is present for your
specific implementation of the resolver . (resolver.c?)
I am 100 % sure that your code can lead to a working state , but, sorry I
can not help you, I'm not so strong in C .
Whether there was a change API, whether changed system defaults ... is a
question for programmers .

Mystery is why others experienced by me sip clients had the same problem
... I assume that, possible, in all of these OpenSource projects used same
resolver source code .

Luckily my configuration is not typical for Android users , but I think
with the increase in the share 4.x Android will still complain about this
problem. At this point, at least two different devices from different
famous manufacturers have this problem (Samsung Galaxy S4 mini and LG G2
D802).

If changes need to be tested - I'm ready to help you... but, sorry, I have
no experience debugging android devices.

Original comment by repairma...@gmail.com on 9 Dec 2013 at 10:40

[GoogleCodeExporter]

Oh. I was find terminal emulator for android. :-)

Router table:

Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT

wlan0 00000000 FE02000A 0003 0 0 0 00000000 0 0 0

wlan0 00000000 FE02000A 0003 0 0 331 00000000 0 0 0

wlan0 0002000A 00000000 0001 0 0 331 00FFFFFF 0 0 0

wlan0 FB02000A FE02000A 0007 0 0 0 FFFFFFFF 0 0 0

wlan0 FE02000A 00000000 0005 0 0 0 FFFFFFFF 0 0 0

arp table:

IP address       HW type     Flags       HW address            Mask
Device
10.0.2.254       0x1         0x2         00:03:b3:04:2a:95     *
 wlan0

2013/12/9 Dmitry Hide <repairmansan@gmail.com>

Original comment by repairma...@gmail.com on 9 Dec 2013 at 11:06

[GoogleCodeExporter]

Yes, its line defines route to host 10.0.2.251 via 10.0.2.254...

2013/12/9 Dmitry Hide <repairmansan@gmail.com>

Original comment by repairma...@gmail.com on 9 Dec 2013 at 11:32

[GoogleCodeExporter]

Yes, its line defines route to host 10.0.2.251 via 10.0.2.254...

wlan0 FB02000A FE02000A 0007 0 0 0 FFFFFFFF 0 0 0

But I can't find where declared this route... Other hosts in my net haven't
this route.

2013/12/9 Dmitry Hide <repairmansan@gmail.com>

Original comment by repairma...@gmail.com on 9 Dec 2013 at 11:34

[GoogleCodeExporter]

Yes it's very strange.
I suspect something in the android ROM that does something special with the DNS 
ip.

It's also very strange that the xmpp client is able to reach directly your 
local dns server. Normally the system route applies to any application using 
network; and actually I even do not know how it would be possible to use 
different routing than the ones defined in system.

Just as quick sum up of how things goes in csipsimple/pjsip :
When DNS SRV is used, the application basically request the posix socket api to 
open a connection to the ip of the dns server and then it's sytem that decide 
the route to use.
When DNS SRV is not used, it's even more the system that does anything since 
the application request to open the socket directly to the hostname you defined 
and so it's up to system to do the name resolution (and apparently it 
internally ends with the same conclusion than csipsimple internal dns resolver).

If we except the fact xmpp app magically get ride of the linux routing table; 
my conclusion is that the root cause problem is this additional routing rule 
that asks to use the gateway to reach your DNS.
I've no idea why this rule could have been added. AFAIK android has no setting 
to add manually new routes for a single host. Maybe the ROM does something 
special or has a bug. 
Else, maybe could be something sent as reply by the DHCP server (using 
dhcp-option) or something added by another app that have root permissions or a 
remaining thing from a previous VPN connection.

Anyway, maybe you could workaround that on your router configuration by 
allowing routing from your 10.0.2.x network to 10.0.2.251 host (or to entiere 
network). I admit it's very strange to add such rule, but well.. if the android 
system decide to use this kind of route rule to reach the dns... And BTW, will 
probably solve a lot of problems for other apps.

Original comment by r3gis...@gmail.com on 9 Dec 2013 at 1:35

[GoogleCodeExporter]

Not only xmpp client works. Web browser works with local web server, mail
client works with local mail server.
I understand that with this route is nothing that requires a DNS server is
not working properly ... but it works.

Why xabber (xmpp client) works with my configuration possible would be able
to see in xabber sources:
https://github.com/redsolution/xabber-android

Well, if "right" solution does not exist, it is necessary to rebuild the
entire system. I hope that eventually the bug will be fixed.
Thanks for your time.

Original comment by repairma...@gmail.com on 10 Dec 2013 at 5:49

[GoogleCodeExporter]

Well, allowing routing 10.0.2.0/24 -> 10.0.2.0/24 on internet gateway is
solve problem with both variants of connection, via SRV and without.
Good that I am an administrator of my network and I can make any changes on
the servers. In foreign networks, this method will not work.

Thank you.

2013/12/10 Dmitry Hide <repairmansan@gmail.com>

Original comment by repairma...@gmail.com on 10 Dec 2013 at 7:58