Luigi's notes about WiFi

From DeSmuME
(Difference between revisions)
Jump to: navigation, search
(Unemulated/incomplete features that could break it)
Line 73: Line 73:
 
* RXSTAT registers (not emulated at all; perhaps some of them are used for sensing multiplayer cmd/reply packets? -- testing RXSTAT emulation: doesn't seem to change much)
 
* RXSTAT registers (not emulated at all; perhaps some of them are used for sensing multiplayer cmd/reply packets? -- testing RXSTAT emulation: doesn't seem to change much)
 
* USCOUNTER bit0 (current method incorrect, yet works better than anything else)
 
* USCOUNTER bit0 (current method incorrect, yet works better than anything else)
* TXBUF_TIM (possibly the host fills sent beacons' TIMs automatically. The beacon NSMB generates has the TIM set to 05 05 00 02 00 00 00, however it is 05 05 01 02 00 00 00 in real life)
+
* TXBUF_TIM (possibly the host fills sent beacons' TIMs automatically. The beacon NSMB generates has the TIM set to 05 05 00 02 00 00 00, however it is 05 05 01 02 00 00 00 in real life. Test of this doesn't change much either.)
 
* REPLY TX slot (but we aren't to this stage yet. For now Luigi never tried to write anything other than zero into it)
 
* REPLY TX slot (but we aren't to this stage yet. For now Luigi never tried to write anything other than zero into it)
 
* IRQ12 and double IRQ7 when sending from CMD TX slot (how does the 'double IRQ7' thing work? for now only IRQ12 and one IRQ7 are triggered)
 
* IRQ12 and double IRQ7 when sending from CMD TX slot (how does the 'double IRQ7' thing work? for now only IRQ12 and one IRQ7 are triggered)
 
* TXSEQNO increment when sending from CMD TX slot (GBAtek says it's incremented by two, however real-life capture shows that it is incremented by one)
 
* TXSEQNO increment when sending from CMD TX slot (GBAtek says it's incremented by two, however real-life capture shows that it is incremented by one)
 
* When receiving a packet, its duration field should be set to something, but what? Also, does Nintendo's software care about this?
 
* When receiving a packet, its duration field should be set to something, but what? Also, does Nintendo's software care about this?
 +
 +
==Envisaged methods to figure out the wifi shit==
 +
 +
* Reverse-engineering NSMB's ARM7 binary: will most likely be a long, time-consuming, painful process, and perhaps it will not help that much (part of the wifi is done by the ARM9 binary).
 +
* Modifying NSMB so that Luigi dumps its wifi registers when it receives the first data frame from Mario: may be helpful but may as well not be helpful
 +
* Building a fake NSMB Luigi client: not that easy to do. Hardware quirks and/or timing issues prevent it from working. Note: a proper low-level wifi library is needed. dswifi is too high-level for our needs, and some of its functionality may be interfering with the multiplayer comm.
 +
* <del>Decapping the wifi chip and reverse-engineering that</del> means for that lacking
  
 
==NSMB wifi code==
 
==NSMB wifi code==

Revision as of 23:24, 20 December 2011

Contents

Current Wifi state

Wifi is WIP and highly experimental, keep it in mind

  • Ad-hoc: Nintendo multiplayer games fail to connect together. At one point the host sends data frames, the client receives them right but seems to not care about them or throw them out for some reason. Quite possibly a timing problem.
  • SoftAP, WFC: doesn't work. Seems to be due to timing issues.
  • SoftAP, homebrew: I was fckin wrong. With some work, homebrews based on the dswifi lib can now communicate with the internet. For example you can use ClIRC to chat on #desmume (irc.freenode.net, port 6667).

Undocumented hardware stuff

Based on observations on real hardware, may be wrong or incomplete tho.

  • setting bit0 of W_US_COMPARE0 keeps W_BEACONCOUNT1 from triggering IRQ14 until W_US_COUNT matches W_US_COMPARE
    • (emulating this effect causes even worse results than what's done right now in desmume)
  • does setting W_MACADDR to FF:FF:FF:FF:FF:FF let one see all the wifi traffic, like monitor mode on a PC wifi card?

Spying on the traffic

  • Mario sends his beacon
  • Luigi sends a standard auth frame
  • Mario replies with another standard auth frame
  • Luigi sends a standard assoc request
  • Mario replies with a standard assoc response
  • Mario sends this data frame: (data+CF-Poll)

28 02 d8 02 03 09 bf 00 00 00 MM MM MM MM MM MM
MM MM MM MM MM MM SS SS de 01 02 00 00 80

  • Luigi replies with this ack, and nothing else for now:

58 11 fe 01 MM MM MM MM MM MM LL LL LL LL LL LL
03 09 bf 00 00 10 SS SS
(where MMMMMMMMMMMM is Mario's MAC, LLLLLLLLLLLL is Luigi's MAC, and SSSS is the sender's sequence number)

That ack is different from the 'standard' ack, which is regularly sent during the auth/assoc process:
d4 00 00 00 XX XX XX XX XX XX
(where XXXXXXXXXXXX is the recipient's MAC)

In fact, the 'standard' ack is a control frame, while the mysterious one is a CF-Ack frame (data frame, subtype 5). Possibly CF-Ack frames are sent automatically in response to Data+CF-Poll frames? Nope. Seeing the traffic that follows, it can't be.

Back into desmume

Observing the packets that are exchanged, a weird glitch can be observed on Mario's side: the auth and assoc frames sent to Luigi have their sequence control set to zero. All other packets are fine. All of Luigi's packets are fine too.

This is weird, because those packets SHOULD have sequence controls. None of the 'manual sequence control' bits are set when the packets are being sent, so wtf?

Actually, the 'TX sequence control' value is being overwritten with 0 right between the TX start order and TX start IRQ, at 0x037FE658.

The packet data is being copied before the TX start order, but for whatever reason, it is being copied again during the preamble.

Unable to find the reason to this so far, I tried adding a simple hack to fix the sequence number of affected packets before sending them. This made things even worse: Luigi doesn't even try to set TXBUF_REPLY in order to send a reply.

This is like the W_USCOUNTER.Bit0 thing. Emulating more correctly gives worse results. All that is telling something. There definitely is something wrong inside the wifi emulation. But what? Possibly the RFPINS/RFSTATUS thing... possibly something else... argh...


The func that tries to copy the packet too much is at 0x037FB12C.

Actually, I have no idea if the overcopying bug comes from Nintendo's software or desmume's wifi implementation... but its main consequence can be avoided in a non-hackish way. According to GBAtek, pre-transmit packet adjustments, including setting the sequence number, should be done when the TXSTART IRQ is triggered, not before.

Also, when the packets' sequence numbers are correct, Luigi, after having successfully associated with Mario, will set its AID_LOW and AID_HIGH registers to 1, which seems right to me. About TXBUF_REPLY not getting set, well... perhaps the RXSTART handler is actually supposed to set it to zero when the packet doesn't need to be replied to. That would make sense, since it only analyzes the header of the received packet, what about the data coming next? Supposedly, the packet's body is analyzed later, and a reply should be sent...

At 0x023A04F8, there is a function that writes a packet into the wifi RAM, then sets TXBUF_REPLY as to send it. However, it doesn't latch the register, and, oddly, it resets AID_LOW/HIGH to zero. This function has no duplicate in the 0x03XXXXXX region. It also never gets called. TODO: Find potential calls to it, either direct or indirect. No direct branches, no pointers... the function is dead code! Either that, or Nintendo used some weirdass calling convention I'm not aware about. In either case, it is really weird. This function is the only one that can do something interesting with TXBUF_REPLY! Come on! It has to be called from somewhere!

Unemulated/incomplete features that could break it

  • RFSTATUS/RFPINS (kind of hacked atm)
  • RXSTAT registers (not emulated at all; perhaps some of them are used for sensing multiplayer cmd/reply packets? -- testing RXSTAT emulation: doesn't seem to change much)
  • USCOUNTER bit0 (current method incorrect, yet works better than anything else)
  • TXBUF_TIM (possibly the host fills sent beacons' TIMs automatically. The beacon NSMB generates has the TIM set to 05 05 00 02 00 00 00, however it is 05 05 01 02 00 00 00 in real life. Test of this doesn't change much either.)
  • REPLY TX slot (but we aren't to this stage yet. For now Luigi never tried to write anything other than zero into it)
  • IRQ12 and double IRQ7 when sending from CMD TX slot (how does the 'double IRQ7' thing work? for now only IRQ12 and one IRQ7 are triggered)
  • TXSEQNO increment when sending from CMD TX slot (GBAtek says it's incremented by two, however real-life capture shows that it is incremented by one)
  • When receiving a packet, its duration field should be set to something, but what? Also, does Nintendo's software care about this?

Envisaged methods to figure out the wifi shit

  • Reverse-engineering NSMB's ARM7 binary: will most likely be a long, time-consuming, painful process, and perhaps it will not help that much (part of the wifi is done by the ARM9 binary).
  • Modifying NSMB so that Luigi dumps its wifi registers when it receives the first data frame from Mario: may be helpful but may as well not be helpful
  • Building a fake NSMB Luigi client: not that easy to do. Hardware quirks and/or timing issues prevent it from working. Note: a proper low-level wifi library is needed. dswifi is too high-level for our needs, and some of its functionality may be interfering with the multiplayer comm.
  • Decapping the wifi chip and reverse-engineering that means for that lacking

NSMB wifi code

NOTE: THIS CODE IS COPYRIGHT NINTENDO!!! DO NOT PUT IT IN YOUR PROJECTS!!!

ARM assembly code, and, if I amn't too lazy, translation to C++ pseudocode

Packet handling or whatever procedure, 0x037F9F88 -> 0x037FA3C0 (ARM7)
Proc1 1.PNG
Proc1 2.PNG
Proc1 3.PNG
Proc1 4.PNG
Proc1 5.PNG
Proc1 6.PNG
Proc1 7.PNG
Proc1 8.PNG
Proc1 9.PNG
Proc1 10.PNG
Proc1 11.PNG
Proc1 12.PNG
Proc1 13.PNG
Proc1 14.PNG
Proc1 15.PNG
037F:A348 E1C800B0 STRH R0, [R8, #0]
037F:A34C E1A00807 MOV R0, R7, LSL #10
037F:A350 E1A00820 MOV R0, R0, LSR #10
037F:A354 E1C900B4 STRH R0, [R9, #4]
037F:A358 E1C400B0 STRH R0, [R4, #0]
037F:A35C EAFFFF20 B 037F9FE4
label_037fa360:
037F:A360 E3550000 CMP R5, #0
037F:A364 0A00000A BEQ 037FA394
037F:A368 E59F0060 LDR R0, [037FA3D0]
037F:A36C E1D040B0 LDRH R4, [R0, #0]
037F:A370 EB000192 BL 037FA9C0
037F:A374 E3500000 CMP R0, #0
037F:A378 0A000005 BEQ 037FA394
037F:A37C E59F004C LDR R0, [037FA3D0]
037F:A380 E1D000B0 LDRH R0, [R0, #0]
037F:A384 E1540000 CMP R4, R0
Proc1 17.PNG

Personal tools