Page 3 of 5

Re: DSi Wifi rev-engineering

Posted: Sun Dec 16, 2018 4:38 pm
by nocash
Got it. The "Key Data" isn't using AES-CCM at all, instead it's encrypted using "AES Key wrap" (and requires "unwrap" to decrypt it).
I've got the "Key Data" from WPA2 Data #3 decrypted (using 80x86 code), and actually found the values for 2nd ADD_CIPHER in there.
The DSi hardware doesn't support "raw AES decrypt" (only AES-CTR and AES-CCM), so I'll definetly need to implement AES in software.

I think I have now found all major stuff needed for WPA2. What's still missing is understanding WPA, I guess it's using MD5 instead of SHA1, and RC4 instead of the AES Key wrap, well, and if that is working, then one could probably also implement WPA on NDS (which would bring up more problems on figuring out the lower-level packet structure for WPA).

Re: DSi Wifi rev-engineering

Posted: Sat Dec 22, 2018 10:28 pm
by nocash
WPA2 and WPA are now more or less working with DSi-Wifi!

I've tested WPA2 on three access points. Two are working fine, the third is successfully passing WPA2 handshakes and exchanging DHCP data packets, but, thereafter, somehow refuses to respond to wifiboot broadcast messages.
I've also tested one of the access points in WPA mode, that's working fine, too. Except, the console somehow gets stunned when hitting the power button after WPA uploads: Wifi stops working, even when switching power off for several minutes. Must be some warmboot flag lurking in memory, one workaround is running the Launcher to resurrect wifi, but I hope I'll find a better solution for that.

There are still a dozen smaller issues, and one major issue would be increasing the transfer speed via NDMA. Plus some work on documenting the initialization sequence, and the parameters for WMI messages.

Re: DSi Wifi rev-engineering

Posted: Wed Jan 02, 2019 12:20 am
by nocash
I've rewritten the MBOX Transfer Headers with new findings added:

Code: Select all

MBOX Send Header/Body
  00h 1    Type        (00h=BootInfo, 01h=WMI Command, 02h=Data Packet)
  01h 1    Request Ack (00h=No, 01h=Yes)
  02h 2    Length of entries [06h..end]  (LEN)
  04h 2    ?
  06h LEN  Body (BootInfo/Event/Data)
  ..  ..   Padding to 80h-byte boundary (for SDIO block size 80h)
Send Body for BootInfo:
  06h ..   related to BE/BK/VI/VO stuff (best effort, background, video, voice)
Send Body for WMI Commands:
  06h 2  WMI Command Number
  08h .. Parameters
Send Body for Data Packets:
  06h 2  <Unknown6>?? 0000h or 1C00h    ;maybe whatever ?
  08h 6  Destination (MAC Addr of Router) (or FF:FF:FF:FF:FF:FF=Broadcast)
  0Eh 6  Source      (MAC Addr of DSi console)
  14h 2  Length Data at [16h...]  ;(LEN1-10h)   ;<-- BIG-ENDIAN !!!
  16h .. Data (usually starting with LLC stuff, ie. AAh,AAh,03h,00h...)
Send Body for empty Data Packets (used when changing WPA/WPA2 CIPHER keys):
  06h 1  Garbage (usually LSB of a previously used WMI command number)
  07h 1  Unknown (02h)

MBOX Receive Header/Body
  00h      1    Type        (00h=Ack only, 01h=WMI Event, 02h=Data Packet)
  01h      1    Ack Present (00h=No, 02h=Yes)
  02h      2    Length of entries [06h..end]     (LEN1+LEN2)
  04h      1    Length of Ack at [06h+LEN1..end] (LEN2) ;garbage when [01h]=00h
  05h      1    ? (00h,20h?,7Fh,F4h,FFh)
  06h      LEN1 Body (Event/Data)
  06h+LEN1 LEN2 Ack List
  ..       ..   Padding to 80h-byte boundary (for SDIO block size 80h)
Receive Body for Ack only:
  06h -  N/A (or boot request info; occurs only shortly after BMI)
Receive Body for Events:
  06h 2  WMI Event Number
  08h .. Parameters
Receive Body for Data Packets:
  06h 1  RSSI (Received Signal Strength Indicator) (00h..3Ch) (aka 0..60)
  07h 1  <Unknown7> 00h
  08h 6  Destination (MAC Addr of DSi console) (or FF:FF:FF:FF:FF:FF=Broadcast)
  0Eh 6  Source      (MAC Addr of Router)
  14h 2  Length of Data entries at [16h..(end-xtracrap)]   ;<-- BIG-ENDIAN !!!
  16h .. Data (usually LLC stuff, ie. AAh,AAh,03h.. or, once F0h,F0h,03h..??)
Ack List (can contain multiple List items):
  X+00h  List Item Type (01h=Ack, 02h=Lookahead)
  X+01h  List Item Len (02h*N for Ack's, 06h for Lookahead)
  X+02h  List Item data
Ack Items (can contain multiple Ack items):
  Y+00h  Ack Item Type (01h=Command Ack, 02h=Data Ack, 05h=Data Ack, too?)
  Y+01h  Ack Item Count? (usually 1) (or 2 for double-ack?)
Lookahead Item (if valid: allows to omit reading Func[1:00408h]):
  Z+00h  Lookahead valid ID1 (00h=No, 55h=Valid)
  Z+01h  Lookahead MBOX0 (or garbage if ID1/ID2 not valid)
  Z+05h  Lookahead valid ID2 (00h=No, AAh=Valid)
With that description, I can now recognize similar definitions in "htc.h", for example, what I've called "Ack List" is officially called "Trailer". And the "Ack Item Count" is apparently called "Credits". I guess one could send multiple data packets up to a certain buffer size limit, and use the Credits reply to determine how many of the sent-packets are already processed (no longer taking up buffer space).
Unfortunately, "htc.h" doesn't contain definitions for all bytes, eg. [05h] and [07h] are still unknown.

Re: DSi Wifi rev-engineering

Posted: Wed Jan 02, 2019 3:28 am
by nocash
And, here's a rundown on what values could found in EAPOL handshake messages, extracted from multiple sources.

Code: Select all

Wifi WPA/WPA2 Handshake Messages (EAPOL)

4-Way Handshake and Group Key Handshake messages
For WPA, the Group Key Handshake occurs immediately after the 4-way Handshake
(effecitively making it a 6-way handshake). For WPA2, the Group Key is
contained in the 4-way Handshake, so the Group Key Handshake isn't needed.
For both WPA and WPA2, the access point may change the Group Key every once and
then, and invoke a new Group Key Handshake for the new key.

EAPOL Key Frame
This is preceeded by a LLC/SNAP header (AAh,AAh,03h,00h,00h,00h,88h,8Eh), the
888Eh in last two bytes indicates that following bytes to contain an EAPOL Key
  00h  2    Version/Type (or Type/Version?) (01 03)
  02h  2    Length of [04h..end] (005Fh+LEN)                      ;BIG-ENDIAN
  04h  1    Descriptor Type (FEh=WPA, 02h=WPA2)
  05h  2    Key Information (flags, see below)                    ;BIG-ENDIAN
  07h  2    Key Length (0=None, 20h=TKIP, 10h=CCMP, 05h/0Dh=WEP)  ;BIG-ENDIAN
  09h  8    Key Replay Counter (usually 0 or 1 in first message)  ;BIG-ENDIAN
  11h  32   Key Nonce (ANonce/SNonce)
  31h  16   Key Data IV (RC4 uses IV+KEK) (not used for AES-Key-Wrap)
  41h  8    Key RSC (TSC/PN) (whatever, for GTK)               ;LITTLE-ENDIAN
  49h  8    Reserved (zerofilled)
  51h  16   Key MIC on [00h..end] (with MIC initially zerofilled)       ;HMAC
  61h  2    Key Data Length (LEN) (00 nn)                         ;BIG-ENDIAN
  63h  LEN  Key Data (can be encrypted in certain messages)

Key Information flags
  0-2   Key Descriptor Version (0=WPA/MD5/RC4, 1=WPA2/SHA1/AESkeywrap)
  3     Key Type (0=Group, 1=Pairwise)
  4-5   Reserved (0) or WPA Group Key Index (1 or 2)
  6     Install  (0=No, 1=Yes, configure temporal key)
  7     Key Ack  (0=No, 1=Yes, AP wants a reply; with same Key Replay Counter)
  8     Key MIC  (0=No, 1=Yes, key frame contains MIC)
  9     Secure   (0=No, 1=Yes, initial key-exchange complete)
  10    Error    (0=No, 1=Yes, MIC failure and Request=1)
  11    Request  (0=No, 1=Yes, request AP to invoke a new handshake)
  12    Encrypted(0=No, 1=Yes, Key Data is encrypted; via RC4 or AESkeywrap)
  13-15 Reserved (0)

Key Data
Key Data does usually consist of element(s) in following form:
  00h 1   Element ID (for WPA: DDh=RSNIE - for WPA2: 30h=RSNIE, DDh=KDE)
  01h 1   Element Length of [02h..end]
  02h ..  Element Data (OUI's etc.)
WPA and WPA2 assign different meanings to Element ID value DDh. The 3-byte
maker prefix in OUI values does also differ for WPA/WPA2. And, the meaning of
the OUI's varies depending on WHERE they are used (eg. 00-0F-AC-02 could be a
Cipher Suite entry, or an Authentication entry):
  EAPOL Descriptor Type values
  WPA          WPA2         Meaning
  FEh          02h          Indicates if ElementIDs and OUIs are WPA or WPA2
  EAPOL Key Information flags/values
  0089h        008Ah        Handshake #1  ;\
  0109h        010Ah        Handshake #2  ; 4-way Handshake
  01C9h        13CAh        Handshake #3  ;
  0109h(again) 030Ah        Handshake #4  ;/
  0391h/03A1h  1382h        Handshake #5  ;\Group Key Handshake
  0311h/0321h  0302h        Handshake #6  ;/
  EAPOL Key Data Element IDs
  DDh          30h          Element ID for RSNIE (Robust Network Security info)
  -            DDh          Element ID for KDE (Key Data Encapsulation)
  -            DDh          Element ID for padding (followed by 00h-bytes)
  RSNIE Version Prefix OUI's (WPA only):
  00-50-F2-01  -            RSNIE Version Prefix (followed by 2 bytes?)
  RSNIE Group Cipher suite selector OUI's (aka Multicast):
  00-50-F2-01  00-0F-AC-01  RSNIE Group Cipher WEP-40  (default for US/NSA)
  00-50-F2-02  00-0F-AC-02  RSNIE Group Cipher TKIP    (default for WPA)
  00-50-F2-04  00-0F-AC-04  RSNIE Group Cipher CCMP    (default for WPA2)
  00-50-F2-05  00-0F-AC-05  RSNIE Group Cipher WEP-104 (default for WEP)
  RSNIE Pairwise Cipher suite selector OUI's (aka Unicast):
  00-50-F2-00  00-0F-AC-00  RSNIE Pairwise Cipher None (WEP, Group Cipher only)
  00-50-F2-02  00-0F-AC-02  RSNIE Pairwise Cipher TKIP (default for WPA)
  00-50-F2-04  00-0F-AC-04  RSNIE Pairwise Cipher CCMP (default for WPA2)
  RSNIE Authentication AKM suite selector OUI's :
  00-50-F2-01  00-0F-AC-01  RSNIE Authentication over IEEE 802.1X
  00-50-F2-02  00-0F-AC-02  RSNIE Authentication over PSK
  KDE Key Data Encapsulation OUI's (WPA2 only):
  -            00-0F-AC-01  KDE GTK         (followed by 2+N bytes)
  -            00-0F-AC-02  KDE STAKey      (followed by 2+6+N bytes)
  -            00-0F-AC-03  KDE MAC address (followed by 6 bytes)
  -            00-0F-AC-04  KDE PMKID       (followed by 16 bytes)

RSNIE (Robust Network Security Information Element)
RSNIE allows to exchange information about the desired/supported encryption
methods. RSNIE is found in handshake message 2/3 (and also in Beacons). In most
cases one could just ignore the RSNIE stuff (eg. if Wifi FLASH is already
configured to use a specific cipher type). A special case might be networks
that use a weaker Group Cipher (for older devices) combined with offering
stronger Pairwise Ciphers (for devices that support them).
  WPA2 RSNIE (Robust Network Security Information Element):
  00h  1  Element ID (30h=RSNIE for WPA2)
  01h  1  Element Len of [02h..end] (usually 14h)
  02h  2  RSNIE Version 1                        (01 00)     ;WHATEVER-ENDIAN?
  04h  4  RSNIE Group Cipher Suite OUI (CCMP)    (00 0F AC 04)
  08h  2  RSNIE Pairwise Cipher Suite Count (1)  (01 00) (in  ;LITTLE-ENDIAN
  0Ah  4  RSNIE Pairwise Cipher Suite OUI (CCMP) (00 0F AC 04)
  0Eh  2  RSNIE Authentication Count (1)         (01 00)      ;LITTLE-ENDIAN
  10h  4  RSNIE Authentication OUI (PSK)         (00 0F AC 02)
  14h  2  RSNIE Capabilities                     (00 00)      ;LITTLE-ENDIAN?
  16h (2) RSNIE Optional PMKID Count  ;\usually none such     ;LITTLE-ENDIAN
  18h (16)RSNIE Optional PMKID's      ;/
  WPA RSNIE (Robust Network Security Information Element):
  00h  1  Element ID (DDh=RSNIE for WPA)
  01h  1  Element Len of [02h..end] (usually 16h or 18h)
  02h  4  RSNIE Version OUI (version)   (00 50 F2 01)       ;<-- WPA only
  06h  2  RSNIE Version value? (1)      (01 00)              ;WHATEVER-ENDIAN?
  08h  4  RSNIE Mcast OUI (TKIP)        (00 50 F2 02)
  0Ch  2  RSNIE Ucast Count (1)         (01 00)               ;LITTLE-ENDIAN
  0Eh  4  RSNIE Ucast OUI (TKIP)        (00 50 F2 02)
  12h  2  RSNIE Auth AKM Count (1)      (01 00)               ;LITTLE-ENDIAN
  14h  4  RSNIE Auth AKM OUI (PSK)      (00 50 F2 02)
  18h (2) RSNIE Capabilities maybe?     (00 00)               ;LITTLE-ENDIAN?
  RSN Capabilities flags (usually 0000h) (also spotted: 0C 00):
  0   RSN Pre-Auth capabilities
  1   RSN No Pairwise capabilities
  2-3 RSN PTKSA Replay Counters (0..3 = 1,2,4,16 replay counters)
  4-5 RSN GTKSA Replay Counters (0..3 = 1,2,4,16 replay counters)
  6   Managment Frame Protection Required
  7   Managment Frame Protection Capable
  8   Joint Multi-band RSNA
  9   PeerKey Enabled
  10  SPP A-MSDU Capable
  11  SPP A-MSDU Required
  12  PBAC
  13  Ext Key ID for Unicast
  14-15 Reserved (0)

KDE Key Data Encapsulation (or raw data for WPA)
KDE (or WPA's raw data) is mainly useful for transferring the GTK group key.
Note that Key Data in WPA2 message 3 contains both RSNIE and KDE GTK (and KDE
padding). Whilst the raw data in WPA cannot be mixed RSNIE.
  WPA2 KDE GTK (Key Data Encapsulation for Group Key, in encrypted Key Data):
  00h  1   Element ID (DDh=KDE for WPA2)
  01h  1   Element Len (16h)
  02h  4   KDE OUI GTK (00-0F-AC-01) (occurs in message 3/5)
  06h  1   KDE GTK Key ID (01h or 02h)      ;bit2: Tx ?
  07h  1   KDE GTK Reserved (00h)
  08h  16  KDE GTK Key GTK (for Key ID from above byte [06h])
  WPA2 KDE PKMID (Key Data Encapsulation for PKMID) (optional, not needed):
  00h  1   Element ID (DDh=KDE for WPA2)
  01h  1   Element Len (14h)
  02h  4   KDE OUI PMKID (00-0F-AC-04) (optionally occurs in message 1)
  06h  16  KDE PMKID (useless checksum on PMK, sometimes exposed in message 1)
  WPA2 KDE Padding (for padding Key Data to Nx8 bytes for AES-Key-wrap):
  00h  1   Element ID (DDh=KDE for WPA2)
  01h  0-6 Padding (00h) (aka Element Len=00h)
  WPA GTK (raw Group Key; without Element ID or KDE-style encapsulation):
  00h  16  Key GTK (for Key ID from Key Information bit4-5) (in message 5)
I hope that's more or less complete and covers all important stuff. I couldn't find specs for the endianness of RSNIE Version and RSNIE Capabilites, so I will leave that as unknown/undefined for now. If I should guess, I assume Version is little endian, ie. 01 00 meaning 0001h=v1 (or who knows, it might also mean 0100h=v1.00). And for Capabilities, there is (hopefully) some common practice to use a specific endiannes for it (at least one source suggests that it's meant being little endian).

I am still having problems to connect to one of my WPA2 access points.
One uncommon thing is that it does expose the KDE PMKID stuff in message 1 (my other access points don't do that). But I am quite that that's just some unimportant oddity.
The other uncommon thing is that it does report 0C 00 in RSNIE Capabilities. Which, that's pretty much unclear what it means (and if it's important at all).
If it's little endian, 000Ch, then the access point does have 16 PTK replay counters (probably referring to the "RSC/TSC", not to the EAPOL Replay Count) (though even if so, it's quite possible that the DSi doesn't need to care about whether the access point supports that many counters).
If it's big endian, 0C00h, then the access point does have/require SPP-A-MSDU, whatever that means, SPP seems to be some kind of "protection" and "A-MSDU" seems to be multiple-small-packets merged into one large packet.

The DSi browser can connect to that access point without problems - and apparently without using any special commands or parameters, regardless of the 0C 00 capabilities value. I start to suspect that the problem might be unrelated to handshakes & cipher keys - maybe the access point just dislikes the messages that I am sending during TCP accept or so.

Well, I could/should use something like wireshark to find out if my TCP messages are sent okay, and if the access point is sending any response to that messages. Though I don't really have any (good) experiences with wireshark... from what I remember, it dislikes my hardware (especially for capturing lower-level packets), and even if it's working, it tends to capture an overhelming amount of packets, so it might need quite some patience to dig through the captured data.

Re: DSi Wifi rev-engineering

Posted: Mon Jan 07, 2019 2:54 am
by nocash
Release! - wifiboot v2.4 (binary and source code)

WPA2 is still working with only 2 of 3 tested access points. When testing it, please let me know if it's working, or not working with your access point(s).

Transfer speed
When uploading the Eragon demo, I am reaching 300-500Kbytes/s (depending on daytime/noise in the neighborhood) when using a more distant access point, and, for reason, fairly constant 400Kbytes/s when using a closeby access point.
For comparision: NDS-Wifi is reaching about 60Kbytes/s (the measurement last month saying 110Kbyte/s was probably wrong, caused by lost vblank IRQs, which were used as timing reference).
The speed isn't perfect yet, but it's ways faster than NDS-Wifi (even if NDS would ever reach full 2MBit/s). Some things that helped to improve the speed were using NDMA (for SDIO-to-memory), and DMA for (for memory-to-memory), and WRAM (for the packet buffer), and, especially: setting the ARM7_RUNNING flag (else SDIO was handled only on vblank IRQs, not on SDIO IRQs, which had frustatingly caused more packets to get 'lost' (which did then cause slowdown whenever trying to speedup things)).
Next thing to try would be running ARM7 code in WRAM or VRAM instead of slow Main RAM, maybe that will boost the transfer speed a bit more.

How to use
Configure your access point in DSI System Settings --> Internet --> Advanced Setup (the advanced stuff supports WPA/WPA2).
Load wifiboot.nds (when using unlaunch: observe that it does contain a built-in older wifiboot version in eMMC, be sure to use the newer wifiboot version (loaded from SD card); if you want to use wifiboot more often, best assign a hotkey to it, or make it the boot default).
On PC side, you can use no$gba --> Utility --> Upload (and set Options --> Other --> Multiboot Port to "Dslink/Wifi"). Or use the dslink.exe commandline tool from devkitpro. Uploading should work for any nds/dsi homebrews that rely on using only their bootcode blocks (without loading further data from cartridge ROM after booting).

Now that WPA/WPA2 are working (including manually handling the EAPOL messages), there's no good reason not to implement WPA for NDS-Wifi, too. The main issue might be making a GUI for entering WPA passwords on NDS, apart from that it should only require some extra tweaking on manually adding the Extended IV and MIC to the WPA packets.
The DSi would benefit from a GUI, too (system settings are prompting to re-enter the password anytime when switching between WPA and WPA2, which is a bit uncomfortable for testing). Well, and I hope I'll get the transfer a bit faster, and fix the isssue with the non-working access point.

Source code
Copy the .zip contents to no$gba's "stuff" subfolder, then use Utility --> Assemble File --> wifiboot.a22 in no$gba. For use with other assemblers you would probably need to change hex numbers from 1234h to something like 0x1234 or #0x1234. I am wondering if anybody will be able or willing to do such things ; ) if you want to: maybe better wait a while and check back if there are newer updates/bugfixes before porting to source code to other formats.
Changes to the old NDS-Wifi code are marked "with_nds_wifi" and "with_dsi_wifi" (in wificore.a22). The new DSi-Wifi code is currently mostly located in wifiboot.a22 and wifisdio.a22 (I'll move that to wificore.a22 in future versions).

Thanks to Stephen Stair for making the original NDS-Wifi library (dswifi) and to wintermute for the original wifi uploader (dslink).

Re: DSi Wifi rev-engineering

Posted: Thu Jan 10, 2019 3:38 pm
by edo9300
I tried the new wifiboot, and even if the ds seems to recognize the network, it won't connect. I attached the output of the program.

Re: DSi Wifi rev-engineering

Posted: Fri Jan 11, 2019 2:54 am
by nocash
The 03 10 in upper right of the hexdump means DISCONNECT event (1003h), usually that means wrong password or too weak signal strength.
CRYPT: OPEN means that you have configured the access point as "open network" in DSi system settings, without using any WEP/WPA/WPA2 password. Is that right? I thought you had mentioned using WPA2 in the unlaunch thread.
RSSI: 0 is pretty weak signal strength, quite possible that it can see the access point - but fail to connect to it. It will probably work better if you get closer to access point, something like RSSI: 20...60 should be fine.
CHANNEL: 2 should work (but wifiboot is scanning the standard channels (1, 6, 11) first, so those might work a bit faster).
PM: 1 new messages in your browser means that I was hoping that you might test wifiboot, but you seem to have found the update without seeing the message : )

I have spent the last some days on researching the country code in the REG_DOMAIN event. The AR6002 ROM contains a database with settings for 112 countries (though 5 of them are dummy/debug entries). The actual/local 10bit country code is stored in I2C EEPROM byte[08h..09h]. The Country selection in DSi System Settings doesn't affect the Wifi-country.
The obvious country specific thing is number of 2.4GHz channels, usually 1-13, or 1-11. But there are some other differences that I wasn't aware of. Most interestingly, Tx power is 100mW (20dB) in most of the world, but canada/mexico/taiwan/usa/etc. have 500mW (27dB), and newzealand/belize/bolivia/venezuela do even have 1000mW (30dB).
For some reason, there are also 5GHz channels in the database (although AR6002 shouldn't support that, maybe 5GHz could/should be supported on AR6013/AR6014, although Nintendo claims that DSi and 3DS support 2.4GHz only). And, the database contains a bunch of additional flags, which I couldn't guess which flag has which meaning; most of them are probably 5GHz-specific, like indoor/outdoor flag etc.
Some related docs: - ISO country codes - Atheros countries ... 4f8/db.txt - official atheros "db.txt" source (click "log" for older versions, which may be closer to DSi era)

Now I am wondering if Nintendo has actually used wifi boards with appropriate country codes when selling DSi consoles. There seems to be no country info on the daughterboard stickers (and the sticker with the model no may be hidden underneath of a black isolation/sticker anyways). And, my european DSi came with japanese wifi board (country 188h), that looks wrong - but it might be no real problem in practice as japan uses 100mW, too, and uses only ch1-13, too (theoretically japan could have unlocked ch14, but that seems to be depracted in newer ieee standards). And, as long as the access point is using standard channel 1, 6, or 11, it won't matter if the console has channel 12-13 (or 14) enabled or disabled.

However, the Tx power might have some more serious ups and downs. If it's too weak then you can't connect to access points that would be within reach. And if it's too high... worst would be disturbing the neighborhood, raising battery consumption, overheating the console, without actually improving anything (assuming that access point can't reply at same strength)... unless the wifi unit does somehow automatically use only as much as actually needed; the browser uses POWER_MODE command with setting MAX_PERF_POWER (whatever that means, MAX doesn't sound good), the other option would be REC_POWER (whatever that means).

Confusingly, Wifi-FLASH does also have an entry with enabled channels (for NDS Wifi), which appears to be always set to 3FFEh aka channel 1-13 on all NDS and DSi consoles (even on US wifi boards that allow only channel 1-11 for DSi Wifi). This setting is used for local networking (eg. local multiplayer, ds download play, pictochat), whereas, those seem to use the first/middle/last of those enabled channels, ie. 1,7,13, probably randomly picking one of those channels. I am not sure if/how that complies with FCC rules in many countries (unless I've missed a software layer that masks off channel 13). Hmmm, does have some smallprint (in the "Notes" at the very bottom of the page) stating the channel 12-13 were perfectly legal even in usa, as long as they are used at "low-power" (whatever that means). Canada has a similar rule for ch12 (but doesn't permit ch13).

Re: DSi Wifi rev-engineering

Posted: Fri Jan 11, 2019 4:05 am
by edo9300
Weird, I tested the connection before launching wifiboot, and I connected fine, could it be that it read the network info from the saved wep networks? I'm not sure but if iirc I had the first network configured as open with that ssid, maybe it read from.there instead of from the advanced network settings?

Re: DSi Wifi rev-engineering

Posted: Fri Jan 11, 2019 8:29 am
by nocash
Yes, if you are using the same SSID in two entries won't work. Easy workaround would be to delete the other entry.

Re: DSi Wifi rev-engineering

Posted: Fri Jan 11, 2019 12:06 pm
by edo9300
Ok, i tested again, both with my home network after removing the duplicate entries and also using my phone as hotspot with wpa2 protection, and in both the cases it got stuck at "connecting".
As for your message, i really didn't notice it, as i come to the site after the mail notifications, and i received none for the pm...

Re: DSi Wifi rev-engineering

Posted: Sat Jan 12, 2019 12:19 pm
by nocash
It's showing only "Nocash Wifiboot v2.4" and "Connecting"? That would be still miles away from any possible problems with the new code. Troubleshooting for connecting:
Make sure that you do use wifiboot v2.4, not the older v2.3 version in unlaunch
Make sure that the access points use channel 1..11, not 12,13,14
Make sure that you didn't accidentally delete the WPA2 settings alongsides with the open network settings
Make sure that you didn't forget to configure your phone hotspot in system settings
Make sure that you didn't mis-spell the SSID's
Make sure that signals are strong enough, if neccessary get closer to the access point
Theoretically there should be no problem in the connecting/scanning stage as that part did work when you had it configured as open network. The scanning is basically searching for an access point that broadcasts one of the SSID strings that you had configured in system settings, there isn't much that could get wrong there, in theory.

One thing that I should have mentioned is that the new WPA/WPA2 features are currently supporting only WPA-TKIP and WPA2-AES (system settings does also allow using more obscure variants like WPA-AES and WPA2-TKIP).
And, if the access point is configured to support both WPA and WPA2, I haven't tested that combination yet. It would probably fail when using WPA2 on DSi side, but should work for WPA on DSi side.
Though that two issues shouldn't affect the connecting/scanning stage (but you might run into that issues later on).

Re: DSi Wifi rev-engineering

Posted: Sun Jan 13, 2019 7:26 am
by edo9300
I tested with all the network encryptions available for my router, so WPA, wpa2 and WPA+wpa2, and I also manually put the channel to 1, to be sure it was in the supported range, but I still had no success in connecting, in the dsi settings it put all the passwords (the one for WPA too) as aes and not a single time as tkip (so probably WPA one didn't work for that, as you said it only support tkip). Idk if there's something else I should configure to make it work, but as now I had no success. :(

Re: DSi Wifi rev-engineering

Posted: Sun Jan 13, 2019 2:07 pm
by nocash
Hmmm, but you are still seeing only "Nocash Wifiboot v2.4" and "Connecting", and the rest of the screen is blank?
That sounds as if unlaunch isn't seeing the "advanced" access point settings in wifi-flash at all.
Can you dump the wifi-flash? In fwtool it's called "firmware" (because NDS did have the firmware stored in that memory, too). And maybe send the dump per PM (there is some personal stuff like mac address, wifi password, and birthday in there though).
Or check the description below, maybe your settings are somehow different. Most importantly, the byte at [0E7h] should be 00h (for Open/WEP) or 10h (for WPA/WPA2). And the SSID should be correct (and zeropadded).
Btw. did you manually enter the settings, or did you use AOSS/WPS? I have never used AOSS/WPS, and don't know if they would require special actions. AOSS is reportedly storing another value in [0E7h], so wifiboot won't accept that (though, maybe I could just ignore that uncommon value and accept the setting without needing to do anything special).

Code: Select all

Connection data 4 at WifiFlash[00020h]*8-A00h (eg. 01F400h) (DSi only)
Connection data 5 at WifiFlash[00020h]*8-800h (eg. 01F600h) (DSi only)
Connection data 6 at WifiFlash[00020h]*8-600h (eg. 01F800h) (DSi only)
The DSi has three extra 200h-byte regions (for use DSi games, with the new
WPA/WPA2 encryption support, and with additional proxy support), these extra
regions are found under "Advanced Setup" in the DSi firmware's "Internet"
configuration menu.
  Addr Siz Expl.
  000h 32  Proxy Authentication Username (ASCII string, padded with 00's)
  000h 32  Proxy Authentication Password (ASCII string, padded with 00's)
  040h 32  SSID (ASCII string, padded with 00's) (see [0E8h] for length)
  060h ..  Maybe same as NDS
  080h ..  WEP Key (zerofilled for WPA)
  0xxh ..  Maybe same as NDS
  0C0h 4   IP Address           (0=Auto/DHCP)
  0C4h 4   Gateway              (0=Auto/DHCP)
  0C8h 4   Primary DNS Server   (0=Auto/DHCP)
  0CCh 4   Secondary DNS Server (0=Auto/DHCP)
  0D0h 1   Subnet Mask (0=Auto/DHCP, 1..1Ch=Leading Ones) (eg. 6 = FC.00.00.00)
  0D1h ..  Unknown (zerofilled)
  0E6h 1   WEP (00h=None/WPA/WPA2, 01h/02h/03h/05h/06h/07h=WEP, same as NDS)
  0E7h 1   WPA (00h=Normal, 10h=WPA/WPA2, or FFh=unused/deleted)
  0E8h 1   SSID Length in characters (01h..20h, or 00h=unused)
  0E9h 1   Unknown (usually 00h)
  0EAh 2   MTU Value (Max transmission unit) (576..1500, usually 1400)
  0ECh 3   Unknown (usually 00h-filled)
  0EFh 1   bit0/1/2 - connection 4/5/6 (1=Configured, 0=Not configured)
  0F0h 14  Zerofilled (or maybe ID as on NDS, if any such ID exists for DSi?)
  0FEh 2   CRC16 for Entries 000h..0FDh (with initial value 0000h)
  100h 32  Precomputed PSK (based on WPA/WPA2 password and SSID) ;\all zero
  120h 64  WPA/WPA2 password (ASCII string, padded with 00's)    ;/for WEP
  160h 33  Zerofilled
  181h 1   WPA (0=None/WEP, 4=WPA-TKIP, 5=WPA2-TKIP, 6=WPA-AES, 7=WPA2-AES)
  182h 1   Proxy Enable         (00h=None, 01h=Yes)
  183h 1   Proxy Authentication (00h=None, 01h=Yes)
  184h 48  Proxy Name (ASCII string, max 47 chars, padded with 00's)
  1B4h 52  Zerofilled
  1E8h 2   Proxy Port (16bit)
  1EAh 20  Zerofilled
  1FEh 2   CRC16 for Entries 100h..1FDh (with initial value 0000h) (0=deleted)
The location of the first data block (aka settings number 4) is at the User
Settings address minus A00h, ie. Firmware Header [00020h]*8-A00h.
Observe that NDS consoles do have Firmware bootcode/data in that area, so those
new regions exist on DSi only. Presence of the new regions is indicated in
Firmware Header [001FEh], that byte is usually FFh=NDS or 20h=DSi, the DSi
browser does internally replace FFh by 10h, and does then check if byte>=20h
(ie. the new areas exist if the byte is 20h..FEh).

Re: DSi Wifi rev-engineering

Posted: Thu Jan 17, 2019 7:45 pm
by nocash
I am still fighting with one access point, again and again. I think I've now tracked down the problem to ARP messages getting lost.
The DSi does receive the wifiboot request via UDP, and it does then send a "Who Has" ARP message to (my PC), which is unanswered when using the router as access point, but it's working okay with three other access points. And even with the router, I can send "Who Has" ARP message to (the router itself), which works okay, it's only the "Who Has" for the PC not working.

So... it looks as if the router (or another switch between the router and PC) isn't forwarding the ARP : /

Frustrating issue. I guess I'll have to figure out how many switches and other crap we have in this building. Or try to find a long cable for wiring my PC directly to the router, trying to bypass the problem that way.

My ARP retry handler did have three evil bugs - but fixing them didn't help on the above issue : (
Normally, the ARP is working without needing retries, except on the router, where it's never working with/without retries.

--- Alongsides, some other findings: ---

AR6002 (on older DSi wifi boards) is really worse than AR6013 (on later DSi wifi boards). AR6002 is getting much warmer, and it's also less reliable (occassionally fails on CONNECT command for distant APs, which works flawless with AR6013).

The SET_BITRATE command works only vaguely: It's somehow reaching more than 200Kbyte/s when selecting 1MBit/s ; )

System Settings behaves a bit weird. When using search access point, it detects my router being WPA2-TKIP, despite of the router announcing itself as WPA2-AES in beacons (including AES groupkey). Nethertheless, the connection does somehow pass with the WPA2-TKIP setting, theoretically that can't work at all since the group key is AES, not TKIP. Almost looks as if Nintendo is ignoring their own configuration settings in that case.

Apropos configuration settings: Without more info from edo9300 (or other people with same problem), I will just ignore that issue for now. Maybe there will be bug reports with more details showing up after including the new wifiboot version in the unlaunch package, though it would be also nice to bugfix such issues before including the new wifiboot in unlaunch. Or well, it doesn't matter that much to get everything perfectly working before next release.

Re: DSi Wifi rev-engineering

Posted: Sun Jan 20, 2019 4:27 pm
by nocash
I have added some code for extracting the supported WPA and WPA2 cipher modes from beacons (instead of trusting the cipher mode selection configured in wifi flash).

Displaying the values received from my access points, and changing their access point configurations...
I seem to have most or all expected combinations: WPA-TKIP, WPA-AES, WPA2-TKIP, WPA2-AES, as well as mixed modes WPA2-TKIP/AES, WPA/WPA2-AES, and WPA-TKIP-WPA2-TKIP/AES. So, I could test all that stuff, yipiehyuh, that will probably take some time : /

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

I didn't find access points with WPA-WEP or WPA2-WEP, but I guess that's rarely used, if ever (although it's semi-documented in IEEE specs). Raw WEP networks do just have the WEP set in capability flags, without further WPA/WPA2 info in beacons (which would mainly make sense for backwards compatibility, ie. when supporting TKIP or AES pairwise keys combined with insecure WEP group keys (though I don't know how the group key would be assigned in that case, probably as fixed WEP key, instead of via EAPOL group key handshakes)).

One more obscure finding in my local network is that somebody (not me) has installed a new repeater some days ago, using the same SSID and password as the router - but with a different cipher mode. The router uses WPA2-AES, the repeater uses WPA2-TKIP/AES. So, well, that explains occassional connection problems. I had blamed that on AR6002 being less reliable than AR6013, but now it looks more as if the new repeater made fun of saying "Hello, I pretend being your AES router, and you won't guess that I don't support AES group keys!"