* Services/UDS: Added a function to generate the EAPoL-Start packet body.
* Services/UDS: Added filter for beacons.
* Services/UDS: Lock a mutex when accessing connection_status from both the emulation and network thread.
* Services/UDS: Handle the Association Response frame and respond with the EAPoL-Start frame.
* fixup: make use of current_node, changed received_beacons into a list, mutex and assert corrections
* fixup: fix damn clang-format
As per 3dbrew:
"During Home Menu start-up it uses APT:PrepareToStartNewestHomeMenu. If that doesn't return an error(normally NS returns 0xC8A0CFFC for that), Home Menu starts a hardware reboot with APT:StartNewestHomeMenu etc. "
We need to know what is being run so we can set the APT parameter destination AppId correctly.
Delaying the preparation of the parameter until we know which AppId is running lets us support booting both the Home Menu and normal game Applications.
There is currently no stage tracking, a client is considered "Connected" when it receives the EAPoL Logoff packet from the server, this is not yet implemented.
This is slightly more ergonomic to use, correctly handles virtual
regions which are disjoint in physical addressing space, and checks only
regions which can be cached by the rasterizer.
* Services/UDS: Set the proper bit in the ConnectionStatus structure when creating a network.
This lets the application know that the host was successfully added to the session.
* Services/UDS: Reset the connection status when destroying the network
* Services/UDS: Reset the connection status's bitmask of changed nodes after reporting it to the game.
Copy the IPC command buffer to/from the request context before/after the
handler is invoked. This is part of a move away from using global data
for handling IPC requests.
The old "Interface" class had a few problems such as using free
functions (Which didn't allow you to write the service handler as if it
were a regular class.) which weren't very extensible. (Only received one
parameter with a pointer to the Interface object.)
The new ServiceFramework aims to solve these problems by working with
member functions and passing a generic context struct as parameter. This
struct can be extended in the future without having to update all
existing service implementations.