DLAM Permanently Shows "Disconnected" Despite Device Being Detected — Full Diagnostics Completed, Server-Side Issue Suspected

issues & bugs
1

Device: Rabbit r1
Firmware: Latest OTA (applied within last 2 weeks)
OS: Windows 11
Browsers Tested: Chrome, Edge, Firefox
Issue Started: 25th February 2026 — was working perfectly the night before

Description

Since the morning of 25th February, DLAM has been completely unable to establish a connection. The r1 is correctly detected and appears in the screen share device selector in the browser, but the DLAM page permanently shows the device as “disconnected” and never transitions to a connected state.

This is not a setup issue — DLAM was working perfectly on the exact same hardware and configuration the previous evening. Nothing changed between the last successful session and the first failed one.

Steps Already Taken

All standard troubleshooting has been exhausted:

  • :white_check_mark: Restarted r1 and PC multiple times

  • :white_check_mark: Performed 5x side button memory refresh on r1

  • :white_check_mark: Tried 3 different browsers (Chrome, Edge, Firefox)

  • :white_check_mark: Tried multiple USB-C cables with confirmed data transfer capability

  • :white_check_mark: Tried multiple USB ports on the same machine

  • :white_check_mark: Reduced to single monitor only

  • :white_check_mark: Confirmed active microphone connected and browser mic permission granted for dlam.rabbit.tech

  • :white_check_mark: Tested on a completely different laptop — same behaviour

  • :white_check_mark: Checked Device Manager — no driver errors or warnings

  • :white_check_mark: Verified rabbithole account is logged in correctly

  • :white_check_mark: Checked for and applied all available updates

Advanced Network & System Diagnostics

Going beyond standard troubleshooting, a full system and network audit was performed:

Windows Firewall

  • No Block rules affecting DLAM or WebRTC traffic found

  • Corporate security policy confirmed active and healthy

USB Stack

  • USBSTOR Start registry value = 3 (enabled) :white_check_mark:

VPN / Remote Access

  • RemoteAccess service = Stopped & Disabled :white_check_mark:

  • Tailscale VPN tunnel brought down temporarily — no change to DLAM behaviour :white_check_mark:

Proxy & DNS

  • ProxyEnable = 0 (no proxy active) :white_check_mark:

  • DNS correctly resolving via local router :white_check_mark:

Hosts File

  • Clean — only standard Tailscale MagicDNS entries present :white_check_mark:

Scheduled Tasks

  • No new or unusual tasks created in the last 24 hours :white_check_mark:

WebRTC / STUN Connectivity
Native UDP STUN Binding Requests sent directly from PowerShell:

  • Port 19302 → :white_check_mark: 32-byte response received from 74.125.250.129

  • Port 3478 → :white_check_mark: 32-byte response received

This confirms the machine is fully WebRTC-capable and UDP traffic is not being blocked at any level — network, OS, or firewall.

Browser Console Errors

The following errors appear consistently in the browser developer console during every connection attempt:

text

[WebRTC] Connection failed!
→ 5-dc60eabc31d26285.js:1
→ t.onconnectionstatechange @ page-4d4101c69a961e60.js:1

[USB Receiver] Transfer error: AbortError: Failed to execute
'transferIn' on 'USBDevice': The transfer was cancelled.
→ 5-dc60eabc31d26285.js:1
→ U @ 418-28537255d48d8d18.js:1

The WebRTC connection failure appears first and causes the USB transfer to abort — the USB error is a downstream consequence of the WebRTC failure, not the root cause.

Conclusion

Every possible local factor has been systematically eliminated:

  • :cross_mark: Not a Windows Firewall issue

  • :cross_mark: Not a USB/driver issue

  • :cross_mark: Not a proxy or DNS issue

  • :cross_mark: Not a VPN/tunnel issue

  • :cross_mark: Not a hardware issue (same on different laptop)

  • :cross_mark: Not a browser issue (same on 3 browsers)

  • :cross_mark: Not a monitor or microphone issue

  • :white_check_mark: WebRTC traffic is fully functional on this network

This is strongly consistent with an account-level or server-side issue — possibly a stuck session, corrupted sync state, or a DLAM backend configuration issue tied to a specific account introduced around the time of the latest OTA update.

A support ticket has been raised but no response received after 24+ hours.

Request

  • Can any Rabbit staff confirm whether there are any known account-level DLAM issues following the latest OTA?

  • Is there a way to reset/clear the DLAM session state server-side for a specific account?

  • Has anyone else experienced this exact behaviour and found a resolution?

Any help or escalation would be hugely appreciated. Happy to provide any additional logs, diagnostics or information needed. :folded_hands::rabbit: