These NWM services are used for local-WLAN communications, NWM module handles regular wifi APs as well. These services are used for creating/connecting to networks, and for sending/receiving data over the network etc. NWM module uses the wifi SDIO hardware via the IO registers for this.

PullPacket is used for receiving data over the network and SendTo is for sending data over the network.

The only sysmodule which uses this is socket-sysmodule. The first command used by socket-module is cmd9.

Beacon entry:

This section describes the structure returned by NWMINF:RecvBeaconBroadcastData and NWMUDS:RecvBeaconBroadcastData.

This section describes the 0x34-byte input structure used by NWMINF:RecvBeaconBroadcastData and NWMUDS:RecvBeaconBroadcastData.

UDS is used for 3DS<>3DS local-WLAN communications, and for 3DS<>Wii U communications. The latter is mainly only used for multi-player in games.

All UDS local-WLAN communications have the CCMP key for data encryption generated via NWM module. The CCMP key passed to nwm::CEC commands(stored in a 0x44-byte input structure) for StreetPass is generated by the CECD module. The input data used with EncryptDecryptAes with keytype1 is a MD5 hash over the input passphrase. This input passphrase is fixed for Download Play, it’s unique per local-WLAN application. The CTR is a MD5 hash over the below 0x10-byte structure. The output from encrypting that data with AES-CTR is the final CCMP key. This passphrase is a raw input buffer: while the passphrase specified by user-processes is normally a string with the NUL-terminator included, it can be anything(like the WirelessRebootPassphrase for example).

The maximum number of nodes(including the host) which can be on an UDS network is 16.

There are two types of client connections: regular Client, and Spectator. The latter never sends any 802.11 frame at all to the host, hence nothing actually connected to the network(including the host) can know about any spectators. Once a spectator is “connected” to a network, it can only receive broadcasted data, no sending.

DLP-client connects to the network as a spectator during DLP scanning to get various metadata including icon data.

This is the network u16 ID for each device on the UDS network. NodeID 0xFFFF is a broadcast alias. 0x1 is for the host, the 0x2 for the first client, 0x3 for the second client, and so on.

The spectator doesn’t have a NetworkNodeID, since it can’t send any data.

NetworkNodeIDs for clients do not change when any clients disconnect, likewise for the encrypted node-listing stored in the wifi beacons. When a client disconnects, the corresponding NetworkNodeID bit in the node_bitmask is cleared. When a client is connecting, the client is assigned the NetworkNodeID with the lowest corresponding clear-bit in the node_bitmask, then that bit is set.

This u32 is an ID only used on the local device. How many devices are on the network or which device this system is does not affect this ID.

The spectator uses BindNodeID 0x1. DLP uses BindNodeID 0x3 when connecting as an actual client. Hence, it seems BindNodeID bit0 is spectator-related. All normal nodes(host/client) start with BindNodeID 0x2. When connecting to a network again(and probably with network creation) without reinitializing NWMUDS, official user processes increase the used BindNodeID by 0x2.

BindNodeID value 0x0 is invalid. The maximum number of BindNodeIDs which can be open at the same time is 16.

The protocol used for sending/receiving data over the network with UDS by official applications is PRUDP(in some cases at least). Mario Kart 7 uses PRUDP here. Triforce Heroes uses plaintext for whatever protocol it uses for UDS.

The UDS version of PRUDP is different from the normal UDP version it appears(no afa1/a1af data for example).

The process of connecting to a host and exchanging data follows the sequence:

Client->Server: Authentication frame SEQ1

Server->Client: Authentication frame SEQ2

[There does not appear to be an association request frame sent by the client to the server, it is however possible that it was sent and just not captured by the test equipment]

Server->Client: Association Response frame with association id

[From here on, the client is connected to the server]

Client->Server: Encrypted data packet containing an 8-byte 802.2 LLC header with ethertype = EAPoL (0x888E) and an u16 header of 0x201 ( EAPoL-Start)

Server->Broadcast: Encrypted data packet containing the updated node information after the client connected (Using ethertype = SecureData).

Server->Client: Encrypted data packet containing an 8-byte 802.2 LLC header with ethertype = EAPoL (0x888E) and an u16 header of 0x0202( EAPoL-Logoff)

[From here on, data packets sent using SendTo are encapsulated with an LLC header with ethertype = 0x876D ( SecureData)]

[The client also sends periodic SecureData data frames on its own, these are probably ping frames]

Data is transferred over the network using NWMUDS:PullPacket/ NWMUDS:SendTo. That data is transferred using 802.11 data frames using CCMP encryption. The encrypted data contained in the frame starts with the 0x8-byte 🔗 LLC header, then the 0xE-byte NWM header, followed by the actual application data from the previously mentioned commands. When NWMUDS:SendTo was used with dst_NodeID = broadcast, the data frame is sent to the 802.11 broadcast MAC address. Otherwise with a specific NodeID, the data frame is sent to the actual MAC address for that device.

Official application data is normally stored here as big-endian.

Application data packets are sent to the host using 802.11 unicast, which then acts as a router and forwards the packet to the right destination node id based on the SecureData header using either broadcast or unicast, it is not yet known how it chooses which to use.

This data is stored as big-endian.

This data is stored as big-endian.

This data is stored as big-endian.

This data is stored as little-endian.

This data is stored as little-endian. All data here is all-zero except for the MAC address, when the u8 at offset 0x8 in the network-struct is 0.

This 0x108-byte structure is used for NWMUDS:BeginHostingNetwork, NWMUDS:ConnectToNetwork, etc. This data is stored as big-endian.

The first 0x20-bytes are written by the user-process before using this structure with NWMUDS:InitializeWithVersion. The data starting at offset 0x8 is only initialized by NWM-module.

The UDS host broadcasts a beacon containing at least two Nintendo-vendor tags(tag number 0xDD, see above for the OUI), normally the data stored in these tags are static. The second tag contains the big-endian u32 networkID, used by the clients when connecting to the host and for the above CCMP key generation. The Nintendo-vendor tag(s) following the first two are unique to the process using UDS, these tags are used for broadcasting metadata regarding the host.

A tool for these beacons is available here: 🔗 1

The following is the structure of each tag, starting at the OUI. The order of the tags is the same as listed below. All data stored under these tags are stored as big-endian.

Normally the size of this tag(from the tag size field) is 0x07.

Normally the size of this tag(from the tag size field) is 0x34, not including appdata.

This is the tag0 used with NWMUDS:DecryptBeaconData. The size of data stored under this tag has a maximum size of 0xFA-bytes, however normally the size is smaller than that. Additional encrypted data, if any, is stored under the below tag1.

When this exists in the beacon, this is the tag1 used with NWMUDS:DecryptBeaconData. The data stored here is the 0xFA-bytes following the previous encrypted data in tag0, for more space for storing the encrypted data.

The following structure is for the plaintext version of the encrypted data, stored as big-endian.

This data is encrypted with AES-CTR, by NWM module in software. The AES key is stored in NWM module itself. See above for the CTR. The size of this encrypted data is 0x12 + (0x1E*val), where val is the u8 from networkstruct offset 0x1D.

Each entry is for a node.

All of the IO mapped under the NWM-module process is listed below:

Category:Services