Local discovery not working on android 11

[Wank]

@imsodin

Local discovery works for them with an android 12 device, which is unexpected. That’s just how it is with android: Lots of varying behaviour between vendors and even devices,

@imsodin

I have a Sumbsung S21 running Android 13, and as far as I can tell, local discovery is working. It also works on my Amazon Kindle.

I have Global discovery disabled on both devices, yet they seem to find one another.

I have more testing to do. I want to be sure that mine works. If I disable Global everywhere, I should find out soon enough.

I also intend to play with the battery care settings because Samsung can hinder applications that are under their battery management.

My goal is see if I can test enough to prove that Local either does or does not work on my specific devices.

[opusforlife2]

Thanks for confirming, guys. It indeed seemed like no one was addressing the discrepancy I pointed out.

I can completely understand not wanting to delve into the intricacies of different devices, but now that it’s being addressed, let me add to the MAC randomisation point, just in case it helps narrow down the issue.

There’s this app, Meshenger, available on F-Droid, that is primarily intended for LAN-only VoIP calls. On my newer device, MAC randomisation causes the app to ‘forget’ its local address. It requires going into the app’s settings, and selecting the new MAC address, for calls to work.

This isn’t true for the legacy device. Its MAC address is fixed, so it’s always discoverable without any user intervention.

This seems to parallel Syncthing’s behaviour so closely, that I can’t help but think they’re connected.

[adgrant93]

Not sure if this has already been addressed but I fixed this issue via the following.

On Android Device go to syncthing > web GUI > edit > manually add tcp://IP:22000 with IP being the device you want to sync to. It should obviously find it by itself locally. But this is a decent work around.

[gadget]

@opusforlife2

Thanks for confirming, guys. It indeed seemed like no one was addressing the discrepancy I pointed out.

I can completely understand not wanting to delve into the intricacies of different devices, but now that it’s being addressed, let me add to the MAC randomisation point, just in case it helps narrow down the issue.

Have you tried turning off MAC randomization to see if it makes a difference?

It’s simply a toggle setting under the Wi-Fi preferences for each configured wireless network under the “Privacy” section.

Every hardware network interface has a factory assigned MAC that usually cannot be changed by end users. However, many hardware manufacturers and network device drivers support MAC spoofing.

There’s this app, Meshenger, available on F-Droid, that is primarily intended for LAN-only VoIP calls. On my newer device, MAC randomisation causes the app to ‘forget’ its local address. It requires going into the app’s settings, and selecting the new MAC address, for calls to work.

The problem described above can also be caused by the router. In the most common type of setup the DHCP server in the router grabs an available IP address from its IP address pool and associates it with the MAC address sent by the client device (it’s how the DHCP server knows when an IP address is available again).

For Meshenger, I suspect the app keeps track of which network interface to use via the MAC address rather than use the system device interface name.

For Syncthing, by default it listens on all available network interfaces so it doesn’t matter if the MAC addresses change.

This isn’t true for the legacy device. Its MAC address is fixed, so it’s always discoverable without any user intervention.

This seems to parallel Syncthing’s behaviour so closely, that I can’t help but think they’re connected.

Android doesn’t change MAC addresses on a fixed timer or during an active Wi-Fi connection. Before Android 12, a random MAC is generated just once per Wi-Fi network (the trigger is based on the SSID and other factors). Starting with Android 12 a new MAC can be regenerated for an existing network but only under specific conditions.

[opusforlife2]

Welp. That didn’t work. So that line of investigation is a bust. Thanks for the help!

I did have randomisation set to occur on every connect in dev options, so it would have been far more frequent.

[gadget]

@opusforlife2

Welp. That didn’t work. So that line of investigation is a bust. Thanks for the help!

You’re welcome.

I did have randomisation set to occur on every connect in dev options, so it would have been far more frequent.

Even with that particular developer setting, the DHCP lease has to have expired or the phone has been disconnected from a given network for at least 24 hours before a new pseudo-random MAC is generated (it’s actually not completely random).

Otherwise there’s a chance the pool of IP addresses managed by a router’s DHCP server could be exhausted. Your phone disconnects when going to sleep. If the previous DHCP lease hasn’t expired its IP address will be unavailable. So when your phone reconnects, a new lease for a different IP address will be issued for your new MAC address. With enough reconnects and users all randomizing MAC addresses, the router could end up leasing out all its IP addresses before any expires.