DD-WRT Binding [5.1.0.0,6.0.0.0)

Add-on Marketplace Bundles
, , ,
1

logo

Monitors and manages DD-WRT, OpenWrt, Tomato, Raspberry Pi and pretty much anything on a network via SSH. Provides device telemetry, wireless client tracking, syslog event monitoring, firewall rule control, and auto-discovery — all over a single SSH connection per device.

Changelog

Version 5.1.3.20260416

  • SSH Backoff & Lockout Prevention
    • Two-tier backoff strategy with independent counters for auth failures vs network failures
    • Auth failures: 30s, 60s backoff, then suspend after 3 attempts — stays under Dropbear’s 5-attempt block threshold so users have time to fix config
    • Network failures: 10s..300s backoff with no hard stop (host may come back)
    • Auth failure resets network counter (proves reachability); network failure does not affect auth counter
  • User Configuration Improvements
    • New useSystemUser option on bridge and device — resolves username from ~/.ssh/config or system user
    • Default user set to root for bridge and device configs
    • Support user@host:port syntax in the hostnames parameter for per-host overrides
    • Updated config descriptions to document username precedence
  • Fixed Ed25519 SSH key support (EdDSA security provider was not registered in OSGi)

Version 5.1.3.20260409

  • Replace AcceptAllServerKeyVerifier with KnownHostsServerKeyVerifier using Trust On First Use (TOFU)
  • Log SSH-style warning with remediation instructions when host key changes
  • Register EdDSA security provider in OSGi for Ed25519 SSH key support
  • Load SSH keys at client level to support ProxyJump authentication
  • fixed Bridge channels: total-clients, wireless-clients, wired-clients
  • fixed Firewall rule cache listener notifications
    • Add i18n keys for all channels and thing types
  • README: quick start, SSH key setup, key directories, SSH config, host key verification (TOFU), firmware SSH setup links

Version 5.1.3

  • fixed: Ed25519 SSH key loading in OSGi (explicit EdDSA security provider registration)
  • fixed: Refresh thread crash recovery — catch-all exception handler prevents silent thread death on SSH session loss
  • added: Device telemetry (CPU load, temperature, uptime, WAN IP, traffic counters)
  • added: Wireless radio monitoring (SSID, channel, mode, associated client list)
  • added: Wireless client tracking (online/offline, signal, roaming, MAC randomization)
  • added: Real-time syslog monitoring (DHCP, wireless, warning, error events)
  • added: Firewall rule control (DD-WRT nvram filter rules)
  • added: Auto-discovery of devices, radios, wireless clients, and firewall rules
  • added: Support for DD-WRT, OpenWrt, FreshTomato, and generic Linux devices
  • added: SSH key auth with Ed25519 support and ~/.ssh/config directives (ProxyJump, User, Port, IdentityFile)

Version 0.1

  • initial release

Resources

5 Likes
Considering a new dd-wrt binding
2

I’ve installed the binding and setup the ssh connections, but getting issues with the connectivity.

I’m using id_ed25519 keys. Here’s what’s in the logs:

2026-04-10 23:10:57.104 [DEBUG] [ding.ddwrt.internal.api.DDWRTNetwork] - Retrying connection to failed device: xxxx
2026-04-10 23:10:57.105 [DEBUG] [.ddwrt.internal.api.SshClientManager] - Connecting to xxxx port 22 as root
2026-04-10 23:10:57.689 [WARN ] [shd.client.session.ClientSessionImpl] - exceptionCaught(ClientSessionImpl[root@xxxx/IP.IP.IP.IP:22])[state=Opened] SshException: key spec not recognised: class net.i2p.crypto.eddsa.spec.EdDSAPublicKeySpec
2026-04-10 23:10:57.689 [WARN ] [rnal.api.DDWRTBaseDevice.xxxx] - Failed to initialize device at xxxx: key spec not recognised: class net.i2p.crypto.eddsa.spec.EdDSAPublicKeySpec

any hints?

3

I’m seeing that as well. I think it’s a problem with dependencies. Working on the fix now.

1 Like
4

OK the updated version should fix the issue

1 Like
5

Thanks - confirmed it connects fine now. Playing around :slight_smile:

6

Using OpenWRT as a “dumb AP” (i.e. without dhcp server) - I’ve noticed very few wireless clients are being added to Things Inbox. Then I’ve noticed these entries in the logs (multiple times). Please can you include all wireless clients for disovery?

2026-04-17 10:45:47.480 [DEBUG] [ddwrt.internal.DDWRTDiscoveryService] - Skipping wireless client without hostname: MAC=XX:XX:XX:XX:7f:16
2026-04-17 10:45:47.480 [DEBUG] [ddwrt.internal.DDWRTDiscoveryService] - Skipping wireless client without hostname: MAC=XX:XX:XX:XX:52:4e

7

Created issue. Please watch for updates here Skipping wireless client without hostname when no DHCP server is present · Issue #57 · ballle98/openhab-addons · GitHub

Originally I was tracking everything by MAC but it was horribly broken by client MAC randimization see Handle MAC randomization for wireless clients · Issue #47 · ballle98/openhab-addons · GitHub