Nintendo wifi config utility

From DeSmuME
(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
The Nintendo wifi config utility is an utility that's provided with most wifi-compliant games.  
+
The Nintendo wifi config utility is an utility that's provided with most wifi-compliant games. <br>
 
It allows the user to easily connect to an access point.
 
It allows the user to easily connect to an access point.
  
Line 6: Line 6:
  
  
The utility doesn't rely on beacons to find access points. It does active scanning.
+
The utility doesn't rely on beacons to find access points. It does active scanning.<br>
 
It sends probe request frames periodically and examinates the probe responses received from access points.
 
It sends probe request frames periodically and examinates the probe responses received from access points.
  
  
The problem is that, on DeSmuME, that util doesn't seem to like the probe responses generated by SoftAP.
+
The problem is that, on DeSmuME, that util doesn't seem to like the probe responses generated by SoftAP.<br>
It always overwrites the first few bytes of the response. It seems to want to read the packet header, but  
+
It always overwrites the first few bytes of the response. It seems to want to read the packet header, but <br>
 
instead it'll read at the end of the packet. The possible causes of that problem are:
 
instead it'll read at the end of the packet. The possible causes of that problem are:
  
Line 19: Line 19:
  
  
After investigating, I found that the util wants to read two values in the RX header (frame type and  
+
After investigating, I found that the util wants to read two values in the RX header (frame type and <br>
transfer rate), but instead of reading them at <packet_start> and <packet_start + 0x6>, it reads them at
+
transfer rate), but instead of reading them at <packet_start> and <packet_start + 0x6>, it reads them at<br>
 
<u16[packet_start+0x8] + 0xC> and <u16[packet_start+0x8] + 0x12>.
 
<u16[packet_start+0x8] + 0xC> and <u16[packet_start+0x8] + 0x12>.
  
  
Here are the instructions executed when the util accesses what should be the first halfword of the packet
+
Here are the instructions executed when the util accesses what should be the first halfword of the packet<br>
 
(but is the halfword located right after the packet body):
 
(but is the halfword located right after the packet body):
  
 
<font face="Courier New">
 
<font face="Courier New">
<nowiki>E1A01087        mov r1, r7, lsl 1      ; r1 = (r7 << 1); </nowiki>
+
<nowiki>E1A01087        mov r1, r7, lsl 1      ; r1 = (r7 << 1); </nowiki><br>
<nowiki>E59F02A8        ldr r0, [pc, +2A8]    ; r0 = word[pc + 0x2A8]; </nowiki>
+
<nowiki>E59F02A8        ldr r0, [pc, +2A8]    ; r0 = word[pc + 0x2A8]; </nowiki><br>
<nowiki>E0800087        add r0, r0, r7        ; r0 += r7; </nowiki>
+
<nowiki>E0800087        add r0, r0, r7        ; r0 += r7; </nowiki><br>
<nowiki>E2811512        add r1, r1, 4800000    ; r1 += 0x4800000; </nowiki>
+
<nowiki>E2811512        add r1, r1, 4800000    ; r1 += 0x4800000; </nowiki><br>
<nowiki>E2811901        add r1, r1, 4000      ; r1 += 0x4000; </nowiki>
+
<nowiki>E2811901        add r1, r1, 4000      ; r1 += 0x4000; </nowiki><br>
<nowiki>E1D110B0        ldrh r1, [r1, +0]      ; r1 = halfword[r1]; </nowiki>
+
<nowiki>E1D110B0        ldrh r1, [r1, +0]      ; r1 = halfword[r1]; </nowiki><br>
 
</font>
 
</font>

Revision as of 20:42, 30 May 2009

The Nintendo wifi config utility is an utility that's provided with most wifi-compliant games.
It allows the user to easily connect to an access point.


The goal is to get this utility to recognize SoftAP (the software access point inside DeSmuME).


The utility doesn't rely on beacons to find access points. It does active scanning.
It sends probe request frames periodically and examinates the probe responses received from access points.


The problem is that, on DeSmuME, that util doesn't seem to like the probe responses generated by SoftAP.
It always overwrites the first few bytes of the response. It seems to want to read the packet header, but
instead it'll read at the end of the packet. The possible causes of that problem are:

  1. incorrect wifi emulation
  2. unknown wifi mode
  3. CPU bug


After investigating, I found that the util wants to read two values in the RX header (frame type and
transfer rate), but instead of reading them at <packet_start> and <packet_start + 0x6>, it reads them at
<u16[packet_start+0x8] + 0xC> and <u16[packet_start+0x8] + 0x12>.


Here are the instructions executed when the util accesses what should be the first halfword of the packet
(but is the halfword located right after the packet body):

E1A01087 mov r1, r7, lsl 1 ; r1 = (r7 << 1);
E59F02A8 ldr r0, [pc, +2A8] ; r0 = word[pc + 0x2A8];
E0800087 add r0, r0, r7 ; r0 += r7;
E2811512 add r1, r1, 4800000 ; r1 += 0x4800000;
E2811901 add r1, r1, 4000 ; r1 += 0x4000;
E1D110B0 ldrh r1, [r1, +0] ; r1 = halfword[r1];

Personal tools