Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

Sergi030
Copy link

@Sergi030 Sergi030 commented May 8, 2021

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

…piplay checks gets the mac address of the passed interface, this solve the bug that multiple instances of rpiplay cannot be lauch on the same network address
@Sergi030
Copy link
Author

Sergi030 commented May 8, 2021

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
Copy link
Author

Sergi030 commented May 8, 2021

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

@Sergi030 Sergi030 changed the title Adding optional argv to pass the name of network interface, now the r… Fix: Cannot run rpiplay on multiple computers of the same network or pc May 8, 2021
@yousukeayada
Copy link

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.

@fduncanh
Copy link

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
Copy link
Author

I pulled the lastest version 35dd995 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
Copy link

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
Copy link

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
Copy link
Author

Sergi030 commented Jul 5, 2021

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.

image

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

@fduncanh
Copy link

This may be a cleaner way to generate a random hw_addr
(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;
}

…ayada proposed (I cannot test it as I don't have any macOS device. I believe in the code proposed by yousukeayada works :D)
@Sergi030
Copy link
Author

Sergi030 commented Sep 4, 2021

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

memcpy(name, dl->sdl_data, dl->sdl_nlen);
name[dl->sdl_nlen] = '\0';
addr = (unsigned char*)LLADDR(dl);
if(strcmp(name, interface) == 0) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a space after the if

#endif

std::string find_mac() {

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove the empty line here

int octet;
for (int i = 0; i < hw_addr.size(); i++) {
if (i == 0) {
octet = rand()%64;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add spaces around the modulo operator

octet = (octet << 1) + LOCAL;
octet = (octet << 1) + MULTICAST;
} else {
octet = rand()%256;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

} else {
octet = rand()%256;
}
hw_addr.at(i) = (char) octet ;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove the space before the semicolon

@FD-
Copy link
Owner

FD- commented Nov 6, 2021

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

@FD-
Copy link
Owner

FD- commented Nov 6, 2021

Also, please improve your formatting

@fduncanh
Copy link

fduncanh commented Nov 6, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants