Networking for sync -- sync two Pi with no router

[ghost]

Hello! Just spent a couple of days working with the sync system, and thank you very much. It is working and seems to be robust.

The current instructions worked very well - using a RPi2 and the most current version of Raspbian (from the end of 2016).

One question that came up was how to link two RPis with no router between them; as you have them in the demo video on vimeo.

In the current version of Raspbian (Jessie) the prefered way to set up a static IP address is using the /etc/dhcpcd.conf file.... (as opposed to the old way : using of the interfaces file - which did not work at all for me).

Sadly, when I used the dhcpcd.conf method, to set each RPi to a static IP - the master would start but the slave RPi never saw the sync commands. I'm guessing it has something to do with the broadcasting gateway not being set correctly... but I'm not sure.

I did find a work around - which was to set both the master and the slave to the SAME IP. Thus the system worked like a champ. (but it scares me some :0 )

But what would be the correct way to deal with this?

I would like to sync two RPis with a single ethernet cable - any thoughts?

again great work and thanks

[magdesign]

Its not really an omxplayer-sync related issue. Disable dhcp and set your IPs static. Check this out: https://ch.mathworks.com/help/supportpkg/raspberrypi/ug/getting-the-raspberry_pi-ip-address.html The two Pi's must be in the same subnet, but not have the same IP.

Also check out the official RaspberryPi forums.

[ghost]

Yeah- that method of setting static IPs does not seem to be working any more... thus the question...

but thanks.... it kinda seemed like a "use case"..

all the best

[barlaensdoonn]

I think now the recommended method is to leave /etc/network/interfaces alone and modify /etc/dhcpcd.conf instead

there is an example in the man pages for dhcpcd.conf. Look for the static parameter

for instance the bottom of my conf file looks like this:

[ghost]

@barlaensdoonn

Yes that is exactly what I did in the end.... and it did work but only if the eth0 static IP was the same on both the Master and the Slave (again this is without a router - no 192.168.1.1)

it seemed so "iffy" to do that....

im no expert but it looks currently the script is using 0.0.0.0 for the undefined route but the slave not having an assigned gateway is not picking up the route there seems no way to have a default gateway unless I run a DHCP server (?)

just trying to learn thanks again

[turingmachine]

@magdesign is right, this no problem with omxplayer-sync per se, but rather a lack of understanding of basic TCP/IP networking principles. But one could also argue that if a questions like this pops up, it's a sign of lack of documentation. So will try to clear some things up:

1. Network interfaces can be configured static or by DHCP, there is no difference from an operating system point of view. So both methods are interchangeable, if they both configure the same parameters. And yes you can define a default gateway without dhcp, but omxplayer-sync does not require a gateway to work as long as master and slave devices are in the same subnet.
2. There is no such thing as a brodcasting gateway, gateways can be used to forward brodcast, but there is no special brodacast gateway.
3. There is no such thing undefined route (well you could argue that an undefined route is one that is simply not there...), what you mean is most probably a default route (0.0.0.0).
4. omxplayer-sync uses brodcast to communicate with slaves. By default it uses the address 255.255.255.255, which will result in a limited broadcast. This default value will work in most cases, e.g. when there is only one network interface configured on the Pi. Because of the nature of this address, the operating system can not determine which interface to choose for sending a packet out if there are more than one interface configured. In this case the operating will choose one of the available interfaces and the choice is not always obvious.
5. If you have multiple interface configured and want to control over which interface the packets should leave, you could use a directed broadcast address instead. By passing the -x command line parameter to omxplayer-sync, you could for example supply 192.168.1.255. This way the operating system would know which interface to use. But only if the system is not misconfigured, Which brings us to point 5...
6. For client type of machine it usually never makes sense to configure the same subnet on multiple interfaces, because the decision which interface to use is based on the subnet part of the interface address. Much worse, I see you used the same IP address on both interfaces. This is a proven recipe for all kinds of problems.

Use either wired or wlan, if you want to have both interfaces activated for whatever reason, (e.g. wlan for internet access and wired for sync), configure a different subnet for each interface.

Make yourself familiar with the basic of TCP/IP networking on linux. These topics are essential:

arp mac address ip address netmask brodacast address gateway directed brodcast limited broadcast routing table

[ghost]

Thanks again -- good explanation...

Sadly this makes me think it's a problem with the current (dec/jan 2016) raspibian disto

I set up only the eth0 on the master and slave (no wifi) first using the interfaces file (that did not work at all - hangs nothing played and "no network connection") and then I reverted back to the original state (all this work was done on fresh images) then tried the dhcpcd.conf file to set up the static IPs and that worked at least for playback of the master the slave just sat waiting

and as I said the master / slave only worked in the one case of both having the same IP ( I spent a day trying most every configuration I could think of )

I will look into it further on my own...

peace!

[ghost]

for future generations: the problem I had was not the network it was that the files did not have the --->>> same name...

while the instructions said they need to have the same name (yes I know) I was using the /home/pi/Videos/* for the file making me think that it was using any file name... but no

the use of the identical ip address was working by "accident" only