Luigi's notes about WiFi

From DeSmuME
(Difference between revisions)
Jump to: navigation, search
(Back into desmume)
(Unemulated/incomplete features that could break it)
Line 70: Line 70:
 
* 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)
* Hardware sets duration of incoming packets automatically in some cases? The management frames exchanged between Mario and Luigi have their durations set to zero, however real-life capture shows that those frames have their duration set to 162. Does Nintendo's hardware do this (and more importantly, does Nintendo's software care), or is it just a specificity of the 'wifimax' dongle used to capture real-life traffic?
+
* When receiving a packet, its duration field should be set to something, but what? Also, does Nintendo's software care about this?
  
 
==NSMB wifi code==
 
==NSMB wifi code==

Revision as of 19:52, 13 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.

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?)
  • USCOUNTER bit0 (current method incorrect, yet works better than anything else)
  • TXBUF_TIM (what are we supposed to do with this register? does the host automatically fills in the TIM in sent beacons?)
  • 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?

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