Nintendo DS ni-fi protocol information

This page will not be updated. The information is being moved to a wiki (page address coming soon) where it can be easily expanded and corrected.

You will find some information regarding the Nintendo DS ni-fi protocol on this page. It has been collected through experimenting and sources on the Web. The information may not be correct and my wireless protocol knowledge is only what I have learnt whilst playing around hacking the DS. You can find some more information on WMB transfers here. Fields are little endian (boo hiss).

The frames are close to the IEEE802.11 standard only deviating by missing some parameters. The DS only uses short preamble.

I do not know much about how things change when more than two DSs are around.

• Beacon Formats
  • Initial 21 bytes
  • WMB Beacons
    • Header bytes
    • Payload
• How to Associate with a Nintendo DS
  • Authentication
  • Pictochat Host
  • WMB Host
• WMB Data Transfer
  • Destination Addresses
  • Host Commands
  • Client Responses

Beacon Formats

When a DS is hosting a Pictochat room or WMB download it acts as an access point and broadcasts beacons. These beacons do not have a SSID parameter. They have a vendor specific tagged parameter. The tag number id 0xDD. The data for this parameter always starts with the three byte sequence 00:09:bf, identifying the parameter as Nintendo.

So the layout of the beacons is as follows:

Initial 21 Bytes

The initial 21 bytes (after the Nintendo ID) appear in all beacons I have seen sent out by a DS. The following table gives values of the bytes when the DS has been doing various things. The descriptions given is a possible function of the byte.

The Blank WMB is the first beacon sent out by a DS after starting up as a WMB host.

WMB Beacons

A WMB host follows the 21 intial bytes with further 112 (although there is no reason why this could not vary as size fields are included). These 112 are divided into two parts, the WMB header (14 bytes) and the payload.

The WMB beacons advertise the download being provided and the current clients connected. The advert beacons come first followed by the client beacon(s). The transmission of the beacons cycles round.

A non advert beacon must be included otherwise a DS will not pick up the beacons.

WMB Header

The game id and stream called this as that is what I have seen them called elsewhere.

The non advert payload marker has a value of 0x00 for beacons contains advert payloads and a value of 0x02 for beacons containing client information (see below).

The sequence number starts at zero for the first advert beacon and increase by one for each beacon transmitted, resetting to zero when the first advert beacon is next transmitted.

A checksum over the bytes following this checksum field to the end of the payload. The checksum is the negated sum of the 16 bit words. It can be computed using the following C code. length is the number of 16 bit words to perform the checksum over.

static uint16_t beacon_checksum(uint16_t *buff, int length) {
  int j;
  uint32_t crc = 0;
  for (j = 0; j < length; j++) {
    crc += buff[j];
  }
  crc = (crc >> 16) + (crc & 0xffff);
  if ( crc & 0x10000) {
    crc += 1;
  }
  crc = ~crc;
  crc &= 0xffff;
  return crc;
}


Advert sequence number follows the value of the first sequence number for advert payload beacons. For client information beacons its value is ?? (I have seen 0x01 when no clients are connected and 0x02 when one client is connected).

The payload size gives the number of valid bytes following. If necessary more zero value bytes are sent to make the beacon upto the correct length. This is not quite true for client payloads.

WMB Payload

Advert payload

The advert has the following format:

The game name and description can by retreived from the banner structure in the nds file.

This advert is split between 9 beacons, the first eight of which have a payload of 98 bytes and the nineth 72 bytes.

Client payload

Not much known here. It is transmitted in beacons with the non advert marker field set to 0x2.

If no clients are connected then the payload size is set to 1 and the value of the byte is 0x00.

If one client is connected then the payload size is set to 3. The value of the first two bytes is 0x02, 0x00. The value of the third varies. The next bit breaks the payload size field in the header (oh). The next byte gives the size of the client's name in characters. The client's name then follows.

How to Associated with a Nintendo DS

A DS with authenticate itself and then associate with a Host.

All management frames sent have the destination address and BSS id fields set to the value of the source address and BSS id fields of the beacons sent by the host. The source address can be set to whatever you like i.e. it does not have to be a Nintendo MAC address(00:09:bf).

Authentication

Authentication is the same whatever the host is doing. The frame has the flags set to zero and the parameters set as follows:

The DS will respond with an Authentication frame with SEQ 0x0002 and if it is happy a status code of success (0x0000). You can now attempt to associate with the DS.

Associating with a Pictochat Host

The layout of the Association Request.

For the association to be successful you need to copy some data out to the Nintendo IE of the most recent beacon that the DS has sent you (the host changes the value of the data after some number of beacons, the number of beacons between changes varies) and into the SSID parameter of the AssocReq. All other bytes of the SSID are zero.

The DS will respond to your Assoc Req with a Assoc Resp and if is happy then the status code in the response will be success (0x0000), if the SSID in your request is not correct the status will be 0x0001. Any other status means you have problems elsewhere.

If the association is successful the DS will start shouting out data frames.

Associating with a WMB Host

The layout of the Association Request is as given for the Pictochat association. For this to be successful you need to copy some data out to the Nintendo IE of the most recent beacon that the DS has sent you (I'm not sure if the data does change but I'm playing it safe) and into the SSID parameter of the AssocReq. All other bytes in the SSID are zero.

The DS will respond to your Assoc Req with a Assoc Resp and if is happy then the status code in the response will be success (0x0000), if the SSID in your request is not correct the status will be 0x0001. Any other status means you have problems elsewhere.

If the association is successful the DS will start shouting out data frames.

WMB Data Transfer

Data transferr is always initiated by the host. The host sends out Data + CF-Poll frames to which the client replies with Data + CF-Ack frame. The client can respond with no data + CF-Ack frames if it is not in a position to give a data response.

Destination Addresses

Data frames are sent to multicast addresses.

03:09:bf:00:00:00 - the hosts sends Data + CF-Poll frames for the client to this address. These frames contains the commands.

03:09:bf:00:00:03 - the hosts sends Data + CF-Ack frames to this address shortly after it transmits a frame to the 00:00:00 address. The data comprise four bytes which values change with each transmission. The client will happily accept a download from a host that is not sending these frames. A DS host expects the client to response in the window between the 00:00:00 CF-Poll and this frame.

03:09:bf:00:00:10 - the client sends Data (no data) + CF-Ack frames to this address in response to the host's CF-Poll frames.

Host Commands

bing bong

Client Responses

bing bong