Summary
Developer Mode is enabled and reports an active 999h session. The key server on 9991 works and I can retrieve a valid RSA key with the correct passphrase. But port 9922 is closed — the TV answers TCP RST — so every ares-* command fails with ECONNREFUSED. A full port scan shows no SSH daemon on any port.
I’d like to know whether the Developer Mode SSH daemon is provisioned at all on this firmware.
Device
- Non-LG brand (webOS Hub licensee), 55" set
- webOS TV version: webOS25 / 10.1.7-4703
- Widevine:
cvte-20250916-webos-1482701 - Connected over Wi-Fi, same /24 subnet as my development machine, no firewall or AP isolation between them
Client
- macOS
- webOS CLI:
ares 3.2.5
What works
Developer Mode app: signed in with my LG developer account, Dev Mode Status: ON, session shows 999h 13m remaining. The TV rebooted automatically when I enabled it. Key Server: ON.
Device discovery finds the TV correctly:
$ ares-setup-device --search
Searching...
? Select webOS_TV_55TV # 192.168.1.100
Key retrieval succeeds, and the passphrase shown in the app is accepted:
$ ares-novacom --device webOS_TV_55TV --getkey
SSH Private Key: /Users/me/.ssh/webOS_TV_55TV_webos
input passphrase: ******
$ ls -l ~/.ssh/webOS_TV_55TV_webos
-rw------- 1.8k
$ head -1 ~/.ssh/webOS_TV_55TV_webos
-----BEGIN RSA PRIVATE KEY-----
So the retrieved key is a real 1.8 KB RSA private key, not an error page.
What fails
$ ares-device --system-info
[Info] Set target device : webOS_TV_55TV
ares-device ERR! [syscall failure]: connect ECONNREFUSED 192.168.1.100:9922
ares-device ERR! [Tips]: Connection refused. Please check the device IP address or the port number
Device configuration is the documented one:
name deviceinfo connection profile
webOS_TV_55TV prisoner@192.168.1.100:9922 ssh tv
Evidence that nothing is listening
Port state — 9922 is closed, not filtered, so the TV’s own stack is sending RST and there is no firewall in the path:
$ nmap -Pn -p 9922,9991 192.168.1.100
PORT STATE SERVICE
9922/tcp closed unknown
9991/tcp open issa
The key server on the same host responds fine over the same network path, which rules out connectivity as a cause.
A full scan (nmap -sV -sC -p-) reports 65518 closed ports (all reset) and these open:
515, 1079, 1172, 1190, 1345, 1673, 1986, 3000, 3001,
7000, 7250, 8008, 8009, 8443, 9991, 18181, 36866
No 22 and no 9922. I then banner-grabbed each unexplained port individually; none returns an SSH-2.0- identification string. There is no SSH server anywhere on this TV.
Already ruled out
| Hypothesis | Why it’s excluded |
|---|---|
| Wrong IP / wrong device | ares-setup-device --search discovers this exact address via webOS’s own discovery |
| Key or passphrase problem | Irrelevant when the port refuses the TCP connection before any SSH handshake |
| Key Server not enabled | It is enabled and demonstrably serving on 9991 |
| Missing reboot after enabling Dev Mode | TV restarted automatically; I’ve also toggled off → reboot → on → reboot and relaunched the app |
| Expired session | 999h remaining |
| Network / firewall / AP isolation | A TCP RST from the device plus a working HTTP fetch from 9991 both prove reachability |
| SSH on 22 instead of 9922 (per some older threads) | 22 is closed; the full scan covered all 65535 ports |
| Wi-Fi vs. Ethernet | The daemon binds all interfaces, so a second NIC can’t start a process that isn’t running |
Questions
- Is the Developer Mode SSH daemon (9922) provisioned on webOS Hub licensee images, or only on LG-branded firmware? The Developer Mode app documentation doesn’t state a supported-device scope.
- If it should be present on
10.1.7-4703, is there any additional step required to start it that isn’t in the documentation? - Is it expected behaviour for the Developer Mode app to display an active session and a working key server while no SSH daemon is running? If sshd is absent on this build, the app reporting a healthy 999h session is misleading — it looks like a working setup right up until the first connection attempt.
Happy to run any further diagnostics on the TV or provide the full scan output.