The client is not contacting the global discovery server when using UMTS/3G/LTE

[ghost]

Hello,

I see a problem with the Global Discovery server: seems the mobile client is not contacting it using the mobile network.

It is not a network issue: if I share the mobile connection using tethering, or using the USB connection , the client on the PC can connect to the global discovery server. So it is not the ISP or the network preventing it. This worked both for Windows and Linux client connected using the same phone, just using tethering.

I also installed a discovery server (the one I found on related github) on my own server, and I took some pcap. It works perfectly using the windows client and the linux client, both from the ethernet network and the UMTS/3G/LTE network. I can see packets incoming in the pcap. It also works with the mobile client using wifi.

The client fails only when the mobile network is used: and I see no udp packets incoming on port 22026.

Seems the android client is not sending any udp packet on the mobile ppp connection.As I said, the ISP is not a problem, neither the network: just using tethering any client can work using the same network.

Logs are keeping empty, it just says 0/2 on "Announce Server". And no UDP packets are received.

I forgot: the version is: v.0.11.9, android version is 0.6.4

[AudriusButkevicius]

Android client uses the same syncthing binary, so it's more likely the environment rather than the client.
In the client you can set the debug options to discovery, and then post the log for us see what's happening.

Also, what does web ui show in terms of announcement server availability when connected via the cell tower?

[ghost]

Here it is

===============8X=============================
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:11.941477 main.go:468: INFO: syncthing v0.11.9 (go1.4.2 linux-arm android) [email protected] 2015-06-14 11:52:00 UTC
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:11.942362 main.go:469: INFO: My ID: LALALALLALALALALA
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:11.948709 main.go:740: INFO: Database block cache capacity 14538 KiB
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:12.101023 main.go:513: OK: Ready to synchronize camera (read only; no external updates accepted)
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:12.277963 main.go:513: OK: Ready to synchronize gipsy (read only; no external updates accepted)
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:12.338175 rofolder.go:90: INFO: Completed initial scan (ro) of folder camera
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:12.348337 rofolder.go:90: INFO: Completed initial scan (ro) of folder gipsy
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:12.735086 main.go:795: INFO: Starting web GUI on https://127.0.0.1:8384/
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:17.538614 main.go:871: INFO: Starting local discovery announcements
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:17.545328 discover.go:343: DEBUG: discover: Received local announcement from 10.166.157.35:59805 for LALALALALALA
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:17.546152 discover.go:343: DEBUG: discover: Received local announcement from 192.168.43.1:59805 for LALALALALALALA
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:17.546213 main.go:876: INFO: Starting global discovery announcements
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:17.546427 discover.go:148: INFO: Error creating discovery client udp4://192.168.2.52:22026 Unsupported scheme:
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:17.551309 client_udp.go:106: DEBUG: discover udp4://boseburo.ddns.net:22026: broadcast resolve: stat /etc/resolv.conf: no such file or directory; trying again in 1m0s
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:17.552408 main.go:513: INFO: Device LALALALALALA is "nomadic3g" at [dynamic]
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:17.553018 main.go:513: INFO: Device LALALALALA is "invernomouth" at [dynamic]
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:17.553537 main.go:513: INFO: Device LALALALALALALA is "AltPanzer" at [dynamic]
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:17.553873 main.go:513: INFO: No automatic upgrades; STNOUPGRADE environment variable defined.
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:17.604471 gui.go:164: INFO: API listening on 127.0.0.1:8384
I/SyncthingNativeCode( 9089): [JZL5T] 2015/06/25 15:17:27.558298 upnpsvc.go:46: INFO: No UPnP device detected

[AudriusButkevicius]

Right, the first one is probably extra spaces in front of the address, the second one is basically a Go bug (golang/go#10714) you have to use IPs until Go 1.5 is released.

[ghost]

About the unsupported schema,, seems it was a " " space into the string. Now I fixed it using the web GUI on the mobile phone, where it was evident.

But this IP address can work only when in WIFI. The other issue, cannot stat "/etc/resolv.conf" seems an issue.

[AudriusButkevicius]

As I've said, golang/go#10714 is the issue you are after, nothing todo with syncthing-android or syncthing.

[ghost]

I see. Actually you need resolv.conf to get a proper DNS ip address. Could it be a (non-mandatory) syncthing configuration item in the future? I cannot use the IP, i'm using a dynamic dns for that reason.... also to avoid problems with VPN and tunnels.

[AudriusButkevicius]

Configuration item configuring what?

It's a golang bug which you will have to wait until August to be fixed, once Go 1.5 comes out.

[ghost]

The reason(s) I ask is

1. Syncthing for android is using arm-compiled binaries, which are assuming to run on linux-arm. Android has no /etc/resolv.conf , neither it will. Linux-arm has.
2. Even using GetHostByName() , Android is not using glibc, is using Bionic, which is not Posix.

This is why I am not confident (like you seem) the 1.5 release will fix this issue for Android. Can you show an explicit statement from google this specific issue will be solved?

So having a field where to put the DNS could be a quicker solution.

Just my two cents, of course.

[AudriusButkevicius]

So the patch in question forces android devices to use cgo for dns lookups.
If you follow the code, and look at:
https://github.com/golang/go/blob/99f5f796d9e689befdd27f5563e28cd49dcc1567/src/net/cgo_unix.go#L100
it seems to use getaddrinfo which is provided by some C runtime at link time if we're using cgo.

I don't exactly know how binaries get linked for GOOS=android, but I guess it links against this bionic thing.

I doubt it very much that they rewrote half of the distribution to use something else than getaddrinfo, and most likely just patched that out to do what they want, as it's easier to maintain the way how one function behaves versus maintaining N tools that might make the call.

Now a quick googling around (not exactly trusting the source though) shows me this file:
http://code.metager.de/source/xref/android/4.0.4/bionic/libc/netbsd/net/getaddrinfo.c#736
which is getaddrinfo implementation for presumably bionic, which has this special proxy method call, which when you check what it does, it talks to /dev/socket/dnsproxyd, which is probably the way you resolve addresses on Android.

The /etc/resolv.conf error is not coming from libc, it's coming from netgo, the dns resolver implemented in go which assumes that the file is there.

But to be honest, if the standard library is broken for such basic things as DNS resolution for the company which maintains the platform that it's broken on... well, I guess we just have to be as ignorant as they are.

I don't think we should include a separate full blown dns library just to get around people wanting to use ddns on android.

[ghost]

Ok, now I see.

Thanks for the kind answer, I'll wait.

[AudriusButkevicius]

We can close this I think.