ASUS RT-BE96U P2P Network Test

ASUS RT-BE96U P2P Network Test: WebRTC Latency and NAT Check

The ASUS RT-BE96U is a Wi-Fi 7 (802.11be) triband router rated BE19000 across 2.4 GHz, 5 GHz, and 6 GHz bands. It ships with a 10G WAN port and a 1G WAN port, both capable of handling multi-gigabit ISP connections without a separate switch. No subscription is required for any feature; all routing, VPN, and QoS functionality is available through the ASUS ASUSWRT firmware without an ongoing fee.

For P2P and WebRTC applications, the RT-BE96U typically assigns Full Cone or Restricted Cone NAT by default, enabling ICE hole-punching to succeed for most peer configurations. The STUN probe on this page will show the same external port across multiple requests if the router is operating in cone mode. A documented firmware bug in versions up to 3.0.0.6.102 causes intermittent packet loss on the 10G WAN interface after a router reboot; probe traffic may show elevated loss for 30 to 90 seconds post-restart before the WAN driver stabilizes.¹

Specifications²

NAT type and UPnP on the RT-BE96U

The RT-BE96U defaults to restricted cone NAT for outbound connections on the WAN interface. UPnP is enabled in the ASUSWRT firmware by default; devices can request port mappings automatically, and the router opens the requested external port for the duration of the session. Disabling UPnP tightens the NAT to port-restricted cone, which still allows WebRTC ICE hole-punching but prevents gaming consoles and media devices from automatically negotiating ports. To verify the current NAT mode, log into the router admin panel at 192.168.1.1, navigate to WAN, and check the NAT Type setting. Port forwarding specific ports for known applications achieves the same result as UPnP for those applications.

When to run a same-LAN baseline before comparing connections

Before testing WebRTC performance to a remote peer, run a same-LAN baseline test with both browsers on the RT-BE96U network. This baseline captures the router's local forwarding behavior without the ISP path, revealing whether NAT restrictions or packet loss originate at the router or further upstream. If the same-LAN test shows low jitter and zero loss but the remote test shows elevated jitter, the ISP path is the cause; if both show loss, the router configuration needs adjustment before troubleshooting the ISP link.

WebRTC and P2P configuration on the RT-BE96U

For the best WebRTC P2P performance, verify that UPnP is enabled in the WAN settings. If WebRTC connections consistently fall back to relay (ICE candidate type "relay" in this tool), enable Adaptive QoS and set real-time applications to highest priority; this prevents download saturation from filling the upload queue and causing STUN responses to be delayed. Furthermore, if the STUN probe shows different external ports for different STUN servers, the router may be applying a per-destination NAT mapping, and updating to the latest ASUSWRT firmware resolves most NAT anomalies. CapyToolkit's P2P tester runs over the same network path your WebRTC applications use, so the ICE candidate type and RTT you see here reflect the actual connectivity your video calls and gaming sessions will experience after you apply these configuration changes on the RT-BE96U.

Testing the RT-BE96U with this tool

Connect one browser to the network served by the RT-BE96U and a second browser to a remote network. Complete the WebRTC handshake and watch the ICE candidate type; "srflx" confirms the router's NAT is permitting direct traversal. If you observe elevated packet loss immediately after rebooting the router, wait 90 seconds before starting the test to allow the 10G WAN driver to stabilize. The STUN probe public IP should match the RT-BE96U's WAN IP visible in the ASUSWRT admin panel under WAN status. Any mismatch indicates the router is behind carrier-grade NAT from the ISP. Running the STUN probe before and after a firmware update is the most reliable way to confirm the update did not change your router's NAT classification, because even minor firmware revisions can reset advanced NAT settings to their defaults on ASUS routers.

ASUSWRT-Merlin firmware and advanced P2P configuration options

ASUSWRT-Merlin is a community-maintained firmware fork for ASUS routers that extends the standard ASUSWRT interface with P2P-relevant features not available in stock firmware. The most significant addition for NAT behavior is the Full Cone NAT toggle in the WAN settings. Stock ASUSWRT uses restricted cone NAT by default and does not expose a mode toggle. Merlin firmware adds this option directly under WAN > Full Cone NAT, allowing you to change from restricted to full cone with a single toggle. Full cone NAT accepts incoming packets on any mapped external port regardless of the source IP, which resolves NAT-related ICE failures for gaming consoles and WebRTC applications that encounter restricted cone restrictions at scale.³

Merlin firmware also enables per-application QoS using Adaptive QoS on the WAN interface. This prevents background TCP transfers from causing jitter spikes on WebRTC probe traffic. Enabling Adaptive QoS in the Merlin interface and assigning the browser or gaming device to the highest-priority class produces measurably lower jitter in this tool compared to stock ASUSWRT with the default FIFO queue.

Installing ASUSWRT-Merlin on the RT-BE96U

Merlin firmware for the RT-BE96U is available from the official Merlin project page. Download the .zip file for your exact router model, navigate to Administration > Firmware Upgrade in the ASUSWRT interface, and upload the Merlin firmware file. The upgrade preserves existing settings. After the reboot, navigate to WAN and verify the Full Cone NAT option is now visible. Enable it, then rerun the STUN probe in this tool to confirm the NAT type moved from restricted cone to full cone.

Before flashing Merlin, verify that the RT-BE96U is on a supported firmware version line; the Merlin project page lists compatible ASUSWRT base versions for each router model. If the router is on an unsupported base version, you may need to flash an intermediate ASUSWRT release first, then flash Merlin on top. The Merlin forum and GitHub issues page document the exact upgrade path for each supported model, and following the documented path avoids the rare but possible scenario where a direct flash leaves the router in a state that requires recovery via TFTP.

Dual WAN failover on the RT-BE96U and WebRTC session continuity

The RT-BE96U supports dual WAN using both its 2.5G and 10G WAN ports simultaneously, with one as primary and the other as failover. When the primary WAN link fails, the router transitions new connections to the failover WAN after 12 consecutive detection failures (at the default 5-second check interval, this means approximately 60 seconds).⁴ Existing WebRTC sessions lose their ICE-negotiated candidate pair when the failover activates, because the public IP address changes when the router switches to the failover link. The ICE agent then attempts an ICE restart, re-gathering candidates from the new WAN IP.

Whether a WebRTC session recovers after failover depends on how quickly the application detects the disconnection and triggers an ICE restart. The oniceconnectionstatechange event fires with "disconnected" when the active candidate pair stops receiving responses. Well-implemented applications trigger onnegotiationneeded and initiate a new offer/answer exchange at this point, completing ICE restart within 2 to 5 seconds on a healthy failover link. Applications that do not handle ICE restart show a permanent "failed" state after failover and require the user to reload the page.

Configuring failover detection intervals for WebRTC applications

In ASUSWRT's WAN settings under Dual WAN, set the failover detection interval to its minimum (5 seconds) for WebRTC applications where fast recovery from WAN failure matters. The detection mechanism sends regular ping packets to a configured target IP (default 8.8.8.8); three consecutive failures trigger failover. Reducing the interval to 5 seconds narrows the window during which WebRTC probes fail (and loss appears in this tool) before the failover link activates.

A realistic same-LAN baseline for the RT-BE96U

Independent lab testing measured client ping through the RT-BE96U at 5 to 15 ms, holding steady whether the network sat idle or carried competing wireless traffic.⁵ Treat that range as your realistic same-LAN baseline for this tool. When you run the same-LAN test here with both browsers on the RT-BE96U, check whether your reading lands inside the 5-to-15ms band that confirms the local forwarding path is healthy, since a same-LAN run measures the router's path rather than any ISP link.

The lab reached those numbers across repeated runs under both idle and congested traffic, and the figure barely moved, which is why a flat 5 to 15 ms reading is a healthy sign rather than a concern. A reading near 0 ms is not the bar to clear here; a reading well outside 5 to 15 ms is what actually signals trouble, usually Wi-Fi congestion or a saturated upload queue rather than a fault in the router's own forwarding path.