LAN netplay does not work with more than two players

[JesseTG]

What version of melonDS DS are you using?

Commit a3c57f0

Does the problem happen in standalone melonDS?

No, it's a bug specific to melonDS DS.

What happened?

As previously discussed here and on Discord, the LAN netplay functionality introduced in #242 does not support more than two players. This is very likely due to multiple clients receiving the same MAC address through similar firmware images or the generated firmware.

At the moment melonDS DS has no way to configure the MAC address, so whatever's in the firmware will be used as-is. The end result is this strange issue that @BernardoGomesNegri described on Discord:

I was trying to implement multiplayer in libretro but the clients keep assigning each other the same aid, and I was wondering if maybe the issue was related to where packets were sent

The cause, suggested by @Arisotura:

do you have some form of MAC randomization going on?
if all players have the same MAC it will definitely cause issues

(The answer here is "no".)

MAC generation has a couple of constraints:

• Netplay sessions can be started in the middle of an offline session without restarting the game, therefore a MAC must be generated before the emulated console starts. You can't change it in the middle of a game, that could cause all sorts of crazy shit to happen.
• MAC addresses should be stable, otherwise games that use it to validate save data (e.g. Pokemon) will raise errors or block certain features. Therefore, the emulated console's MAC address should not change between sessions (unless the player wants it to).
• Standalone melonDS generates MAC addresses by tweaking the firmware's address based on each client's instance ID, but that means the MAC can change depending on the order in which players join a game. Not only will that cause non-obvious confusing behavior, it may be the cause of a few bugs upstream. Therefore, we can't use the exact same solution that standalone melonDS does.
• MAC addresses could be generated based on device info, but then players who sync their RetroArch save data between multiple devices would only be able to reliably play games on one of them. Therefore, the generated MAC must not rely on the device.
• Libretro does not provide a way for players to enter arbitrary strings as core option values. Although we can read MAC addresses from a file at runtime and list them in the core options, this won't solve the aforementioned problems. Therefore, the player must be able to configure their emulated MAC address by selecting from a finite set of choices.

What should've happened instead?

A solution to this problem would entail generating a unique MAC address for each client, and I can think of a simple solution for that:

Use the username returned from retro::username() as the basis of the MAC generation. Usernames are unlikely to change often, are likely to be the same across a player's devices, and are easy to change in RetroArch. As long as the algorithm used to generate the MAC is reliable, this should work regardless of device and join order.

The existing behavior of reading the MAC from the firmware image should still be possible, though. I think it should still be the default, though I'm open to being persuaded otherwise.

Oh, but don't forget to warn the player if their username isn't set! There's only one possible empty string, so if multiple players in a session neglect to set a username then we'll be back to this problem.

Which platforms do you see the problem on?

• Windows
• macOS
• Linux
• Android
• iOS
• tvOS
• Other (specify below)

Which versions of the OS?

N/A

Which libretro frontend are you using?

RetroArch 1.19

Terms

• I agree to follow the code of conduct.
• I understand that melonDS DS is not developed or maintained by the authors of melonDS.
• I understand that this form is for reporting bugs, not for requesting help.
• I understand that the author develops this core in his spare time, and that he is under no obligation to respond to this bug report.

[BernardoGomesNegri]

I've confirmed that generating random MAC addresses fixes the issue and allows more than 2 players to join a multiplayer session.

[JesseTG]

I've confirmed that generating random MAC addresses fixes the issue and allows more than 2 players to join a multiplayer session.

That's awesome! Can't wait to see what you come up with when you're ready.