The new wifi adventure
I'm doing this while waiting for my surgery, which will be in 3 days. So, a bit more about yesterday's screenshot.


Basically, it all started with a new branch called slirp. What's that, you ask, another of Arisotura's oddball noises?

Nah. If you followed the melonDS history, you know that a while back, support for internet connectivity was added. It was pretty similar to how DeSmuME did it back then: providing a basic emulated access point to connect to, then forwarding outgoing traffic via libpcap.

While it was straightforward, it had its lot of issues: it required installing libpcap (or any Windows equivalent), required admin/root privileges, and, more annoyingly, did not work over wifi connections, as explained here.

Eventually indirect mode (aka LANMAGIC) was developed to get around this. The basic idea was to emulate a local network and use simple BSD sockets to forward outgoing traffic to the host network. The idea was good, but the actual implementation was more or less a pile of hacks that never really worked right.

Enter the slirp branch. Basically, QEMU's libslirp does exactly what LANMAGIC clumsily tried to do.

So I reimplemented indirect mode using that. Took a while to figure out how to use libslirp, as it isn't really documented, but we got there, and it works beautifully.

More notably, this is how we like it. Unlike direct mode, it requires no setup, it Just Works™. Over any sort of connection, without any special privileges, ...


Then I got carried away and began implementing features of the DSi's new wifi device. From there, you can see how this ended.

The DSi uses this new wifi device when connecting to the internet (local-multiplayer type connections use the old DS wifi device).

Alas, due to being a few years late to the party, there isn't much to do anymore. You can try using the DSi browser, but it won't be able to load a lot of websites successfully due to how limited and outdated it is. This site works fine... somewhat.

I was also able to update my emulated DSi to the latest firmware version, 1.4.5E. It doesn't do much, but it's working without issues, so there's atleast that.

Connecting to the DSi Shop gave me some weird undocumented error code. The logs showed that it was trying to use AES-CCM encryption, which was unimplemented. As I had already taken care of CCM decryption and verification, I could implement encryption quickly. Then I was able to access the Shop, from which you can download the 3DS transfer utility, and, well, nothing else.

Atleast these features are emulated, in case this can help spark new initiatives in the field, akin to AltWFC. Although things like custom DSi Shop servers would pose obvious copyright problems, unless they only distributed homebrew...


Regarding the old libpcap-powered direct mode, I'm thinking of retiring it. Perhaps not for 0.9, but later for sure. It might stick around for debugging purposes, but it has little advantage for the average joe if libslirp works just as well and is more flexible and easier to setup.


Regarding directions to take now, I have several ideas.

An interface for editing firmware settings. We could atleast make it work for DS mode. It would also allow you to change the console's MAC address, mostly to make up for the fact we're removing MAC randomization.

We also need some FAT library that can access files inside a FAT image. One of the purposes would be accessing the config files inside the NAND (which, below the encryption layer, is mostly a FAT filesystem), so we could edit the DSi-mode firmware settings too. We could also patch the touchscreen calibration data, like we do for DS mode (might also make that feature optional?).

Being able to generate a FAT image from a given folder, and maybe reflect changes to the actual files, would be perfect for things like the DSi's SD card, or DLDI. Not sure what is possible there, but we'll see.

I also need to finish the cheats feature. Dammit, considering all these things you see are popping up because I'm procrastinating on that.


Either way, this has been a fun ride.
Amnesia says:
Jun 24th 2020
From HBL and TWL++
Amnesia says:
Jun 24th 2020
I know that from TWL it should not work but to test
Amnesia says:
Jun 25th 2020
I know I shouldn't ask for it, but if someone wants to share their files, I would appreciate it, no matter how hard I try I can't dump my files (I don't even know which ones are fine and which ones aren't)
Rian Caio says:
Jun 25th 2020
there some dump in archive
Amnesia says:
Jun 25th 2020
I have a user in the forum, I can't find the option to create a user in the board. My forum user is Amnesia.

The nand does contain the string "DSi eMMC CID / CPU" at offset 0xF000000.

BIOSDSI7 "5e81ea4df434c3d2f51eb9326aaadc8056a3f613da54405325267b0971eb9d84"

BIOSDSI9 "664c608bd6ccfe583e87b3b924afa00f8697dc7ca92eeb6d206d68abb03d2e10"

FirmwareDSi "551649ca46a7eb346c4c3a2bea434d3e83a5c9798fa3d24b210f7babc3deab90"
Amnesia says:
Jun 25th 2020
I have already done this tutorial (dsi.cfw.guide/launching-the-exploit), in effect it is what I did to modify my DSi
^.^ says:
Jun 28th 2020
We never had an emulator that supports both the Dsi AND wifi! This is BIG. (The online component in games like flipnote studio and Pokemon BW/BW2 is still important)
There were some workarounds for using the libpcap mode on a laptop, but I'm really happy a better implementation was included :D
Also also also, I got an idea from the dolphin team: since the online firmware update still works, can we build a nand image only from *what we can download from the NUS (Nintendo Update Servers)*, having only to provide the BIOS files, maybe?
WaluigiWare64 says:
Jul 2nd 2020
Also, great work!
I can finally connect to custom WFC servers, and I'm using wifi!
Vijju123 says:
Jul 10th 2020
Hey,

First of all GLAD to hear you are ok. And I just wanted to really really thank you for this emulator - when my cousins came over for the summer we had TON of fun and pokemon battles and what not. Really lots lots LOTS thanks for this. <3
Post a comment
Name:
DO NOT TOUCH