Fix: Cannot run rpiplay on multiple computers of the same network or pc

[Sergi030]

rpiplay checks gets the mac address of the past interface, this solves the bug that multiple instances of rpiplay cannot be launch on the same network address

[Sergi030]

I recreate the pr cuz last time I set the master branch of my fork now is a separate branch.

Original pr: https://github.com/FD-/RPiPlay/pull/230

[Sergi030]

I added an option called --randomMac that allows you to run more than one rpiplay instances on the same pc.

With this option a random mac will be calculated, and also it generates a random name for the rpiplay instance ./rpiplay --randomMac

Also if you want to set a custom name just simply use the -n option with the --randomMac ./rpiplay --randomMac -n leftScreen

[yousukeayada]

I made the -i option enable to run on macOS. https://github.com/yousukeayada/ludimus

I referred to the following repository to build RPiPlay on macOS and to run it on multiple computers of the same network.

• https://github.com/Loxodromics/ludimus
• https://github.com/Sergi030/RPiPlay/tree/allow-multiple-instances-in-the-same-network

[fduncanh]

why do you say multiple instances of rpiplay cannot be launched on the same computer? I tested the unchanged rpiplay, and they can (two instances, two ipads mirrored), different options -n). They were using different ports. I got two gstreamer windows, both audios playing at the same time, but if one is screen mirroring without audio, that is not a problem.

I can see that if the actual mac address is somehow not found, it is not a good idea to have a hard-coded DEFAULT_HW_ADDRESS, and that should perhaps be randomly chosen, but that would be for different computers on the same network, both of which failed to find their true mac address. Please explain.

[Sergi030]

I pulled the lastest version 35dd995fceed29183cbfad0d4110ae48e0635786 and I can reproduce the problem.

I'm using rpiplay on a pc with ArchLinux when I launch the rpiplay with an -n option my ipad is able to connect but when another instance on the same pc is launch with different -n option we can see in the ipad how the first server is renamed to second one.

Which env are you using?

[fduncanh]

I am on opensuse 15.3.
The performance with two instances running on the same server was not good, both had latency.

If the two ipads are not mirroring, only the latest server instance shows as available. But it one ipad is connected, and a second instance with a different name is then started the running first instance retains its name, and the second can be connected to with a different ipad,

I'm guessing this is a Bonjour server issue. and your change may be needed for both server choices to be offered simultaneously on the ipad..

[fduncanh]

you probably need to appropriately fix the second hex character modulo 4 in the random mac address. (unicast/multicast local/universal etc.)

see https://en.wikipedia.org/wiki/MAC_address

[Sergi030]

what you say about bonjour fits me.

Regarding the mac address...

You mean second digit means unicast/multicast universally/local, right? So for unicast universally should be 0, 4, 8 or C.

@fduncanh If you can confirm if this is what you are referring to.

[fduncanh]

_This may be a cleaner way to generate a random hwaddr (use it after call to srand)

#define MULTICAST 0
#define LOCAL 1
static int set_random_hw_addr(std::vector<char> &hw_addr) {
    int octet;
    for (int i = 0; i < hw_addr.size(); i++) {
        if (i == 0) {
            octet = rand()%64;
            octet = (octet << 1) + LOCAL;
            octet = (octet << 1) + MULTICAST;
        } else {
            octet =  rand()%256;
        }
        hw_addr.at(i) = (char) octet ;
    }
    return 0;
}

[Sergi030]

I made the changes proposed by @fduncanh and also added the macOS that @yousukeayada said.

[FD-]

Please clarify why -i is what allows to run multiple instance in the same network. That should be working already.

[FD-]

Also, please improve your formatting

[fduncanh]

I also fixed all these issues in UxPlay 1.3x. The issues are: (1) two different computers on the same network: some systems (both macOS and various exotic linux systems (as I discovered from user issues posted at the new UxPlay) fail to find the true hardware address with find_mac, and drop back to the SAME hard coded "default" mac address (cant have two identical mac addresses on same network). The default mac address should therefore be random, not hard coded. (2) Two instances of (RPi/Ux)Play on the same computer certainly need different mac address. (as well as server names) (3) Actually Apple has moved to only using random one-time MacAddresses because of "privacy" (tracking) issues when portable devices connect to public networks in shopping malls etc.

These is no need for a "-i" option when random mac is implemented. I have got UxPlay to build and run on macOS. The most useful things from the "ludimus" fork code were hints on how to get CMakeLists.txt adapted, and one small #ifdef in one of the raop* files. Otherwise no real changes were needed to build and work on MacOs using GStreamer.

The mac just fails to find the true hw_address and just uses the random one, when it is implemented.

My inclination would in fact be to reverse things, and actually make a random mac address the default, and include a Linux-specific option to look for the "real" one if that was needed.