Remote management on the Asus Pro WS X570-ACE, under Linux?

Hardware Hub Motherboards
,
55

I got one of these boards and running Linux on it and couldn’t resist investigating the RTL8117 stuff a bit today to see if I could use it without a Windows client and ACCE.

I really don’t have time to investigate this further (I already spent too much time on this), but below is some ramblings in case someone is interested or wants to pick it up, so they don’t need to necessarily start from scratch.

tl;dr Basic commands mostly work, KVM/VNC does not (but is probably solvable with some effort).

I mostly discovered the below using wireshark and mitmproxy.

First, there is an unauthenticated REST GET endpoint https://IP/cgi-bin/luci/apiasus/descriptor that returns JSON with some basic info and a list of functions.

Then GET https://IP/cgi-bin/luci/?luci_username=root&luci_password=PASSWORD where PASSWORD is the last 15 characters from the UUID contained in the JSON in the last request. You will get a Location: redirect to /cgi-bin/luci/;stok=STOK where STOK is a new dynamic token. Next register the token using GET https://IP/cgi-bin/luci/;stok=STOK/apiasus/reg_stok?appuid=consoleTest (replace STOK) - any appuid seems to work, but ACCE uses “consoleTest”.

Now you can call the rest of the functions with the stok, e.g.:

  • https://IP/cgi-bin/luci/;stok=STOK/apiasus/dmesg (dmesg of the Linux system running on RTL8117)
  • https://IP/cgi-bin/luci/;stok=STOK/apiasus/get_dxe_info (sensor data etc., but there is noise in the output, maybe there is some encapsulation on top of JSON…)
  • https://IP/cgi-bin/luci/;stok=STOK/apiasus/reboot_pc (reboot)
  • etc, see the descriptor JSON for all functions.

There is a WS-Management API on port 623, HTTP Digest auth, root:PASSWORD with PASSWORD from before.
One can use wsmancli, or AMD DMTF DASH tools, or just manually POST XML into the http://IP:623/wsman endpoint.
A lot of my wsmancli commands caused the remote wsman server to crash (?) and not respond to commands anymore, I used REST “stop_service” and “restart_service” functions to bring it back (I now see there is “restart_wsmand” too, maybe it would be enough).

The KVM uses a VNC-like protocol but only seems to allow a single connection each time so you need to disable KVM and enable KVM via WS-Man each time before connecting.

The raw XML command to enable/disable KVM is as follows. Replace IPADDRESS with the RTL8117 address, and the MessageID UUID should be unique (but I doubt the server cares). Replace XXX with 3 for disable, 2 for enable. I used curl -i --data-binary '@input.xml' --digest --user 'root:PASSWORD' http://IP:623/wsman.

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd"
xmlns:n1="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_KVMRedirectionSAP">
  <s:Header>
    <wsa:Action s:mustUnderstand="true">http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_KVMRedirectionSAP/RequestStateChange</wsa:Action>
    <wsa:To s:mustUnderstand="true">http://IPADDRESS:623/wsman</wsa:To>
    <wsman:ResourceURI s:mustUnderstand="true">http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_KVMRedirectionSAP</wsman:ResourceURI>
    <wsa:MessageID s:mustUnderstand="true">uuid:9bf323ca-016e-4bb5-aca3-84acda80088e</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
    </wsa:ReplyTo>
    <wsman:SelectorSet>
      <wsman:Selector Name="__cimnamespace">root/interop</wsman:Selector>
      <wsman:Selector Name="Name">KVMSAP:2149449728</wsman:Selector>
      <wsman:Selector Name="SystemName">IPADDRESS</wsman:Selector>
      <wsman:Selector Name="CreationClassName">CIM_KVMRedirectionSAP</wsman:Selector>
      <wsman:Selector Name="SystemCreationClassName">CIM_ComputerSystem</wsman:Selector>
    </wsman:SelectorSet>
  </s:Header>
  <s:Body>
    <n1:RequestStateChange_INPUT>
      <n1:RequestedState>XXX</n1:RequestedState>
      <n1:TimeoutPeriod>00000000000000.000000:000</n1:TimeoutPeriod>
    </n1:RequestStateChange_INPUT>
  </s:Body>
</s:Envelope>

The VNC is running in standard port 5900, no authentication (just disable/enable KVM as above each time).

The VNC protocol is unfortunately not standard VNC. The server identifies the protocol as RFB 003.00R\n, i.e. version 3.R (Realtek?), which is not understood by e.g. tigervnc. After faking support for 003.00R in TigerVNC (just consider 3.R as 3.8 and inform server 3.R is supported) I did get something to display, e.g. the AMIBIOS logo was recognizable but was somehow messed up, and occasionally seemingly the VNC client kept losing the synchronization and tried to interpret pixel data as commands (“Unknown message type 85”), especially when rebooting the server system.

I think the VNC issues should be solvable with some effort, the protocol is simple enough that one should be able to figure out what is going wrong. Could just be some disagreement between client and server on the exact pixel encoding or screen size.

AMD DMTF DASH tools produced errors when trying to connect to the KVM VNC.

2 Likes