MultiSync: Hide/Disregard eth0 on Remotes when wlan0 is the Primary Address

[vegasdave2k]

To preface, I am using the wireless master/remote setup where a remote talks to the master on the main WiFi network of 192.168.10.X.  eth0 is only used to pass data to a controller on 192.168.X.1, and the controller address on that subnet is 192.168.X.50.

The MultiSync page sees both the 192.168.10.X and 192.168.X.1 addresses for each remote, and the ordering(priority?) of the two is indeterminate.  I have only checked "Unicast Sync" box for the 192.168.10.X addresses.  The issue is that MultiSync sees the 192.168.X.1 address first sometimes(see screenshot) and thus doesn't "match" a know address for remotes to "sync".  The only way to solve this is to continuously reboot the remote until the 192.168.10.X is the first shown address for it on the master.

Underneath, MultiSync still works for the 192.168.10.X remotes where the 192.168.X.1 address is displayed first.  This is because the 192.168.10.X is saved and is displayed in the "MultiSync Unicast Discovery IPs (CSV list)" text field.

The only "filtering" option in this case that would hide the 192.168.X.1 address is the "Hide 192.168.x.x/16 Subnets in systems list" option.  However, this hides the entire remote, even if the correct 192.168.10.X address is displayed first.

Is there a way we can have determinate ordering on the remote addresses?  Alternatively, is there something that could be added to ignore all network addresses for a given remote except for the one that resides on the same subnet as the master?

[pixelpuppy]

As a former network engineer, I find it a bit odd that FPP discovery reports all IP addresses instead of just the one that received (and responds) to the discovery request.  I'm hoping one of the developers can respond to your question with a little better understanding of why its done that way.

I don't think there is a clean way to filter that in the current versions of FPP.  However, you might be able to fudge it by putting your controllers on 10.x.x.x subnets instead of 192.168.x.x.  Then you could "Hide 10.x.x.x/8" subnets.  Disclaimer: I have not yet played with the "Hide...." feature so I'm just guessing at this point

[vegasdave2k]

Thanks for the reply.  This is causing an actual blocker issue now.  When you attempt to "Copy Files" using the MultiSync page, if it sees the 192.168.X.1 address first, it attempt to sync files to that address and stalls...

Syncing files to remote FPP system at 192.168.102.1
==================================================================================
Syncing sequences dir to 192.168.102.1
Command: rsync -rtDlv --modify-window=1 -z --stats /home/fpp/media/sequences/ 192.168.102.1::media/sequences/ 2>&1
rsync: failed to connect to 192.168.102.1 (192.168.102.1): Connection timed out (110)
rsync error: error in socket IO (code 10) at clientserver.c(127) [sender=3.1.3]

Nothing happens after that, so this is actually causing me an issue now.

[vegasdave2k]

My show went live yesterday, and there's now a major pain point with this bug.  The "Unicast Sync" doesn't work when 192.168.X.1 is the primary address.  Like at all.  Even adding the correct 192.168.10.X address to the CSV list for unicast doesn't send them sync packets either.

I've brute-forced this by multicasting to all remotes for now, but this bug really needs to be looked at.

For those wanting more info on the WiFi master-remote setup, it's been a thing for a long time.  See this pinned topic http://falconchristmas.com/forum/index.php/topic,4231.0/topicseen.html

[CaptainMurdoch]

I merged a change from master back to v4.5 which will let you select each IP individually so you can select the desired IP you want to receive the unicast packets.  I also have added some logic to the master branch to try to auto detect which IP to use to copy files so hopefully this issue is solved in master.

Having all IPs visible does have its advantages sometimes from a user perspective and there are a lot of users who use 192.x for WiFi and 10.x for wired or vice versa.  That makes it easier to exclude the remote inaccessible networks from the MultiSync UI using the 'Hide' checkboxes at the bottom.