1,434
edits
Changes
Jump to navigation
Jump to search
mLine 10:
Line 10: − + − + Line 20:
Line 20: − + Line 32:
Line 32: − + Line 64:
Line 64: − + − + Line 92:
Line 92: − + Line 124:
Line 124: − + − + − + Line 158:
Line 158: + + + + + + + + + + + + + + + Line 165:
Line 180: − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 180:
Line 265: − + Line 193:
Line 278: − + − + − + − + − + − + Line 225:
Line 310: − + Line 231:
Line 316: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − + + + − Only one spectator can be connected to the network at a time. DLP-client connects to the network as a spectator during DLP scanning to get icon data.+ + + Line 244:
Line 428: + + Line 249:
Line 435: + + − + + + + + + + + + + + + + + + + + + + + + + + + + + − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 265:
Line 620: − + − + Line 277:
Line 632: − + Line 299:
Line 654: − + Line 307:
Line 662: − + Line 321:
Line 676: − + + + + + + + + + − + Line 337:
Line 700: − + + + − + + + + + − + + + + + + + + + − + − + − + − + − + − + − + Line 373:
Line 750: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 424:
Line 839: − + − Line 473:
Line 887: − + − + Line 490:
Line 904: − + Line 505:
Line 919: − + − + − |- − | 0x18 − | 0x4 − | ? − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 525:
Line 963: + + + + + + + + + + + + + + +
→NWM local-WLAN service "nwm::UDS"
! Description
! Description
|-
|-
| 0x00010442
| 0x000102C2
|
|
| Unknown, probably deprecated. Not used by "Steel Diver: Sub Wars".
| Initialize Deprecated. Appears to be handled about the same way as [[NWMUDS:InitializeWithVersion]], except this uses version=0x100 internally instead of loading it from the command request.
|-
|-
| 0x00020000
| 0x00020000
| 0x00030000
| 0x00030000
|
|
| [[NWMUDS:Shutdown|Shutdown]]
| [[NWMUDS:Finalize|Finalize]]
|-
|-
| 0x00040402
| 0x00040402
| 0x00060000
| 0x00060000
|
|
| EjectSpectator
| [[NWMUDS:EjectSpectator|EjectSpectator]]
|-
|-
| 0x00070080
| 0x00070080
| 0x000E0006
| 0x000E0006
|
|
| Unknown. Not used by sub-wars.
| ''Identical'' to [[NWMUDS:GetNodeInformationList|GetNodeInformationList]]. Deprecated, only used by old titles.
|-
|-
| 0x000F0404
| 0x000F0404
|
|
| [[NWMUDS:RecvBeaconBroadcastData|RecvBeaconBroadcastData]]
| [[NWMUDS:StartScan|StartScan]]
|-
|-
| 0x00100042
| 0x00100042
| 0x00150080
| 0x00150080
|
|
| SetMaxSendDelay(u32 unk0, u32 unk1) Not used by sub-wars.
| SetMaxSendDelay(u64 unk) Not used by sub-wars.
|-
|-
| 0x00160040
| 0x00160040
| 0x001D0044
| 0x001D0044
| Unknown, >[[2.0.0-2]]
| Unknown, >[[2.0.0-2]]
| [[NWMUDS:BeginHostingNetwork|BeginHostingNetwork]] This is a replacement for the original network-creation command.
| [[NWMUDS:CreateNetwork2|CreateNetwork2]] This is a replacement for the original network-creation command.
|-
|-
| 0x001E0084
| 0x001E0084
| Unknown, >[[2.0.0-2]]
| Unknown, >[[2.0.0-2]]
| [[NWMUDS:ConnectToNetwork|ConnectToNetwork]] This is a replacement for the original network-connection command.
| [[NWMUDS:ConnectNetwork2|ConnectNetwork2]] This is a replacement for the original network-connection command.
|-
|-
| 0x001F0006
| 0x001F0006
| Unknown, >[[2.0.0-2]]
| Unknown, >[[2.0.0-2]]
| [[NWMUDS:DecryptBeaconData|DecryptBeaconData]]
| [[NWMUDS:GetNodeInformationList|GetNodeInformationList]]
|-
|-
| 0x00200040
| 0x00200040
! Command Header
! Command Header
! Description
! Description
|-
| 0x00010000
| ?
|-
| 0x00020000
| ?
|-
| 0x00030000
| ?
|-
| 0x00040000
| ?
|-
| 0x00050000
| ?
|-
|-
| 0x000603C4
| 0x000603C4
| [[NWMINF:ConnectToEncryptedAP|ConnectToEncryptedAP]]
| [[NWMINF:ConnectToEncryptedAP|ConnectToEncryptedAP]]
|-
|-
| 0x0008....
| 0x00080302
| [[NWMINF:ConnectToAP|ConnectToAP]]
| [[NWMINF:ConnectToAP|ConnectToAP]]
|-
| 0x00090000
| ?
|-
| 0x000A0000
| ?
|-
| 0x000B0000
| ?, return event handle in cmdbuf[3]
|-
| 0x000C0040
| ?
|-
| 0x000D0000
| ?
|-
| 0x000E0002
| ?
|-
| 0x000F0082
| ?
|-
| 0x00100040
| ?
|}
|}
=NWM socket service "nwm::SOC"=
=NWM socket service "nwm::SOC"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010042
| (u32 size, <static_buffer translate-hdr with static_buf_id=0>, addr) ?
|-
| 0x00020080
| (u32 unk, u32 size) Unknown. Uses size=0x5F8 internally unless the input is <=0x5F8. Uses an ipc static_buffer(static_buf_id=0) for output with the specified size(also used when writing the translate-hdr). Writes an output u32 to cmdreply[2].
|-
| 0x00030042
| (u32 unk, u32 size, <static_buffer translate-hdr with static_buf_id=0>, addr) ?
|-
| 0x00040042
| (u32 size, u32 unk, <static_buffer translate-hdr with static_buf_id=1>, addr) ?
|-
| 0x00050040
| (u32 unk) ?
|-
| 0x00060080
| (u32 unk0, u16 unk1) ?
|-
| 0x00070040
| (u16 unk) This writes an output u32 to cmdreply[2].
|-
| 0x00080040
| [[NWMSOC:GetMACAddress|GetMACAddress]]
|-
| 0x00090000
| This just copies data from state to the cmdreply, this always returns 0. u32 cmdreply[2] = sharedmem_size, cmdreply[4] = [[NWM_Shared_Memory|sharedmem_handle]], cmdreply[5] = eventhandle.
|-
| 0x000A0040
| (u32 unk) ?
|-
| 0x000B0040
| (u32 unk) This writes an output u32 to cmdreply[2].
|-
| 0x000C0040
| (u32 unk) ?
|-
| 0x000D0002
| ([[IPC|kernel_processid_translatehdr]], u32 processid) ?
|}
The only sysmodule which uses this is [[Socket_Services|socket]]-sysmodule. The first command used by socket-module is cmd9.
=NWM service "nwm::SAP"=
=NWM service "nwm::SAP"=
|-
|-
| 0x00060002
| 0x00060002
| Unknown, called by CECD module, cmdbuf[2] takes an event handle
| Unknown, called by CECD module, cmdbuf[2] takes an event handle.
|-
|-
| 0x000D0082
| 0x000D0082
! Description
! Description
|-
|-
| 0x0001....
| 0x00010000
| <=[[2.0.0-2]]
| <=[[2.0.0-2]]
| ?
| ?
|-
|-
| 0x0002....
| 0x00020000
| <=[[2.0.0-2]]
| <=[[2.0.0-2]]
| ?
| ?
|-
|-
| 0x0003....
| 0x00030000
| <=[[2.0.0-2]]
| <=[[2.0.0-2]]
| ?
| ?
|-
|-
| 0x0004....
| 0x00040040
| <=[[2.0.0-2]]
| <=[[2.0.0-2]]
| ?
| ?
|-
|-
| 0x0005....
| 0x00050002
| <=[[2.0.0-2]]
| <=[[2.0.0-2]]
| ?
| ?
|-
|-
| 0x0006....
| 0x00060000
| <=[[2.0.0-2]]
| <=[[2.0.0-2]]
| ?
| ?
| [[NWMEXT:ControlWirelessEnabled|ControlWirelessEnabled]]
| [[NWMEXT:ControlWirelessEnabled|ControlWirelessEnabled]]
|-
|-
| 0x0009....
| 0x00090000
| <=[[2.0.0-2]]
| <=[[2.0.0-2]]
| ?
| ?
=NWM service "nwm::TST"=
=NWM service "nwm::TST"=
=BeaconDataReply Structure=
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Max output size, from the command request.
|-
| 0x4
| 0x4
| Total amount of output data written relative to struct+0. 0xC when there's no entries.
|-
| 0x8
| 0x4
| Total entries, 0 for none.
|-
| 0xC
| <Rest of the structure>
| Beacon entries.
|}
Beacon entry:
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Size of this entire entry. The next entry starts at curentry_startoffset+curentry_size.
|-
| 0x4
| 0x1
| ?
|-
| 0x5
| 0x1
| AP wifi channel.
|-
| 0x6
| 0x1
| ?
|-
| 0x7
| 0x1
| ?
|-
| 0x8
| 0x6
| AP MAC address.
|-
| 0xE
| 0x6
| ?
|-
| 0x14
| 0x4
| Size of this entire entry, games use this value to traverse the beacons list.
|-
| 0x18
| 0x4
| Value 0x1C(size of this header and/or offset to the actual beacon data).
|-
| 0x1C
| Entry_size - 0x1C
| The actual beacon data is located here, starting at the 802.11 management frame header.
|}
This section describes the structure returned by [[NWMINF:RecvBeaconBroadcastData]] and [[NWMUDS:RecvBeaconBroadcastData]].
=ScanInputStruct=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Two unknown u16s.
|-
| 1
| Two unknown u16s.
|-
| 2-3
| Host MAC address. The 6-bytes located here are normally all 0xFF, for all hosts. Otherwise when not set to broadcast-MAC, the command will only return info for the specified host MAC address.
|-
| 4-12
| Uninitialized for UDS.
|}
This section describes the 0x34-byte input structure used by [[NWMINF:RecvBeaconBroadcastData]] and [[NWMUDS:RecvBeaconBroadcastData]].
=Local-WLAN=
=Local-WLAN=
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.
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 [[Process_Services|EncryptDecryptAes]] with [[PSPXI:EncryptDecryptAes|keytype1]] is a MD5 hash over an input passphrase. This input passphrase is fixed for [[Download Play]], it's unique per local-WLAN protocol. 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.
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 [[Process_Services|EncryptDecryptAes]] with [[PSPXI:EncryptDecryptAes|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 [[DLP_Services|WirelessRebootPassphrase]] for example).
The maximum number of nodes(including the host) which can be on an UDS network is 16.
==NodeID==
==NodeID==
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 [[Download_Play|metadata]] including icon data.
===NetworkNodeID===
===NetworkNodeID===
The spectator doesn't have a NetworkNodeID, since it can't [[NWMUDS:SendTo|send]] any data.
The spectator doesn't have a NetworkNodeID, since it can't [[NWMUDS:SendTo|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 [[NWMUDS:GetConnectionStatus|node_bitmask]] is cleared. When a client is connecting, the client is assigned the NetworkNodeID with the lowest corresponding clear-bit in the [[NWMUDS:GetConnectionStatus|node_bitmask]], then that bit is set.
===BindNodeID===
===BindNodeID===
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.
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.
==Application data transfer==
==Application data transfer==
The protocol used for sending/receiving data over the network with UDS by official applications is [[PRUDP]](in some cases at least). In some cases at least this is with PRUDPS(additional encryption layer). This includes UDS-specific data in each frame, such as Mii data. Mario Kart 7 uses PRUDPS here.
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).
==Communication protocol==
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 ([[NWM_Services#EAPoL-Start frame|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([[NWM_Services#EAPoL-Logoff frame|EAPoL-Logoff]])
[From here on, data packets sent using SendTo are encapsulated with an LLC header with ethertype = 0x876D ([[NWM_Services#SecureData NWM header|SecureData]])]
[The client also sends periodic SecureData data frames on its own, these are probably ping frames]
==Data frames==
==Data 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 a 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.
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 [https://en.wikipedia.org/wiki/Subnetwork_Access_Protocol#Use 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.
==Special data channels==
{| class="wikitable" border="1"
|-
! Channel
! Description
|-
| 0x101
| Used when broadcasting the updated node information after a new client connects.
|-
| 0x103
| Used when sending what appears to be "ping" or "null" frames.
|-
| 0x104
| Used to signal the ejection of all spectators in the network.
|}
==SecureData NWM header==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x2
| Size of the entire frame minus the 8 bytes from the LLC header.
|-
| 0x2
| 0x2
| unknown
|-
| 0x4
| 0x2
| Size of the entire frame minus 12 bytes.
|-
| 0x6
| 0x2
| Data channel. Applications can only use the low 8 bits, channels greater than 255 are reserved for management functions.
|-
| 0x8
| 0x2
| Sequence number, incremented after each sent packet.
|-
| 0xA
| 0x2
| Destination network node id
|-
| 0xC
| 0x2
| Source network node id
|}
This data is stored as big-endian.
==EAPoL-Start frame==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x2
| Always 0x201 in big-endian.
|-
| 0x2
| 0x2
| Association id of the sending client in big-endian.
|-
| 0x4
| 0x2
| Unknown. Always 0x1 in big-endian. The parser for this packet errors out if this is > 3.
|-
| 0x6
| 0x2
| Unknown
|-
| 0x8
| 0x28
| NodeInfo structure with all fields in big-endian
|}
This data is stored as big-endian.
==EAPoL-Logoff frame==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x2
| Always 0x202 in big-endian.
|-
| 0x2
| 0x2
| Unknown. Always 0?
|-
| 0x4
| 0x2
| Assigned network node id.
|-
| 0x6
| 0x6
| Mac address of the newly connected client.
|-
| 0xC
| 0x4
| Unknown
|-
| 0x10
| 0x2
| Unknown. Always 0.
|-
| 0x12
| 0x1
| Number of connected nodes, including the new client.
|-
| 0x13
| 0x1
| Max number of nodes.
|-
| 0x14
| 0x2
| Always 0.
|-
| 0x16
| 0x2
| Unknown.
|-
| 0x18
| 0x280
| List of 16 NodeInfo structures with all fields in big-endian
|}
This data is stored as big-endian.
==Structure used for generating the CTR for CCMP key generation==
==Structure used for generating the CTR for CCMP key generation==
| 0x0
| 0x0
| 0x4
| 0x4
| Local-WLAN communication ID, normally this is: (user_process [[Title_list|uniqueID]] << 8) | val. Where val is 0x10 on retail([[Configuration_Memory|configmem]] UNITINFO bit0 set), 0x90 for devunit. For [[Download Play]], this is always 0x2810 on retail(0x2890 on devunit).
| wlancommID
|-
|-
| 0x4
| 0x4
| 0x4
| 0x4
| u32 networkID, randomly-generated when creating the network. The network SSID used when a client connects to the network is sprintf(out, "%08X", networkID).
| networkID
|-
|-
| 0x8
| 0x8
| 0xE
| 0xE
| 0x2
| 0x2
| ID, for [[Download Play]] this is 0x55.
| id8
|}
|}
| 0xA
| 0xA
| 0x1
| 0x1
| This ID is also stored at offset 0xE in the CTR-generation structure.
| id8
|-
|-
| 0xB
| 0xB
| 0xC
| 0xC
| 0x4
| 0x4
| This is the u32 from offset 0x18 in the network-struct.
| networkID
|}
|}
| 0x0
| 0x0
| 0x6
| 0x6
| This is the MAC address of the host. This is all-zero on the host, like with [[NWMUDS:BeginHostingNetwork]].
| This is the MAC address of the host. This is used for when [[NWMUDS:ConnectToNetwork|connecting]] to the network.
|-
| 0x6
| 0x1
| This is actually written as an u16 without byte-swapping. This is the network wifi channel. When connecting this is normally non-zero. When hosting, this can be 0 to automatically select a channel, otherwise the specified channel is used. When non-zero official user-processes require this value to be one of the following when hosting: 1, 6, or 11.
|-
| 0x7
| 0x1
| Padding
|-
|-
| 0x8
| 0x8
| 0x1
| 0x1
| This is non-zero when at least one entry is stored in the array under the encrypted beacon data.
| Initialized flag. Must be non-zero otherwise NWM-module will use value 0x0 for most/all(?) fields in this structure when reading these fields.
|-
|-
| 0xC
| 0xC
| 0x10
| 0x10
| 0x4
| 0x4
| wlancommID
| wlancommID. Local-WLAN communication ID, normally this is: (user_process [[Title_list|uniqueID]] << 8) | val. Where val is 0x10 on retail([[Configuration_Memory#ENVINFO|ENVINFO]] bit0 set), 0x90 for devunit. Official software includes an input bool flag parameter for setting bit0 in this wlancommID, normally that flag isn't set. For [[Download Play]], this is always 0x2810 on retail(0x2890 on devunit).
This wlancommID can have the side affect of region-locking when the title uses the uniqueID for the current title(hard-coded in .text normally), instead of using a fixed input uniqueID for each region of the title.
|-
|-
| 0x14
| 0x14
| 0x1
| 0x1
| This ID is also stored at offset 0xE in the CTR-generation structure.
| id8. ID, for [[Download Play]] this is 0x55. 0x55/'U' seems to be used for networks where Wii U can host it(Download Play, Smash Bros, ...) - this value isn't known to be actually checked anywhere however.
|-
| 0x15
| 0x1
| Number of times the network structure hash was updated.
|-
|-
| 0x16
| 0x16
| 0x2
| 0x2
| This u16 bitmask can be written via [[NWMUDS:UpdateNetworkAttribute]]. When bitmask 0x2 is set, new Clients are not allowed to connect. Bitmask 0x4 is probably the same as 0x2 except for Spectators.
| This network attributes u16 bitmask can be written via [[NWMUDS:UpdateNetworkAttribute]].
Bitmasks:
* 0x1: When set, spectators are not allowed to connect(see [[NWMUDS:EjectSpectator|here]]). Checked by official user-processes before using [[NWMUDS:ConnectToNetwork]], when connecting as a Spectator. Must be clear otherwise that code returns error 0xE10113EA. If the initialized_flag at offset 0x8 is zero, this code handles it the same way as if this bit was set. The latest NWM-module handles checking this bit itself however.
* 0x2: When set, new regular-clients are not allowed to connect.
* 0x4: Unknown, has no affect on new clients/spectators connecting. Official software has an option for setting this bit via an input flag from the same code using bitmask 0x2. Official software always clears bitmask 0x6 when unblocking new connections.
|-
| 0x18
| 0x4
| u32 networkID, randomly-generated when creating the network. The network SSID used when a client connects to the network is sprintf(out, "%08X", networkID).
|-
|-
| 0x1C
| 0x1C
| 0x1
| 0x1
| ?
| Total number of currently connected nodes, including the host.
|-
|-
| 0x1D
| 0x1D
| 0x1
| 0x1
| This is the total number of entries stored under the array in the encrypted beacon data.
| Maximum number of nodes, including the host. This also is the total number of entries stored under the array in the encrypted beacon data.
|-
|-
| 0x1E
| 0x1E
| 0x1
| 0xD
| ?
| ?
|-
|-
| 0x1F
| 0x2B
| 0x1
| 0x14
| ?
| SHA1 hash of the network structure, starting at the OUI field (offset 0xC) and spanning SizeOfAppData + 0x34. The unused space of the app data buffer is not hashed.
|-
|-
| 0x3F
| 0x3F
| 0x1
| 0x1
| Size of appdata. Normally zero.
| Size of appdata.
|-
|-
| 0x40
| 0x40
This 0x108-byte structure is used for [[NWMUDS:BeginHostingNetwork]], [[NWMUDS:ConnectToNetwork]], etc. This data is stored as big-endian.
This 0x108-byte structure is used for [[NWMUDS:BeginHostingNetwork]], [[NWMUDS:ConnectToNetwork]], etc. This data is stored as big-endian.
==NodeInfo structure==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| u64 ID, this is the UDS version of the FriendCodeSeed. This is loaded from BlkID 0x00090000 in the [[Config_Savegame|system-config]] via [[CfgS:GetConfigInfoBlk2]].
|-
| 0x8
| 0x14
| The first 0x18-bytes from BlkID 0x000A0000 in the [[Config_Savegame|system-config]] loaded via [[CfgS:GetConfigInfoBlk2]] is written here by user-processes. However, the data at +0x14(absolute offset 0x1C) is written by NWM-module later.
|-
| 0x1C
| 0x2
| u16, unknown. Set to 0x0 with the output from [[NWMUDS:DecryptBeaconData]].
|-
| 0x1E
| 0x1
| u8 flag, unknown. Originates from the u16 bitmask in the beacon node-list header. This flag is normally 0 since that bitmask is normally 0?
|-
| 0x1F
| 0x1
| Padding?
|-
| 0x20
| 0x2
| u16 NetworkNodeID
|-
| 0x22
| 0x6
| Normally zero?
|}
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.
== UDS Beacons ==
== UDS Beacons ==
|}
|}
Normally the size of this tag(from the tag size field) is 0x34.
Normally the size of this tag(from the tag size field) is 0x34, not including appdata.
==== OUI Type 24 ====
==== OUI Type 24 ====
==== Encrypted beacon data ====
==== Encrypted beacon data ====
The following structure is for the plaintext version of 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(zero when the u8 at networkstruct offset 0x8 is value zero).
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.
===== Structure =====
===== Structure =====
| 0x10
| 0x10
| 0x2
| 0x2
| ?
| u16 bitmask. Unknown, normally 0? Bit0 is for entry0, bit1 for entry1, and so on.
|-
|-
| 0x12
| 0x12
|-
|-
| 0x0
| 0x0
| 0x18
| 0x1C
| This is the first 0x18-bytes of the structure from [[NWMUDS:Initialize|here]].
| This is the first 0x1C-bytes of the NodeInfo structure, stored as big-endian.
|-
|-
| 0x1C
| 0x1C
| 0x2
| 0x2
| ?
| u16 NetworkNodeID, stored as big-endian.
|}
Each entry is for a node.
= Mapped IO =
''All'' of the [[IO_Registers|IO]] mapped under the NWM-module process is listed below:
{| class="wikitable" border="1"
|-
! Userland address
! Physical address
! Size
! Description
|-
| 0x1EC22000
| 0x10122000
| 0x1000
| [[WIFI_Registers]]
|-
| 0x1EC40000
| 0x10140000
| 0x1000
| [[PDN_Registers]]
|-
| 0x1EE22000
| 0x10322000
| 0x1000
|
|}
|}
| 0xC8A06C0D
| 0xC8A06C0D
| The operation being performed is already done (e.g., if you run NWMEXT_ControlWirelessEnabled to turn wifi on when it's on already, you can't turn it on again).
| The operation being performed is already done (e.g., if you run NWMEXT_ControlWirelessEnabled to turn wifi on when it's on already, you can't turn it on again).
|-
| 0xC8A113EA
| Returned when the command isn't allowed to be used on this device.
|-
| 0xC90113FA
| Node doesn't exist / invalid NetworkNodeID?
|-
| 0xC92113FB
| Returned when trying to connect to a host when the host has the specified connection-type blocked via the network attributes. There might be other causes too.
|-
| 0xE10113E9
| Returned when the input size is invalid. Returned by [[NWMUDS:PullPacket]] when the input size is smaller than the frame_size.
|-
| 0xE10113EA
| Invalid bind / data_channel is invalid(0x0).
|}
|}