Page 4 of 5

Re: DSi Wifi rev-engineering

Posted: Sun Jan 20, 2019 6:32 pm
by koitsu
nocash wrote:... And, I do even have an access point that supports something called "802.1X" and "WPA" and "WPA2-enterprise", despite of the confusing names, all three are using something called Radius server. As far as I know, that's better than normal WPA/WPA2, but not for home use, or so. I guess I'll omit supporting that, I've no idea how it works, and I don't even know if I do have a Radius server (it doesn't look as if the access point would have that built-in).
For consumer (read: non-workplace/non-enterprise) use, don't worry about 802.1X. 802.1X is a form of authentication protocol/model used for both wired and wireless networks. It was originally designed for Ethernet (called EAPOL (EAP Over LAN), where the idea was that you wanted an authentication layer atop Ethernet to ensure nobody could just plug something into a port and immediately begin using it. It's implemented at layer 2, thus has its own framing type/format. Later it was extended to support 802.11 wireless, where sometimes it's just called EAP. The implementation is pretty simple: there's a client (server/laptop/desktop/whatever) which runs software that generates the frames + handles the authentication. This talks to an "authenticator", which for Ethernet would be a switch or bridge that supports 802.1X itself. That device then talks to an authentication server (which is what stores credentials or whatever else), usually via the RADIUS protocol.

RADIUS is a TCP or UDP-based protocol that's used for authentication (i.e. approval/rejection). It was designed back in the early 90s for dial-up use, mainly used for defining whether or not a particular customer/user had the ability to log in/authenticate on dial-up or not (as well as delegating L2TP parameters if necessary); but it's a general-purpose protocol. In the later 90s, companies began using it for ISDN and later ADSL/SDSL authentication, usually in combination with PPP. It can be used as a kind of "back-end" for 802.1X.

Anything that's labelled "Enterprise" with WPA or WPA2 as a prefix involves RADIUS or 802.1X -- not needed for consumer stuff.

Some reference materials for you:

https://www.vocal.com/secure-communicat ... -over-lan/
https://kb.netgear.com/188/What-is-802- ... entication
https://networkengineering.stackexchang ... entication
https://en.wikipedia.org/wiki/RADIUS

Re: DSi Wifi rev-engineering

Posted: Tue Jan 22, 2019 12:50 pm
by edo9300
Ok, i finally found some time to test again the connections, but still had no lock, before i connected using the wps configuration, so i thought that might have been the issue, and thus i redid the setup in the "normal" way, but still no luck, it remained stuck on connecting. Then i receched the configurations and i noticed tat the password encryption was ser to wpa2-psk (tkip), not aes (apprently for my router that's the default), so i forced it to be aes, but even if now the network is correctly recognized by the app (no longer shown as "open"), and it's no longer stuck on connecting, i'm still getting the same response as the one i posted on my first answer. I think it's worth noting that during the testes, all those configurations worked fine for the dsi browser, both wps, tkip and aes.

Re: DSi Wifi rev-engineering

Posted: Wed Jan 23, 2019 7:23 am
by nocash
Yes, WPA2-TKIP doesn't work in current version. But I am working on it, and next version should support it (as well as other variants). Btw. a router using WPA2-TKIP would be the newest protocol combined with weakest security, which would be really weird. Unless it's actually using some more meaningful backwards-compatibility mode, like WPA2-AES/TKIP (the DSi's System Settings GUI can't display that combination), or WPA-TKIP+WPA2-TKIP (but in that case wifiboot should have worked fine with WPA-TKIP).

Anyways, my major concern is that - when you had used WPS - my understanding is that you were only seeing this two lines:

Code: Select all

Nocash Wifiboot v2.4
Connecting
on the screen, and the rest of the screen was blank? Yes-yes, I've already asked that twice, but it would be really nice if you could answer that question (alike clearly saying "Yes, only that 2 lines" or "No, more than those 2 lines"). Because, if it's really showing only that two lines then it would be a major problem (ie. it would mean that wifiboot can't read your settings from flash, and then it just won't work, no matter if everything else is perfectly implemented).

My code is now converting beacon info to best matching encryption type. The beacon info consists of WPA or WPA2, and TKIP or AES group key, and TKIP or AES (or both) pairwise key. Plus WEP and open network. That gives quite a number of different combinations. The best matching combination would depend on having WEP or WPA(2) password defined in flash memory, and on having matching decryption hardware (ie. NDS can't do AES, but could probably implement TKIP in software).

Another parameter would be the selected encryption type in flash memory - I am tempted to ignore that setting because it's only hindering connection. If the the WPA(2) password is defined, then one could connect anyways, no matter if the access point is using WPA or WPA2 and AES or TKIP. And if the access point is using a AES/TKIP-combo then one couldn't define that in DSi settings anyways.

Concerning security, it would be difficult for attackers to mimmick a (working) WPA/WPA2 access point, so I don't think that there is much of a security risk when allowing WPA-TKIP despite of flash settings saying WPA2-AES, for example.
The exception would be allowing Open Network (or WEP) despite of flash settings saying something else. That would be highly insecure, up to including other people to upload their own executables to your console via wifiboot. That's perhaps unlikely to happen, but, admittedly, my current code is allowing to do that : )

Re: DSi Wifi rev-engineering

Posted: Wed Jan 23, 2019 7:47 am
by nocash
koitsu wrote:Some reference materials for you:
https://www.vocal.com/secure-communicat ... -over-lan/
One stunning thing in EAPOL is the "Version" byte. Official specs seem to define it as part of 16bit value (that contains Type and Version bytes; without clearly saying which byte is Type, and which is Version).
The above linked document suggests that Version is the 1st byte, and Type is 2nd byte of that 16bit value. But even then, the bytes are usually 01 03. If the 1st byte is Version, then it would be Version=01, whilst most docs are saying that v2 is current version. I could only guess what is happening there:
- Maybe version is 00=v1 and 01=v2
- Maybe version is 01=v1 and 02=v1.1 and 03=v2, or the like
- Maybe version is 02=v2=current, but everybody is held to use 01=v1 for better backwards compatibility.
- Maybe version is unimportant and should be ignored

Re: DSi Wifi rev-engineering

Posted: Thu Jan 24, 2019 7:48 am
by edo9300
Ops, sorry for the misunderstanding, yes, I'm only seeing those 2 lines, also another thing I noticed, in my router settings, when I'm selecting the network encryption, it's actually selected "wep+wpa2" (that's pretty weird tho)

Re: DSi Wifi rev-engineering

Posted: Thu Jan 24, 2019 10:30 am
by nocash
Okay, thanks! I guess I'll need to test WPS myself tonight/tomorrow & dump the resulting DSi-Wifi-FLASH settings, there should be an access point with WPS button somewhere upstairs. The Wifi-FLASH is probably merely having a "WPS-was-used" flag in there, which is currently seen as unknown value by wifiboot.

WEP+WPA2 is really weird, WPA+WPA2 would be a bit more common, or maybe WEP+WPA+WPA2 if one wants support it all. Also, if WEP implies RC4, and WPA2 usually implies AES, then I can't imagine how system settings had detected it as using TKIP. But yeah, theoretically, WEP+WPA2 should be possible for backwards compatibility. But I've no idea how to support that in practice.

The first problem is that I don't know if or how EAPOL is capable of sending WEP groupkeys (it would be pointless as the WEP group key should be identical to the WEP pairwise key, which is fixed for WEP, so EAPOL wouldn't need to send it at all; at least not to clients that do use WEP as pairwise key).
The other problem, for real working compatibility with stuff like NDS, is that WPA/WPA2 are using keyindex=1/2 for group keys, whilst NDS games seem to require to use keyindex=0 for both group+pairwise key.

Does your router have two separate passwords for WEP and WPA2? WEP does usually require a fixed-length password (13 characters, or 26-hex-digits), and WPA/WPA2 can have variable-length text strings as password.

Re: DSi Wifi rev-engineering

Posted: Fri Jan 25, 2019 4:33 am
by nocash
Here are the differences between normal-setup and automated-WPS-setup. Bit1 of entry [0E7h] is just what one would have expected, the unexpected part is that bit0 is also set.
Also noteworthy: The plaintext password is stored at 120h and up, that's useful when changing the SSID, so the console can recompute the new PSK for password+ssid. And oddly, WPS has some garbage in unused password characters.

Code: Select all

Offset       WPS   Normal
1F6E7        13    10         ;<-- diff
1F6FE        F4    A0         ;\crc
1F6FF        9D    78         ;/
1F734-1F75E  xxx   00-filled  ;-garbage (unused password chars)
1F7FE        F3    49         ;\crc
1F7FF        2C    1B         ;/
Dumping that info was painful: I've tried three access points, with the DSi prompting me to push and hold the WPS button and wait two minutes until seeing a WPS Failure message (on the first three or four attempts with the first two access points), or until eventually passing okay (on the third access point).
Alltogether, it would have been ways to enter the password manually than using WPS. But anyways, it's now dumped and known what bytes are stored in flash memory (just in case anybody would be interested in such things).

Re: DSi Wifi rev-engineering

Posted: Sat Jan 26, 2019 5:10 am
by edo9300
edo9300 wrote:Ops, sorry for the misunderstanding, yes, I'm only seeing those 2 lines, also another thing I noticed, in my router settings, when I'm selecting the network encryption, it's actually selected "wep+wpa2" (that's pretty weird tho)
Apparently I remembered wrongly (when I wrote this message I couldn't go look up the router settings because the web interface was kinda bugged) anyways the encryption is WPA+wpa2, not wep+wpa2 (in fact that was a butt too weird).

Re: DSi Wifi rev-engineering

Posted: Sat Jan 26, 2019 5:19 am
by edo9300
Update, finally managed to connect, I set the encryption to wpa2 only and it worked

Re: DSi Wifi rev-engineering

Posted: Sat Jan 26, 2019 4:13 pm
by nocash
Got the wifiboot v2.5 update finished & uploaded.
http://problemkaputt.de/wifiboot.zip (binary and source code)
I hope the DSi code is now able to connect to most or all access points including such with mixed TKIP+AES ciphers.

Code: Select all

;wifiboot v2.5 - 26 Jan 2019
; - dsi-wifi: detects supported cipher/combinations (from AP beacons)
; - dsi-wifi: determines best-matching-cipher (AP beacons versus FLASH settings)
; - dsi-wifi: supports wifi-flash entries with WPS-flag (ie. ignores that flag)
; - dsi-wifi: relocated all code to vram (slightly faster than slow main ram)
; - dsi-wifi: displays life-updates for current signal strength
; - dsi-wifi: source code: REG_SDIO_xxx symbols instead of numeric I/O addresses
; - dsi-wifi: uses WMI_GET_CHANNEL_LIST to determine enabled channels/domain
; - dsi-wifi: shows REG_DOMAIN country code (eg. 0188=JP, 0348=US)
PS. for whatever reason, NDS-wifi upload speed is back at 110Kbyte/s today, last week it was only 60Kbyte/s, maybe the weather is good for it today. DSi-wifi speed still ranges somewhere at 300..600Kbyte/s.

Re: DSi Wifi rev-engineering

Posted: Sat Jan 26, 2019 4:37 pm
by edo9300
nocash wrote:Got the wifiboot v2.5 update finished & uploaded.
http://problemkaputt.de/wifiboot.zip (binary and source code)
I hope the DSi code is now able to connect to most or all access points including such with mixed TKIP+AES ciphers.

Code: Select all

;wifiboot v2.5 - 26 Jan 2019
; - dsi-wifi: detects supported cipher/combinations (from AP beacons)
; - dsi-wifi: determines best-matching-cipher (AP beacons versus FLASH settings)
; - dsi-wifi: supports wifi-flash entries with WPS-flag (ie. ignores that flag)
; - dsi-wifi: relocated all code to vram (slightly faster than slow main ram)
; - dsi-wifi: displays life-updates for current signal strength
; - dsi-wifi: source code: REG_SDIO_xxx symbols instead of numeric I/O addresses
; - dsi-wifi: uses WMI_GET_CHANNEL_LIST to determine enabled channels/domain
; - dsi-wifi: shows REG_DOMAIN country code (eg. 0188=JP, 0348=US)
PS. for whatever reason, NDS-wifi upload speed is back at 110Kbyte/s today, last week it was only 60Kbyte/s, maybe the weather is good for it today. DSi-wifi speed still ranges somewhere at 300..600Kbyte/s.
Wonderful, tested this new release and connected flawlessy first try to the wpa+wpa2 network configured with wps :), only thing, i couldn't use dslink to upload stuff, nor i can use no$gba upload feature as i get a nocashio driver failure, otehrwise it is connected fine to the network.

Re: DSi Wifi rev-engineering

Posted: Sat Jan 26, 2019 6:21 pm
by nocash
Okay, so it's working, except that uploading doesn't work. Which was the main purpose. But yeah, better than nothing!

Hmmmm, and the nocashio driver - that was for parallel port uploads on windows XP and up, but wasn't intended to be used when selecting wifi as upload method. But yes, now that you mention it, yes, looks as if no$gba insists on installing the driver for wifi, too.
Thanks for the info! I'll fix that in next no$gba update... best before releasing the new wifiboot bundled with next unlaunch update, so that the hordes of DSi developers won't run into the problem.
The devasting part is that the wifi upload function in no$gba was one of the top-new-features released in June 2018. And now you seem to have been the first person to have tried using that feature.
But yeah, also much better than nobody ever having tried using it at all.

And dslink.exe doesn't work either? Then it might be still an issue with wifiboot being not-so compatible with most or all access points : /
Well, I guess I will just wait 20-30 years until a software/hardware archaeologist downloads the wifiboot source code and hopefully fixes the bug for me...

Over here it's working with 3 of 4 access points, so there might be a relative good chance to find a working access point (unless it turns out to work only with those 3 access points, and fails with millions of others).

PS. Did you use the WPS "push-button" method, or WPS "pin-number" method? I've so far tried only the push-button thing. The DSi firmware also allows using a pin-number (a random number displayed on the DSi screen, supposed to be entered in the access point's settings).
I haven't tested that pin-number method, and don't know if it does store yet different values in wifi-flash. Intuitively, I would assume that it's even more difficult than the push-button method (which took me about 20 minutes to get it working). But if somebody is using that pin-number stuff, it would be interesting to hear if it's working, or if it's storing uncommon values in wifi-flash.

Re: DSi Wifi rev-engineering

Posted: Sun Jan 27, 2019 5:15 am
by edo9300
nocash wrote:Okay, so it's working, except that uploading doesn't work. Which was the main purpose. But yeah, better than nothing!

Hmmmm, and the nocashio driver - that was for parallel port uploads on windows XP and up, but wasn't intended to be used when selecting wifi as upload method. But yes, now that you mention it, yes, looks as if no$gba insists on installing the driver for wifi, too.
Thanks for the info! I'll fix that in next no$gba update... best before releasing the new wifiboot bundled with next unlaunch update, so that the hordes of DSi developers won't run into the problem.
The devasting part is that the wifi upload function in no$gba was one of the top-new-features released in June 2018. And now you seem to have been the first person to have tried using that feature.
But yeah, also much better than nobody ever having tried using it at all.

And dslink.exe doesn't work either? Then it might be still an issue with wifiboot being not-so compatible with most or all access points : /
Well, I guess I will just wait 20-30 years until a software/hardware archaeologist downloads the wifiboot source code and hopefully fixes the bug for me...

Over here it's working with 3 of 4 access points, so there might be a relative good chance to find a working access point (unless it turns out to work only with those 3 access points, and fails with millions of others).

PS. Did you use the WPS "push-button" method, or WPS "pin-number" method? I've so far tried only the push-button thing. The DSi firmware also allows using a pin-number (a random number displayed on the DSi screen, supposed to be entered in the access point's settings).
I haven't tested that pin-number method, and don't know if it does store yet different values in wifi-flash. Intuitively, I would assume that it's even more difficult than the push-button method (which took me about 20 minutes to get it working). But if somebody is using that pin-number stuff, it would be interesting to hear if it's working, or if it's storing uncommon values in wifi-flash.
I tried using dslink after setting the network to open, but it didn't seem to work with wifiboot (i also tried the version 2.3 bundled with unaunch, still same result), as for wps, i think nowadays it's almost impossible to find a router that pairs wps with the pin, iirc i saw this stuff only once, but then never see that after as all teh current routers have only the button setup (it's weird that it took 20 minutest for you btw)

Re: DSi Wifi rev-engineering

Posted: Thu Feb 07, 2019 8:28 pm
by nocash
I've updated no$gba - http://problemkaputt.de/gba.htm

The utility/upload function should now work without bugging you about installing nocashio for wifi uploads (as long as you select "Dslink/Wifi" in the "Multiboot Port" setting in no$gba's "Other" options screen). Don't know if it will help on problems with your router (if dslink.exe didn't work then the no$gba uploader probably won't work either). For testing best start uploading something that is known to be working as wifi-upload (eg. magicflr.nds, unlaunch.dsi, or wifiboot.nds itself).

The built-in help (and gbatek) are now also containing the new findings about the dsi-wifi hardware, some general info about wpa/wpa2, and a bunch of info about nintendo's auto-load and title-list structures.

Code: Select all

08 Feb 2019 - version 2.9c
- wifiboot: now supports dsi-wifi-hardware with wpa/wpa2 encryption
- utility/upload: omits nocashio lpt-port-driver for wifi upload (thanx edo9300)
- dsi/wifi/hack: dsi browser patch for writing all sdio traffic to wifi-log.txt
- dsi/wifi/help: new chapter for DSi Atheros Wifi - MBOX Transfer Headers
- dsi/wifi/help: added notes on used WMI params (connect, cipher, pstream, etc)
- dsi/wifi/help: more details for access point 4/5/6 settings in wifi-flash
- nds/wifi/help: updated ds download play chapter (and separate beacon chapter)
- nds/wifi/help: new chapters for WPA/WPA2: handshake, keys/mics, encryption
- nds/help: added reverse-engineered dldi specs (flashcart driver for homebrew)
- dsi/help: added several notes on files found in firmware v1.0J (thanks AnKi)
- dsi/ndma: added support for SDIO startup mode (much alike as SDMMC startup)
- dsi/boot: init AES Key2.X (for Data Managment export to SD card, thanx zoogie)
- dsi/help: device list: details on naming for "public & private savedata"
- dsi/autoload/help: new chapter for auto-loading (formerly in i2c chapter)
- dsi/autoload/help: added skeleton/info on 2000000h (autoload parameters)
- dsi/autoload/help: added more details on 2000300h (autoload by title id)
- dsi/autoload/help: added specs for 2000800h (unlaunch autoload by path\name)
- dsi/autoload/help: added specs for 2FFD800h (nintendo's title list and flags)
- dma/gba/nds7: re-fixed dma0/1/2 len, don't crop 16bit to 8bit (thanx normmatt)
- dsi/bios: added warn if/when using missing RSA keys (missing bios dsi dump)
- aboutbox: added email/contact page (debug version only, not gaming version)
- xed editor: fixed scrolling upon backspace in first some lines (thanks yuki)

Re: DSi Wifi rev-engineering

Posted: Mon Apr 22, 2019 2:08 pm
by nocash
Finally got around to test the write-ability of the DSi's new tiny Wifi-FLASH chips. I had some boards with those chips laying around for a year, but didn't test them yet, parts because overwriting the first some bytes could potentially brick the console (what I have done new is wiring one of the FLASH chips from a broken wifi board to my PC, which can't brick anything).
Results are: A 128Kbyte memory space, with only 4Kbyte actual writeable memory (kinda weird design, and not really needed; the more important part for NDS compatibility is the 24bit address bus).

Code: Select all

DSi "5A32" chip (32Kit aka 4Kbyte)
Early DSi DWM-W015 boards did have 128Kbyte FLASH, but later boards have custum
4Kbyte FLASH chips (these 4K chips are found on later DSi DWM-W015 boards, and
DSi DWM-W024 boards, and 3DS DWM-W028 boards). The chips are having a 24bit
address bus (needed for NDS compatibility), and, a weird non-writeable gap
within a 128Kbyte memory are:
  000000h..0002FFh  Writeable only if /WP=HIGH (otherwise writes are ignored)
  000300h..01F2FFh  Not writeable (FFh-filled, writes are ignored)
  01F300h..01FFFFh  Writeable
  020000h and up    Mirrors of 0..01FFFFh (same read/write-ability as above)
There are several part numbers: "5A32" (DSi), "5K32" (3DS), "32B, 3XH" (3DS),
and "26FV032T" (DSi), that chips are probably all the same size & functionally
same; most of those 4Kbyte chips have tiny packages (except "26FV032T" which
comes in classic large package).

Pin-Outs (Large Package, in NDS, and early DSi boards)
  1   D    Serial Data In (latched at rising clock edge)          _________
  2   C    Serial Clock (max 25MHz)                             /|o        |
  3   /RES Reset                                            1 -| |         |- 8
  4   /S   Chip Select (instructions start at falling edge) 2 -| |         |- 7
  5   /W   Write Protect (makes first 256 pages read-only)  3 -| |_________|- 6
  6   VCC  Supply (2.7V..3.6V typ) (4V max) (DS:VDD3.3)     4 -|/          |- 5
  7   VSS  Ground                                              |___________|
  8   Q    Serial Data Out (changes at falling clock edge)

Pin-Outs (Tiny Package, in newer DSi boards, and 3DS)
  1   /S   Chip Select (instructions start at falling edge)     ___________
  2   Q    Serial Data Out (changes at falling clock edge)  1 -| o         |- 8
  3   /W   Write Protect (makes first pages read-only)      2 -|           |- 7
  4   VSS  Ground                                           3 -|           |- 6
  5   D    Serial Data In (latched at rising clock edge)    4 -|___________|- 5
  6   C    Serial Clock
  7   /RES Reset
  8   VCC  Supply (2.7V..3.6V typ) (DSi: VDD33)
Next, I wanted to test the chip ID for the 26FV032T flash chip on a Hon Hai J27H020 board (which should be equivalent to Mitsumi DWM-W024 boards). But, that didn't worked out : /
When I got that J27H020 board, I had immediately desoldered the shielding plate (and smeared some solder on the antenna connector). I have replaced the antenna connector last week, and put the shielding plate back on the board... but it doesn't work... the console is booting up okay, but it can't find any access points (neither wirh my own firmware/wifiboot code, nor with Nintendo's original firmware, System Settings, and Browser).
Maybe I had damaged the board when removing the shield plate (it was soldered all way round, instead of just to a handful of solder points). Hmmm, or maybe the Hon Hai J27H020 boards require different antenna's?
Would be interesting if other people had similar problems when swapping Mitsumi boards against Hon Hai boards (one known problem is, of course, that DWM-W024 and J27H020 do both require firmware v1.4 or newer; the older firmwares support DWM-W015 only).

Anyways, while searching for J27H020 info, I came across FCC ID webpages, with some interesting info on the wifi hardware & pinouts:

Code: Select all

Wifi FCC ID
The wifi hardware has been registered by Mitsume, Hon Hai, and Nintendo
themselves:
  https://fccid.io/BKE - Nintendo
  https://fccid.io/EW4 - Mitsumi
  https://fccid.io/MCL - Hon Hai (Foxconn)
The above webpages include some unrelated stuff (like bluetooth), and some
duplicate entries. The wifi/console related entries are:
  https://fccid.io/EW4-AGBWA      GBA        ;\GBA wireless adaptor
  https://fccid.io/EW4-OXYWA      GBA-Micro  ;/(not wifi/wlan compatible)
  https://fccid.io/BKENTR001      NDS (non-remove-able board)
  https://fccid.io/BKEUSG-001     NDS-Lite (old remove-able board, with MM3155)
  https://fccid.io/EW4DWMW006     NDS-Lite (new remove-able board, with MM3218)
  https://fccid.io/BKERVL036      Wii
  https://fccid.io/EW4DWMW004     Wii (mitsumi) (also W016, and maybe W014 ?)
  https://fccid.io/MCLJ27H010     Wii (foxconn) (also H003 ?)
  https://fccid.io/EW4DWMW015     DSi (old wifi board, mitsumi)
  https://fccid.io/EW4DWMW024     DSi (new wifi board, mitsumi)
  https://fccid.io/MCLJ27H020     DSi (new wifi board, foxconn)
  https://fccid.io/EW4DWMW028     3DS (mitsumi)
  https://fccid.io/MCLJ27H023     3DS (foxconn)
  https://fccid.io/MCLJ27H02301   2DS (foxconn)
  https://fccid.io/BKERED001      New3DS (on mainboard)
The pages include test reports, photos (including some prototypes), and most
interestingly, the Mitsumi "Label location" pages usually include pinout &
signal names for the wifi board.

DSi Wifi board pinout
https://fccid.io/EW4DWMW024/Label/Label-format-and-location-1137926.pdf
https://fccid.io/EW4DWMW015/Label/Label-Location-1031953.pdf
  1  MX_SD_CLK    2  GND
  3  GND          4  VDD_18
  5  SDIO_DATA0   6  VDD_18
  7  SDIO_DATA3   8  GND
  9  SDIO_DATA1   10 VDD_33
  11 SDIO_CMD     12 VDD_33
  13 SDIO_DATA2   14 GND
  15 JTAG_TDO     16 ATH_TX_H
  17 JTAG_TMS     18 SYS_RST_L
  19 GND          20 JTAG_TDI
  21 CLK32k       22 JTAG_TCK
  23 GND          24 JTAG_TRST_L
  25 NC(VDD28_TP) 26 SEL_ATH_L
  27 SPI_CS2      28 W_B
  29 BBP_SLEEP    30 SPI_CLK
  31 RF_SLEEP     32 SPI_DO   MISO
  33 RF_SCS       34 SPI_DI   MOSI
  35 BPP_SCS      36 CCA        ;typo: should be BBP (not BPP)
  37 BB_RF_SDO    38 RXPE
  39 BB_RF_SDI    40 TRDATA
  41 BB_RF_SCLK   42 GND
  43 NC(VDD18_TP) 44 TRCLK
  45 GND          46 TRRDY
  47 MCLK         48 TXPE
  49 GND          50 RESET

DS-Lite Wifi board DWM-W006 pinout
https://fccid.io/EW4DWMW006/Label/ID-label-format-and-location-706511.pdf
  1  GND          16 +3.3V
  2  TXPE         17 GND
  3  RXPE         18 RF_SCS
  4  CCA          19 BBP_SLEEP
  5  TRRDY        20 BBP_SCS
  6  GND          21 RF_SLEEP
  7  TRCLK        22 RESET
  8  TRDATA       23 GND
  9  GND          24 SPI_CLK
  10 BB_RF_SDO    25 SPI_DI
  11 BB_RF_SDI    26 SPI_DO
  12 BB_RF_SCLK   27 W_B
  13 GND          28 SIP_CS2     ;typo: should be SPI (not SIP)
  14 MCLK         29 LD
  15 GND          30 GND

Wii Wifi board
https://fccid.io/EW4DWMW004/Label/ID-Label-670426.pdf
  1  GND          12 VDD3.3
  2  SDIO_DATA_2  13 GND
  3  SDIO_DATA_1  14 GPIO_0
  4  GND          15 GND
  5  SDIO_CLK     16 SDIO_DATA_3
  6  GND          17 SDIO_DATA_0
  7  GPIO_1       18 GND
  8  GND          19 SDIO_CMD
  9  N.C.(VDD1.8) 20 GND
  10 N.C.(VDD1.8) 21 ANT_A (MAIN)
  11 VDD3.3       22 ANT_B (AUX)

3DS Wifi Board DWM-W028
https://fccid.io/EW4DWMW028/Label/ID-label-location-1272988.pdf
  1  MCLK         2  RF_CSRF
  3  GND          4  BB_CSBB
  5  RXPE         6  BB_RF_SDIN
  7  TXPE         8  BB_RF_SDOUT
  9  CCA          10 BB_RF_SCK
  11 TRDATA       12 GND
  13 TRCLK        14 BBP_SLEEP_L
  15 TRRDY        16 RF_SLEEP_L
  17 TRST_L       18 SEL_ATH_L
  19 GND          20 GND
  21 SDIO_DATA_0  22 JTAG_TDO
  23 SDIO_DATA_1  24 JTAG_TMS
  25 SDIO_DATA_2  26 JTAG_TDI
  27 SDIO_DATA_3  28 JTAG_TCK
  29 GND          30 SPI_CS2
  31 SDIO_CLK     32 W_B
  33 GND          34 SPI_CLK
  35 SDIO_CMD     36 SPI_DO
  37 UART_TXD     38 SPI_DI
  39 UART_RXD     40 SYS_RST_L
  41 GND          42 ATH_TX_H
  43 CLK32k       44 RESET
  45 GND          46 GND
  47 VDD_18       48 VDD_33
  49 VDD_18       50 VDD_33
Functionally same as DSi, but not pin-compatible, and with two UART pins
(instead of the NC pins).
The missing part are pinouts for original NDS-Wifi-boards. However, the DS-Lite board pinout could be used to rev-engineer the MM3155-chip pinout, and the MM3155-chip pinout could be then used to rev-engineer the NDS-Wifi-board pinout (not that that would be too useful for any practical purposes, but it's interesting to know what each pin is good for, and sometimes it does actually help to better understand the hardware capabilities).