The Agent only opened the on-screen passcode splash when IsMachineConfigured() was false (Ethernet adapter on DHCP). But during SecureConfig the Service assigns a TEMPORARY static IP to the adapter so it can broadcast — which flips IsMachineConfigured() to true. So an Agent starting at auto-login (in the SecureConfig wait window) saw a "configured" adapter and skipped the splash entirely; the Request ID / Passphrase only reached the log and the COM2 plasma display, never the screen. Gate the splash on the configuring.json file the Service writes (before the temp IP) as well as the DHCP check, and make the splash dismiss robustly when SecureConfig finishes (file gone after being seen, or the machine becomes configured). The COM2 plasma path in the Service was already correct. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
TeslaSuite
The Tesla cockpit-pod software, in one repository:
| Folder | What it is | Target |
|---|---|---|
Console/ |
TeslaConsole — the operator console (WinForms) that configures and drives the pods. A faithful decompiled reconstruction of the original TeslaConsole.exe, with a differential test suite that pins it to the original baseline. |
.NET Framework 4.8 |
Launcher/ |
TeslaLauncher — the pod-side Service (Session 0 RPC listener) + Agent (user-session app launcher). A clean .NET 6 rewrite of the original launcher. | .NET 6 (windows, x86) |
The console and the launcher talk over TCP 53290 using an OFB-encrypted
BinaryFormatter RPC. They share a wire contract (Tesla.Net types +
ILauncherService/IPodManagerConnection signatures) that must stay byte-for-byte
compatible.
⚠️ Known duplication (intentional, for now): that shared contract currently lives in two places — the console consumes it as the compiled
Console/lib/TeslaConsoleLaunchLib.dll, and the launcher hand-replicates the same types inLauncher/LaunchModels_Shared.cs. They must match exactly. Consolidating this into a single multi-targetedTesla.Contractsource project is the main follow-up this monorepo is meant to enable.
Building
Each side has its own toolchain; the combined solution builds both:
dotnet build TeslaSuite.sln -c Release
Or individually:
dotnet build Console/TeslaConsole.csproj -c Release # the console
dotnet test Console/tests/TeslaConsole.DiffTests # differential + catalog tests
dotnet build Launcher/TeslaLauncher.sln -c Release # service + agent
The launcher also has its original Launcher/build.bat / Launcher/install.bat
for producing and deploying the self-contained pod build.
Layout notes
Console/original/TeslaConsole.exeis the reference baseline the differential tests compare against — keep it.Console/lib/*.dllare the proprietary binary dependencies the console still references (TeslaConsoleLaunchLib,TeslaSecureConfiguration,Munga Net,BitmapLibrary,WeifenLuodocking).Console/RedPlanet/Apps.xmlis the data-driven product catalog (see the console's Site Management → Add Product / Register Product on Pods).