Emulator Issues #12323
Wii network not fully emulated
Any game that's using Nintendo's DWC library, meaning, any game with online support. Tested with MKWii (RMCP01).
What's the problem? Describe what went wrong.
When a game initializes the DWC library, a network socket is created using a random port. This is NOT done by requesting a port of 0, as it is usually done on Unix, but instead the library itself has code to generate a random number between 49152 and 65535, and then opens this specific port. If this port is already in use, the initialization of the library (and thus the connection to the online servers) fails.
On a real Wii, that's not a problem - the currently running software (game) is the only software to run on the Wii and thus the only software which could ever be using ports, so the software can make sure not to use ports it's already using for other stuff.
On Dolphin, that's not necessarily the case. Depending on how many applications are currently running on the computer that might all be doing network connections, it becomes increasingly more likely that the random port the game picked is already in use by another application, forcing the user to try to connect to the online servers over and over again until the game randomly picks a port that's not yet in use by the operating system.
Sure, that's a pretty artificial problem by itself, and I actually noticed it while doing something different:
Usually, as described above, games will pick a random port. That's not really helpful if you want to add port forwardings to help with the connection, as you'd have to forward the whole 49152-65535 range to your Wii / Dolphin. To prevent that we added some code in our Wiimmfi update for MKWii that allows the user to manually pick a port to use on the Wiimmfi webpage.
A while later we've then received a bug report from a user who was running two instances of Dolphin on the same machine to test stuff, and he was unable to go online with the 2nd instance. Further investigation showed why that was the case, the two Dolphins were trying to use the same port (the port they were told to use by Wiimmfi), and that obviously didn't work.
An additional instance where we noticed the Wii network not fully being emulated by Dolphin would be the fact that MKWii on a Wii does not support SNI in SSL requests, while booting MKWii on Dolphin "magically" makes that work (because Dolphin doesn't emulate the Wii network code, instead it all hands these requests to the operating system / standard SSL libraries instead).
All this is not really an important problem for us / for Wiimmfi, we'll just add some update code to the game to make it retry with a different random port on error, until it gets a random port that is free to use. But because I was unable to find information about this behaviour elsewhere I just wanted to open this bug report so that this bug (or rather, emulation inaccuracy) is documented somewhere just in case it causes other trouble in the future.
What steps will reproduce the problem?
Yeah, that's where it gets difficult. This is more a design issue (handing network connections straight through to the OS instead of handling them inside Dolphin, including DHCP and its own IP for the emulated console). To fix that Dolphin would probably need to do all the network handling itself - meaning, send its own DHCP requests to the router with the MAC address defined in the config, and get its own local IP which is only used for this one instance of Dolphin. That is probably not feasible, though.
If you do want to reproduce this somehow you can take a Wiimmfi patched copy of Mario Kart Wii PAL (RMCP01), run it in Dolphin and set an execute breakpoint at 800d2848. That's where the random port generation happens, and when you replace 800d2878 with "li r4, X" you can force the game to use port X for testing. If that X (or, in the unmodified game, that random port) is already in use by some other software on the OS, the game will fail to connect to Wiimmfi.
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
As said above, I don't expect this to be fixed soon (or at all) due to how convoluted this all is (and we can work around the port issue with some additional code in the Wiimmfi update anyways), I just wanted to let people know that this issue exists.
Since IOS are emulated using HLE (High Level Emulation) that was to be expected.
Unless Dolphin creates its own network interface and/or has special privileges, we won't be able to emulate some network features accurately.
For instance, we can't forge ICMP packets or modify datagrams like the Wii.
I don't think we respect the network settings properly either (this will change at some point).
AFAIK, Dolphin doesn't implement SNI.
However, if IOS fails to parse such feature, we won't reproduce that behaviour due to HLE.
I'm pretty sure I can reproduce this.
Regardless, I'm unsure if there is a reasonable workaround to address this.
For the record, based on the signature on Mario Kart Wii, I located the same function but on Super Smash Bros. Brawl (NTSC-U).
You will find in attachment screenshots of its properties.
It won't affect all games using the DWC library but rather all games relying on the GameSpy part of the library.
More specifically, the GT2 connection part which seems to be used on things related to GPCM/GPSP servers including QR2 server.
That random port generation isn't part of the standard
DWC_Init function, AFAICT.
In sum, it will affect some games using the DWC library but not all of them (though, it will affect most of the ones supported by Wiimmfi).
For instance, Just Dance games are using the DWC library but aren't affected by this issue since they only rely on the NAS server.
Some references for people new to this:
#3 Updated by Leseratte10 about 2 months ago
You're correct, Dolphin does not implement SNI. The mbedtls library that Dolphin uses for SSL stuff does, though. I checked it with Wireshark, requests sent by the game in Dolphin do have the server_name extension, while requests sent by a real Wii don't.
I created PR 9406 to change a config option of mbedtls to stop it from using SNI for SSL requests. That still leaves the port issue (which was the main reason for this bug report), but it gets rid of the SNI issues (unless people are building with libpolarssl-dev installed which would use the system's library for SSL).
#4 Updated by sepalani about 2 months ago
I tried an alternative approach which should work without recompiling the library:
Regarding the port issue, I don't have any idea not involving administrator rights like:
- Creating a new NIC
- Adding another IP address to the current NIC