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:
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
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).