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).
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.
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)
Unfortunately, "htc.h" doesn't contain definitions for all bytes, eg. [05h] and [07h] are still unknown.
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 Frame: 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 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.
http://problemkaputt.de/wifiboot.zip - 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).
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.
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).
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:
http://www.davros.org/misc/iso3166.html - ISO country codes
http://madwifi-project.org/wiki/UserDocs/CountryCode - Atheros countries
https://kernel.googlesource.com/pub/scm ... 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, https://en.wikipedia.org/wiki/List_of_WLAN_channels 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).
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...
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).
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).
The DSi does receive the wifiboot request via UDP, and it does then send a "Who Has" ARP message to 192.168.1.29 (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 192.168.1.1 (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.
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!"