Dolphin bug tracker: Issueshttps://bugs.dolphin-emu.org/https://bugs.dolphin-emu.org/favicon.ico?12022-12-27T06:02:21ZDolphin bug tracker
Redmine Emulator - Emulator Issues #13129 (New): Network: Wrong broadcast address used on Androidhttps://bugs.dolphin-emu.org/issues/131292022-12-27T06:02:21ZLeseratte10
<p><strong>What's the problem? Describe what went wrong.</strong></p>
<p>This is a general bug in Dolphin's network code for Android that I noticed looking at the code. I didn't open a PR as I'm unsure how to fix that, never programmed anything for Android before. At least now the bug is documented here (if it's a bug and I'm not misunderstanding stuff).</p>
<p>Looking at the function GetSystemDefaultInterface in Source/Core/Core/IOS/Network/IP/Top.cpp, this function is supposed to return a DefaultInterface which according to the struct definition contains IPv4, subnet mask, and broadcast address. </p>
<p>Looking at how that function is implemented, on Windows and Linux it correctly returns IP, netmask and broadcast address. <br>
On Android, the function calls GetNetworkGateway() which is a Java function that returns the Gateway of the current network connection. And then it returns that in place of the broadcast address. Also, it only returns something if the condition "if (addr || netmask || gateway)" is met - shouldn't that be "if (addr && netmask && gateway)" instead so no incomplete data is returned? </p>
<p>The code has that bug ever since it was introduced in PR 9191. </p>
<p>Another related bug is in the function below, GetSystemDefaultInterfaceOrFallback. It uses variable names "IP", "NETMASK" and "GATEWAY", though it returns IP, Netmask and Broadcast address. And the broadcast address that's included in the code there ("10.0.255.255") is neither a valid broadcast address nor a valid gateway address for that network (broadcast for that network would be 10.0.1.255). </p>
<p>Looking at what a real Wii does according to WiiBrew, that IOS call is supposed to return IP, Netmask & Broadcast, so the struct and the Windows/Linux implementation seems correct while the Android implementation is wrong.</p>
<p><strong>Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.</strong></p>
<p>Yes, see <a href="https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/IOS/Network/IP/Top.cpp" class="external">https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/IOS/Network/IP/Top.cpp</a> </p>
Emulator - Emulator Issues #12899 (New): [Feature Request] Steam Input support for SteamDeckhttps://bugs.dolphin-emu.org/issues/128992022-04-26T07:26:16ZLeseratte10
<p>I just got a Steam Deck and installed Dolphin onto it to play Wii games. Unfortunately, it's <em>really</em> difficult to configure the controller(s) correctly. </p>
<p>On my computer, I've always just used a real Wiimote and had no issues with button mapping. On the SteamDeck I want to use the built-in controller, and that has two issues: </p>
<p>A) The first issue is that I can't have game-dependant controller configs in Dolphin. If I have one game that requires Wiimote+Nunchuk, and another game that doesn't work with the Nunchuk, then I would always have to open up the Dolphin interface, go into the controller settings and enable or disable the Nunchuk when I switch games. I usually have the Wii games directly in the SteamDeck interface (executing "dolphin-emu -e gamename.wbfs"), so this is annoying. </p>
<p>B) I would like to perform the button mapping through Steam - because then it'll all be at one place, the Steam configurator has more features than Dolphin, and it easily supports game-dependant configs. <br>
For actual real Steam games with Steam input, the game exports a list of things you can "do" (like "Accelerate", "Brake", "Steer", "Use Item"), and then in the Steam game settings you can just set "Accelerate" to the A button, and so on. <br>
Of course that's not going to work with all games on Dolphin, as the list of actions would be game-dependant. </p>
<p>Right now what I'm doing is I'm mapping something like "Steam Deck button X" = "Keyboard key Q", and then in Dolphin "Keyboard key Q = Shake Wiimote up" or something. Unfortunately that means that in the Steam Deck UI I can only see that button X is keyboard key Q, and a week later I have no idea what Wii action that is anymore.</p>
<p>What would be great is if Dolphin would export every Wiimote "action" as a Steam action so there'd only be one mapping. <br>
So Dolphin could "export" the following list of actions: </p>
<ul>
<li>Vertical Wiimote Button A</li>
<li>Vertical Wiimote Button B</li>
<li>...</li>
<li>Vertical Wiimote with Nunchuk Button A</li>
<li>...</li>
<li>Horizontal Wiimote Button A</li>
<li>...</li>
</ul>
<p>That way, for example, to configure MKWii I'd set "A" to "Vertical Wiimote with Nunchuk Button A" and the left Stick to "Vertical Wiimote with Nunchuk Stick". <br>
And for NSMB Wii, I could configure "A" to be "Horizontal Wiimote Button 2". All in the SteamDeck UI. </p>
<p>That way there would be no need for people to manually change the Dolphin controller settings for each game because Dolphin could "read" from the Steam Input API whether a Nunchuk is supposed to be connected or not - if the player presses a button on "Vertical Wiimote with Nunchuk" then connect an emulated Nunchuk, and if he presses a button on "Vertical Wiimote", disconnect it again. </p>
<p>I did see a Steam-related PR on Github ( <a href="https://github.com/dolphin-emu/dolphin/pull/10462" class="external">https://github.com/dolphin-emu/dolphin/pull/10462</a> ) but that's just for the Steam runtime and doesn't add any Steam Input code. </p>
Emulator - Emulator Issues #12895 (Accepted): Riivolution-replaced disk files always load instantlyhttps://bugs.dolphin-emu.org/issues/128952022-04-23T16:46:50ZLeseratte10
<p><strong>Game Name?</strong></p>
<p>Probably any game / tested with Mario Kart Wii</p>
<p><strong>Game ID?</strong> (right click the game in the game list, Properties, Info tab)</p>
<p>Probably any game / tested with RMCP01</p>
<p><strong>What's the problem? Describe what went wrong.</strong></p>
<p>Usually, Dolphin emulates the read speed of a real Wii's disk drive, so every read request is delayed until it takes the amount of time it would take on a real Wii. I believe this was added because some games break when files loaded from a Disk load too fast. </p>
<p>However, the new Riivolution patch support seems to not implement that. The loading times in Mario Kart Wii, especially for the tracks themselves, are way faster when the tracks are loaded from a Riivolution XML instead of directly from the emulated Disk. </p>
<p>That doesn't cause any issues in Mario Kart Wii, which to my knowledge doesn't care how fast or slow a disk read is, but it might cause other games to break randomly if Riivolution reads are faster than Disk reads. </p>
<p>I am not sure how that is on actual hardware (maybe SD card reads of a file through Riivolution are faster too and games might break as a result, or maybe Riivolution actually adds a delay in that case) as I currently don't have a real Wii with working disk drive available.</p>
<p>I'm also not sure if this even effects any actual game, as I was unable to find like a list of games that are broken with fast read speeds. <br>
I just stumbled upon this while testing Dolphin's Riivolution implementation and was surprised how fast the games loaded stuff.</p>
<p><strong>What steps will reproduce the problem?</strong></p>
<p>Prepare a Riivolution XML / bundle that replaces a large file on-disk with an identical copy of that file. Observe that with "Speed up Disc Transfer Rate" <strong>disabled</strong>, the Riivolution version loads way faster. With "Speed up Disc Transfer Rate" <strong>enabled</strong>, they load in about the same time. </p>
<p><strong>Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.</strong></p>
<p>Yes, in 5.0-16143</p>
<p><strong>Is the issue present in the latest stable version?</strong></p>
<p>Latest stable didn't have Riivolution support.</p>
Emulator - Emulator Issues #12507 (New): Dolphin sometimes uses wrong source IP for UDP packetshttps://bugs.dolphin-emu.org/issues/125072021-05-15T08:43:51ZLeseratte10
<p><strong>Game Name?</strong></p>
<p>Probably any game, I tested with Mario Kart Wii</p>
<p><strong>Game ID?</strong> (right click the game in the game list, Properties, Info tab)</p>
<p>RMCP01, probably applies to any game.</p>
<p><strong>What's the problem? Describe what went wrong.</strong></p>
<p>I'm running Dolphin on a linux machine with the following network configuration: </p>
<pre><code>4: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 70:85:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 10.0.1.102/16 brd 10.0.255.255 scope global dynamic noprefixroute enp3s0
valid_lft 2283sec preferred_lft 2283sec
inet 10.20.0.1/16 scope global enp3s0
valid_lft forever preferred_lft forever
inet6 2001:470:70bc:0:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic noprefixroute
valid_lft 6756sec preferred_lft 3156sec
inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link noprefixroute
valid_lft forever preferred_lft forever
</code></pre>
<p>10.0.1.102 is my "main" local IP in my normal network. 10.20.0.1 is an extra IP I added to my machine manually. <br>
My actual router (at 10.0.1.1) is configured with a static route to send all 10.20.0.0/16 traffic to 10.0.1.102.<br>
My Wii has the IP 10.20.0.39 with gateway 10.20.0.1 which makes my computer act as a router for the Wii. </p>
<p>Mario Kart Wii (and other Wii games, too) has a feature that when it figures out that two clients are behind the same internet connection (= have the same public IP) they tell eachother their local IP address and try to communicate directly, without using the NAT negotiation server. </p>
<p>When that happens in this particular constellation, Dolphin uses the wrong source IP and the Wii then errors out.</p>
<p>The Wii (10.20.0.39) and Dolphin (10.0.1.102 and 10.20.0.1) come to the conclusion that they are on the same internet connection, and MKWii on Dolphin then tells the MKWii on the Wii "hey, we could skip all that server stuff, just contact me directly at 10.0.1.102". </p>
<p>The Wii obliges and sends an UDP packet from its IP (10.20.0.39) to the IP that Dolphin claimed to have (10.0.1.102). Then Dolphin replies to the Wii at 10.20.0.39, but chooses to use 10.20.0.1 as the sender IP (as that IP is in the same network), and not the IP 10.0.1.102 which it previously claimed to be. The Wii then goes "wait a minute, this response comes from the wrong IP" and cancels the connection. </p>
<p>This probably isn't an issue for most people (since I doubt many people have multiple local IPs on their machine AND want to play with a Wii in the same local network) but I wanted to report it anyways to make sure. </p>
<p>To fix it, I'd assume Dolphin would have to pick ONE local IP address from the system's network stack (in this case the first one, 10.0.1.102), and then always use that IP as sender of UDP packets even if the destination address is in the same subnet as one of the other existing IP addresses. </p>
<p><strong>What steps will reproduce the problem?</strong></p>
<p>I'm not sure if there's an easier way to reproduce this issue, but here's how it should work: </p>
<ul>
<li>Take a Linux machine and add another IP to its network interface (ip addr add 10.20.0.1/16 dev eth0)</li>
<li>Add a static route to your router, forwarding the whole 10.20.0.0/16 network to your Linux machine</li>
<li>Enable forwarding / routing on that Linux machine: echo 1 > /proc/sys/net/ipv4/ip_forward</li>
<li>Configure a static IP from that new network on your Wii in the network settings (static IP 10.20.0.39, netmask 255.255.0.0, gateway 10.20.0.1)</li>
<li>Start Mario Kart Wii on your Wii, connect to Wiimmfi and open a friend room</li>
<li>Start Mario Kart Wii in Dolphin, connect to Wiimmfi, and try to join your Wii's friend room. </li>
</ul>
<p>Notice that after a bit of matchmaking the two clients do exchange peer-to-peer data over UDP, but the handshaking process fails (and is repeated over and over again) because the Wii notices the wrong IP.</p>
<p><strong>Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.</strong></p>
<p>It is, in 5.0-14191</p>
<p><strong>Is the issue present in the latest stable version?</strong></p>
<p>Not sure, can't successfully compile 5.0-stable. Tried a version from half a year ago (5.0-12725) and the issue is present there, too.</p>
<p><strong>What are your PC specifications?</strong> (CPU, GPU, Operating System, more)</p>
<p>i9-9900K, RTX 2080Ti, Ubuntu 20.04</p>
Emulator - Emulator Issues #12379 (Fixed): Some Mario Kart Wii track elements are invisible since...https://bugs.dolphin-emu.org/issues/123792021-01-08T13:29:04ZLeseratte10
<p><strong>Game Name?</strong></p>
<p>Mario Kart Wii</p>
<p><strong>Game ID?</strong> (right click the game in the game list, Properties, Info tab)</p>
<p>RMC***</p>
<p><strong>What's the problem? Describe what went wrong.</strong></p>
<p>Since the "Fix Super Mario Sunshine Debug cubes" PR has been merged ( <a href="https://github.com/dolphin-emu/dolphin/pull/9122" class="external">https://github.com/dolphin-emu/dolphin/pull/9122</a> ), some elements in Mario Kart Wii custom tracks are invisible which were visible before. </p>
<p>This includes the wodden bridge at the end of "1465 N64 Yoshi Valles Beta2.mkwfun (zilly)" (<a href="https://ct.wiimm.de/i/1465" class="external">https://ct.wiimm.de/i/1465</a>), and one of the transparent pipes in "8072 Seaway v1.02 (Okin)" (<a href="https://ct.wiimm.de/i/8072" class="external">https://ct.wiimm.de/i/8072</a>). These are the two tracks where I noticed the issue, it's possible (and likely) that other tracks are broken as well. </p>
<p>On console and on older Dolphin versions, both the bridge and the pipe are visible. </p>
<p><strong>What steps will reproduce the problem?</strong></p>
<ul>
<li>Download and patch Wiimms MKW Fun 2020-12 (<a href="http://wiki.tockdom.com/wiki/Wiimms_Mario_Kart_Fun_2020-12" class="external">http://wiki.tockdom.com/wiki/Wiimms_Mario_Kart_Fun_2020-12</a>), which contains these two tracks.</li>
<li>Play a race on "N64 Yoshi Valley". </li>
</ul>
<p>Notice that the wood bridge near the end of N64 Yoshi Valley and the glass pipe where the two roads cross on Seaway are both invisible. </p>
<p><strong>Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.</strong></p>
<p>Yes, it is, in 5.0-13452</p>
<p><strong>Is the issue present in the latest stable version?</strong></p>
<p>No idea, I can't successfully compile 5.0-stable. </p>
<p><strong>If the issue isn't present in the latest stable version, which is the first broken version?</strong> (You can find the first broken version by bisecting. Windows users can use the tool <a href="https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds" class="external">https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds</a> and anyone who is building Dolphin on their own can use git bisect.)</p>
<p>First broken version is 5.0-13081, the first version after PR 9122 has been merged. A bisect says 51724c1ccdbc141b1aed67a2efc952e884cadd35 is the first broken commit, which is one of the two commits in said PR.</p>
<p><strong>If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: <a href="https://wiki.dolphin-emu.org/index.php?title=FifoPlayer" class="external">https://wiki.dolphin-emu.org/index.php?title=FifoPlayer</a></strong></p>
<p>I attached a fifolog of the invisible bridge, and two screenshots. One from a broken build (invisible bridge), one from a working build (visible bridge).</p>
<p><strong>What are your PC specifications?</strong> (CPU, GPU, Operating System, more)</p>
<p>i9-9900K, RTX 2080Ti, Ubuntu 20.04</p>
<p><strong>Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,<br>
configuration files, savefiles, savestates)</strong></p>
<p>Screenshots & FIFO logs are attached.</p>
Emulator - Emulator Issues #12323 (New): Wii network not fully emulatedhttps://bugs.dolphin-emu.org/issues/123232020-11-20T13:40:27ZLeseratte10
<p><strong>Game Name?</strong></p>
<p>Any game that's using Nintendo's DWC library, meaning, any game with online support. Tested with MKWii (RMCP01).</p>
<p><strong>What's the problem? Describe what went wrong.</strong></p>
<p>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. </p>
<p>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. </p>
<p>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. </p>
<p>Sure, that's a pretty artificial problem by itself, and I actually noticed it while doing something different: <br>
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. </p>
<p>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. </p>
<p>===</p>
<p>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).</p>
<p>===</p>
<p>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. </p>
<p><strong>What steps will reproduce the problem?</strong></p>
<p>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. </p>
<p>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. </p>
<p><strong>Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.</strong></p>
<p>Yes, 5.0-13063</p>
<p><strong>Other stuff</strong></p>
<p>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. </p>
Emulator - Emulator Issues #12153 (Fixed): Dolphin crashes on game exit if two USB Geckos are con...https://bugs.dolphin-emu.org/issues/121532020-06-14T13:29:15ZLeseratte10
<p><strong>Game Name?</strong></p>
<p>Any game (tested multiple games)</p>
<p><strong>What's the problem? Describe what went wrong.</strong></p>
<p>When you connect two emulated USB Geckos to the emulated console, Dolphin crashes when you quit the game. </p>
<p><strong>What steps will reproduce the problem?</strong></p>
<ol>
<li>Go into the Dolphin Settings, to the "Gamecube" tab, and connect a USB Gecko both to Slot A and to Slot B</li>
<li>Start a game (I tested MKWii, Wii Sports and Wii Play and they all crashed).</li>
<li>Quit the game (press the Stop button in Dolphin, or close the Window)</li>
<li>Observe that Dolphin crashes.</li>
</ol>
<pre><code>terminate called after throwing an instance of 'std::system_error'
what(): Invalid argument
</code></pre>
<p><strong>Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.</strong></p>
<p>Yes, 5.0-12115</p>
<p><strong>Is the issue present in the latest stable version?</strong></p>
<p>Not sure, trying to compile 5.0-stable results in errors. </p>
<p><strong>What are your PC specifications?</strong> (CPU, GPU, Operating System, more)</p>
<p>Ubuntu 20.04, i9-9900K, RTX 2080Ti</p>
Emulator - Emulator Issues #12047 (Accepted): Arbitrary mipmap detection fails for certain textur...https://bugs.dolphin-emu.org/issues/120472020-04-12T18:56:53ZLeseratte10
<p><strong>Game Name?</strong></p>
<p>Mario Kart Wii</p>
<p><strong>Game ID?</strong> (right click the game in the game list, Properties, Info tab)</p>
<p>RMCP01</p>
<p><strong>What's the problem? Describe what went wrong.</strong></p>
<p>There is a certain light effect on the track "Toads Factory" (the arrows on the conveyor belts), that normally is light, and gets darker the closer you get. On original resolution (640x528) that is working properly, like on console. But the higher the resolution that I use, the sooner the effect gets darker. </p>
<p><strong>What steps will reproduce the problem?</strong></p>
<p>Set the resolution to 1x. Start Mario Kart Wii, start a race on Toads Factory (last track in the Mushroom Cup).<br>
Drive about half a lap until you get to the conveyor belts that run from side to side. Drive onto the conveyor belt, directly onto one of the red or green arrows. Notice that while you are this close, the arrow becomes almost invisible (this is what is supposed to happen, and this also is what happens on console). </p>
<p>Now set the resolution to a reasonably high one (I used 6x (3840x3168) for the test, but 3x or 4x also work, the bug is just not as obvious then) and drive onto one of the conveyor belts again. <br>
Notice that now, all the arrows on the belt are almost invisible, and even when you leave the belt, it takes a reasonable distance until the arrows become visible again. </p>
<p><strong>Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.</strong></p>
<p>Yes, it is, 5.0-11836</p>
<p><strong>Is the issue present in the latest stable version?</strong></p>
<p>Not sure, I have a Linux machine and trying to compile 5.0 just gives me errors. I'd assume that it would be present there as well, but I didn't test it. </p>
<p><strong>If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: <a href="https://wiki.dolphin-emu.org/index.php?title=FifoPlayer" class="external">https://wiki.dolphin-emu.org/index.php?title=FifoPlayer</a></strong></p>
<p>Screenshots are attached. <br>
fifo log is too large for the upload function (22 MB), can be downloaded here: <a href="https://www.dropbox.com/s/x7xfjdirevpae6r/fifo_log?dl=0" class="external">https://www.dropbox.com/s/x7xfjdirevpae6r/fifo_log?dl=0</a> <br>
"working.png" is from Dolphin with 1x resolution (how it's supposed to look, bright arrows)<br>
"broken.png" is from Dolphin with 5x resolution (broken, arrows almost invisible)</p>
<p><strong>What are your PC specifications?</strong> (CPU, GPU, Operating System, more)</p>
<p>i9-9900K, RTX 2080 Ti, Ubuntu 19.10</p>
Emulator - Emulator Issues #12019 (Fixed): Improper handling of null bytes in encrypted setting.t...https://bugs.dolphin-emu.org/issues/120192020-03-20T13:33:28ZLeseratte10
<p><strong>Game Name?</strong></p>
<p>Any game that tries to read stuff from the setting.txt</p>
<p><strong>What's the problem? Describe what went wrong.</strong></p>
<p>Take a look at the file <code>Source/Core/Common/SettingsHandler.cpp</code>, at the function <code>SettingsHandler::Decrypt</code>. </p>
<p><code>str</code> is a pointer to the encrypted data, and the data uses a XOR shuffle with a rotating key. <br>
Right at the beginning of the function is the while condition <code>*str != 0</code> - which is true at the end of the file, but it's also true when there is a NULL byte in the middle of the encrypted data, which can happen - then, the decryption stops in the middle of the file and the decrypted data is incomplete. </p>
<p>See my comment on pull request 8673 for more information: <a href="https://github.com/dolphin-emu/dolphin/pull/8673#issuecomment-601696961" class="external">https://github.com/dolphin-emu/dolphin/pull/8673#issuecomment-601696961</a> </p>
<p><strong>What steps will reproduce the problem?</strong></p>
<p>Find a setting.txt that contains a nullbyte, decrypt using this function, notice that the decryption is wrong. <br>
If necessary, I can provide such a file</p>
<p><strong>Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.</strong></p>
<p>Yes, 5.0-11788</p>
<p><strong>Is the issue present in the latest stable version?</strong></p>
<p>Probably, but I can't test that since 5.0-stable doesn't work properly for me. </p>
Emulator - Emulator Issues #11930 (Fixed): NAND backup serial number import not working properlyhttps://bugs.dolphin-emu.org/issues/119302019-12-14T16:29:48ZLeseratte10
<p><strong>Game Name?</strong></p>
<p>Doesn't really matter (happens with all Wii games), but I tested with Mario Kart Wii. </p>
<p><strong>What's the problem? Describe what went wrong.</strong></p>
<p>When you import a NAND backup from an actual console into Dolphin (which is required for online play in Mario Kart Wii on Wiimmfi), in theory, the "console identity" the server sees when Dolphin connects should be the same one the server sees when the console connects to the server (if Dolphin was perfectly emulating the Wii, and if the user entered his Wii's MAC address into the Dolphin.ini file properly). </p>
<p>However, we've noticed two things Dolphin does differently than on console, which mean that A) the Dolphin instance is seen as another console identity on the server as the real console, and B) Dolphin has four different console identities, one for each game region. </p>
<p>Meaning, that instead of having one console identity shared between console and Dolphin, there are (worst case) five, one for the Wii, and one for each region in Dolphin. </p>
<p>I've noticed that each time I import a NAND into Dolphin, the resulting emulated console has a different serial number. I don't know why that happens, I checked the source code and it looks like it should import the serial number from the NAND. Either I missed some code where this is deliberately reset, or there is a bug in Dolphin. </p>
<p>The second issue is that Dolphin regenerates the setting.txt from scratch on each game boot, and it doesn't honor the serial number prefix properly. <br>
Looking at the Dolphin source code at <code>Core/Core/Boot/Boot_BS2Emu.cpp</code> there is a function called <code>CBoot::SetupWiiMemory</code>, which checks the game region and creates this <code>region_settings</code> array thing, which contains the serial number prefixes (LJ for Japan, LU for USA, LE for PAL and LKH for Korea). This causes the resulting serial number to be different for each game region, meaning, that if a player connects to Wiimmfi with games from four different regions, that'll be seen as four different consoles (which does not happen on Wii). </p>
<p><strong>Summary</strong></p>
<p>A) Importing a NAND backup doesn't use the serial number from the NAND backup but regenerates a random one and<br>
B) Booting a game switches the serial number prefix to one matching the game region, instead of using the prefix from the NAND backup.</p>
<p>Is there a particular reason for both of these quirks? They force Dolphin users to wait an additional week because their Dolphin instance is detected as a new console, or, worst-case, for them to wait multiple weeks if they play games from different regions. Also, this bloats up the user's Wiimmfi web interface when they see five different entries for their Dolphin instead of just one.</p>
<p><strong>What steps will reproduce the problem?</strong></p>
<p>Not that easy to reproduce in-game, but with a bit of logging the issue should become clear. As seen in <code>CBoot::SetupWiiMemory</code> within <code>Core/Core/Boot/Boot_BS2Emu.cpp</code> there is a hardcoded serial number prefix for each region (while Dolphin is supposed to use the one from the NAND backup, if the user did import one); and each import of the same NAND backup generates a new serial number instead of reading and using the one from the NAND backup. </p>
<p>But if you do want to test in-game, this is how you could do it: </p>
<ul>
<li>Import your Wii's NAND into Dolphin</li>
<li>Get a Wiimmfi-patched image for any supported game</li>
<li>Boot it and connect to Wiimmfi</li>
<li>While doing so, run at a network dump and observe the serial number sent to the first server at ca.nas.wiimmfi.de (for Mario Kart Wii) or naswii.wiimmfi.de (for any other game) in the "csnum" parameter.
(or enable debug logging in Dolphin and look for the "Using serial number" line)</li>
<li>Observe that A) the serial number changes each time you import the NAND and doesn't match the serial number of your console, and that B) the serial number prefix is one of the four hardcoded ones, and not the one of your console. </li>
</ul>
<p><strong>Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.</strong></p>
<p>Yes, 5.0-11382.</p>
<p><strong>Is the issue present in the latest stable version?</strong></p>
<p>Unable to test, 5.0-stable is unable to connect to Wiimmfi. Highly likely that this is present in 5.0-stable as well. </p>
<p><strong>What are your PC specifications?</strong> (CPU, GPU, Operating System, more)</p>
<p>Highly unlikely that this is relevant, but why not: i9-9900K, NVIDIA RTX 2080 Ti, Ubuntu 19.10.</p>
Emulator - Emulator Issues #11455 (Fixed): Mario Kart Wii @ Wiimmfi not working with recent patcheshttps://bugs.dolphin-emu.org/issues/114552018-11-12T20:23:59ZLeseratte10
<p><strong>Game Name?</strong><br>
Mario Kart Wii @ Wiimmfi</p>
<p><strong>Game ID?</strong> (right click the game in the game list, properties, info tab)<br>
RMCP01, RMCE01, RMCJ01, RMCK01</p>
<p><strong>MD5 Hash?</strong> (right click the game in the game list, properties, info tab, MD5 Hash: Compute)<br>
For RMCP01, ae18681737466a6a85c7e8071c40b1d8, but that is not the original image but a Wiimmfi-patched copy, so I don't know how helpful this is. The image itself is patched properly and works just fine on a Wii. </p>
<p><strong>What's the problem? Describe what went wrong.</strong></p>
<p>Hello everyone. My name is Leseratte and I am one of the developers of Wiimmfi. Yesterday, for security reasons, we had to publish a mandatory update for all Wiimmfi patchers due to a security issue in Mario Kart Wii (if you are interested in background info read <a href="https://wiimmfi.de/update" class="external">https://wiimmfi.de/update</a> but I believe that is irrelevant to this bug). That patcher works without a problem on Wiis, but it does not work properly on Dolphin. </p>
<p>Now I basically spent the whole day today to test different Dolphin versions, settings, configurations, but was unable to get it to work flawlessly. </p>
<p>In my case, running Dolphin 5.0-2968 on Ubuntu 17.10, everything works fine. This is why this bug wasn't noticed during our testing. Now that we released the update, basically all Dolphin players are telling us that this doesn't work. Connecting to Wiimmfi, which should result in the server applying some RAM patches to the game, results in either error code 20100 or 20101. Network dumps show that either, the game just stops after getting the OK to continue connecting from our login server, or, that it doesn't connect to the login server properly at all. </p>
<p>We tried running different Dolphin builds to find out if there is one that works, but were unable to find one. We did also try running Dolphin in Interpreter mode, which, as far as I understand, should make it behave 100% like a Wii with no optimizations at all, and that seems to have fixed the problem in some cases, but most of the time it still fails and I was not able to determine any kind of pattern as to what could cause it to work / cause it to fail. </p>
<p>I realize that the Dolphin developers don't really have any knowledge about the patcher update / patch system, but I really hope that it is possible to somehow fix this issue anyways, because in its current state, due to this change (which works fine on console, so it is a problem in Dolphin), no Dolphin player can play MKWii online, and there were quite a few people who did that and would like to continue doing so. </p>
<p>Is there any kind of debugging log the affected players could create to help find this bug? </p>
<p><strong>What steps will reproduce the problem?</strong></p>
<ol>
<li>Make sure you have all the Wii network stuff with certificates and whatnot set up properly: <a href="https://de.dolphin-emu.org/docs/guides/wii-network-guide/" class="external">https://de.dolphin-emu.org/docs/guides/wii-network-guide/</a> </li>
<li>Grab a Mario-Kart-Wii ISO (no matter what region)</li>
<li>Download the newest Wiimmfi patcher: <a href="https://download.wiimm.de/wiimmfi/patcher/mkw-wiimmfi-patcher-v4.zip" class="external">https://download.wiimm.de/wiimmfi/patcher/mkw-wiimmfi-patcher-v4.zip</a> , extract it and put your ISO into that folder. </li>
<li>Run the "patch-wiimmfi.bat" (on Windows) or the "patch-wiimmfi.sh" on Linux.</li>
<li>After some time a new ISO should appear in a "wiimmfi-images" subfolder. Boot that in Dolphin. </li>
<li>(Try to) connect to Wiimmfi.</li>
</ol>
<p>You will receive either error 20100 or error 20101 depending on your Dolphin config, when you run in JIT Recompiler mode. When you try JITIL it doesn't boot at all. In Interpreter mode, it seems to work for some people, but not for everyone. </p>
<p><strong>Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.</strong></p>
<p>Yes, it is, in 5.0-9115.</p>
<p><strong>Is the issue present in the latest stable version?</strong></p>
<p>Yes, it is, in 5.0.</p>
<p><strong>If the issue isn't present in the latest stable version, which is the first broken version?</strong> (You can find the first broken version by bisecting. Windows users can use the tool <a href="https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds" class="external">https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds</a> and anyone who is building Dolphin on their own can use git bisect.)</p>
<p>It is present in the latest stable version. </p>
<p><strong>What are your PC specifications?</strong> (CPU, GPU, Operating System, more)</p>
<p>I am testing on Ubuntu 17.10 with both 5.0-2968 and 5.0-9115 and it works for me, all the time. For the other users for which this fails I can only say that they use Windows and that multiple different versions of Dolphin have been tested. If the exact specifications of CPU, OS, Dolphin version are important, just tell and I'll go ask for a couple examples of Dolphin/CPU/GPU/OS combinations.</p>
<p><strong>Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,<br>
configuration files, savefiles, savestates)</strong></p>
<p>Well, there aren't any special config files or savestates, tell me if you need anything and I will try to provide it. I don't know much about Dolphin internals or how such a bug might be tracked down so I don't know what information might help you guys. </p>