Android can't find TrueNAS (and vice versa)

Hey :slight_smile:

A week ago I reinstalled the Syncthing Plugin on my TrueNAS and configured my previous setup. I got a TrueNAS, Android phone, Windows and Linux machine. They all are able to discover each other, except TrueNAS and Android. Before the reinstallation they could see each other without a problem.

I tried to remove the Android Device from TrueNAS and TrueNAS from Android and readd them. The logs do not show any information about them.

This is the log of the TrueNAS after I did restart it and added the Android device (cut up links, because of new-user-restrictions):

2021-06-20 03:32:08 Single thread SHA256 performance is 528 MB/s using minio/sha256-simd (458 MB/s using crypto/sha256).
2021-06-20 03:32:08 Hashing performance is 439.81 MB/s
2021-06-20 03:32:08 Overall send rate is unlimited, receive rate is unlimited
2021-06-20 03:32:08 Relay listener (dynamic+https ://relays. syncthing. net/endpoint) starting
2021-06-20 03:32:08 Using discovery mechanism: global discovery server https://discovery. syncthing. net/v2/?noannounce&id=AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA
2021-06-20 03:32:08 QUIC listener ([::]:22000) starting
2021-06-20 03:32:08 Using discovery mechanism: global discovery server https: //discovery. syncthing. net/v2/?nolookup&id=AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA
2021-06-20 03:32:08 Using discovery mechanism: global discovery server https: //discovery. syncthing. net/v2/?nolookup&id=AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA-AAAAAAA
2021-06-20 03:32:08 TCP listener ([::]:22000) starting
2021-06-20 03:32:08 ...
2021-06-20 03:32:08 Using discovery mechanism: IPv4 local broadcast discovery on port 21027
2021-06-20 03:32:08 Using discovery mechanism: IPv6 local multicast discovery on address [XXXX::XXXX]:21027
2021-06-20 03:32:08 Ready to synchronize "SHARED-DIR-ONE" (aaaaa-aaaaa) (sendreceive)
2021-06-20 03:32:08 Ready to synchronize "SHARED-DIR-TWO" (bbbbb-bbbbb) (sendreceive)
2021-06-20 03:32:08 GUI and API listening on
2021-06-20 03:32:08 Access the GUI via the following URL: http: //127 .0 .0. 1:8384/
2021-06-20 03:32:08 My name is "HOSTNAME"
2021-06-20 03:32:08 Completed initial scan of sendreceive folder "SHARED-DIR-ONE" (aaaaa-aaaaa)
2021-06-20 03:32:08 Completed initial scan of sendreceive folder "SHARED-DIR-TWO" (bbbbb-bbbbb)
2021-06-20 03:32:08 Established secure connection to ZZZZZZZ-ZZZZZZZ-ZZZZZZZ-ZZZZZZZ-ZZZZZZZ-ZZZZZZZ-ZZZZZZZ-ZZZZZZZ at 172. 16. 0. 2:22000-ZZZ. ZZZ. ZZZ. ZZZ: 22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256
2021-06-20 03:32:08 Device YYYYYYY-YYYYYYY-YYYYYYY-YYYYYYY-YYYYYYY-YYYYYYY-YYYYYYY-YYYYYYY client is "syncthing v1.17.0" named "HOSTNAME-WINDOWS" at 172. 16. 0 .2 :22000-ZZZ.ZZZ.ZZZ.ZZZ:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256
2021-06-20 03:32:18 quic://0 . 0. 0. 0:22000 detected NAT type: Symmetric NAT
2021-06-20 03:32:18 Detected 1 NAT service
2021-06-20 03:32:43 Joined relay relay: //BBB .BBB .BBB .BBB:22067

Syncthing Versions:

Android v1.17.0(-dirty)

TrueNAS v1.15.1

A screenshot from the GUI (does look the same on both devices): gui

Has anyone an idea what the problem could be?

Do you have discovery disabled? Or you might have logs with errors trying to reach discovery servers, as it hasn’t found any addresses for the other device.

All my devices have default connection settings, so ‘Enable NAT traversal’, ‘Local Discovery’, ‘Global Discovery’ and ‘Enable Relaying’ are enabled.

Are there any additional logs other than the one in the GUI? I didn’t specify any other locations and the log should output to stdout.

NEWS! Just discovered myselfe how to open ‘Discovery Failures’.

From TrueNAS:

From Android:

@AudriusButkevicius two different topics about timeouts of the global discovery server. Just coincidence?

1 Like

Both on some funky NAS.

If discovery didn’t work, I’d expect more people at our doors.

1 Like

Discovery shouldn’t be the problem, as all devices are discoverable by some other. I disabled ‘Global Discovery’ on all devices and they behave as before.

Windows <—> Android

Windows <—> TrueNAS

Android <-/-> TrueNAS

Is there any way to get more debugging information that might narrow down to the cause?

And the funky NAS just creates a FreeBSD jail configured with VNET, NAT and ‘NAT Port forwarding’, if that information helps.

This just means that your systems does not have IPv6 connectivity, no problem as long as IPv4 is working.

Your Android can’t reach any discovery server. This is a problem. This only leaves local discovery as an option, but that is known to be problematic on Android (due to system restrictions).

1 Like

@Nummer378 thanks a lot for those informations. I reinstalled Syncthing on my Android phone (maybe a restart of the phone would have done the same). Now there is a 5/5 at ‘Discovery’ and it does connect to TrueNAS! Weirdly it seems like it’s enough when ‘Global Discovery’ is enabled only on the TrueNAS. But maybe that makes more sense to someone with knowledge about the backend.

Is there any current discussion about how the discovery status is displayed? It’s a bit confusing for me, if 4/5 means e.g. four out of five steps to a ‘perfect’ connection. For someone who has zero knowledge of the discovery process, 3/5 may seem like ‘good enough’.

Perhabs it would be helpfull if 3/5 is colored red and 4/5 is also colored green. If 3/5 means that discovery is not functional and 4/5 is functional for ipv4, which is sufficient.

EDIT: I know a failed ipv6 connection can have a lot of causes and maybe desired, in which case green is also misleading.

3/5 says that 3 out of 5 methods are working.

You can’t judge based on that if a connection is possible or not, so there is no way to colour them sensibly I think.

Even 0/5 might be ok if you have static addresses for devices configured.

1 Like

Ah, I see. Thank you for the quick explenation.

I still think the current presentation of this status can be confusing, also the hidden error messages behind the ‘invisible’ x/5 button.

But that’s obviously a more complex topic for it’s own issue.

I think that’s not particularly complex: Those are links, but not styled as links (except on hover) - that’s bad and should be changed (like e.g. the device ID).

Yes, that could be a solution. But only a different style doesn’t necessarily show that it links to an error or does fit with sourrounding layout. My second thought was to show an error icon (e.g. red triangle with exclamation mark in it) next to the x/5, which can be clicked.

Also the discovery status could be split up somehow (different icons/descriptions for different connection methods). Which may help or may confuse more. Maybe categorizing the (now) hidden errors helps new user better.

That’s why I said it seems more complex and could benefit from more input of different users, to find a long lasting solution.

1 Like

Sure, I didn’t want to imply that UX in general is simple, just that the bad discoverability of these errors has one, obvious and simple to correct cause - there might be and likely are more problems/possible improvements :slight_smile:
Fixed in gui: Make listener/discovery modal more discoverable by imsodin · Pull Request #7780 · syncthing/syncthing · GitHub


True! A distinct style will definitely help a lot.

Thanks for this fast fix :slight_smile:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.