Peplink Firmware 8.6.1 RC1: What’s New and What Got Fixed

Peplink released Router Firmware 8.6.1 Release Candidate 1 on September 16, 2026. This is the first release candidate on the 8.6.1 line, and it is a big one: 16 improvements and 40 resolved issues across the Balance, MAX, B One, SDX, Dome, MBX, Orbit, UBR, MediaFast, EPX, PDX and FusionHub families.

Most of what is in this build has been cooking since 8.6.1 Beta 1. Only two items are tagged as new in RC 1, and both are worth your attention. The rest is a mix of genuinely new capability (native IPv6 on cellular, Starlink RF control, WINS support), a loosening of licensing requirements (Synergy Mode and the Starlink Dish API no longer need a Care plan), three security advisories, and a long list of fixes for cellular carriers, SpeedFusion, Wi-Fi 6 and LAN forwarding.

If you have been holding off on the 8.6.x train, this is the build that starts to make it feel finished. Below we summarize everything, then dig into the changes that actually matter for how you deploy and support your network.

First, a word on release candidates

A release candidate is not a beta, but it is not general availability either. Peplink uses the RC label to say “we think this is done, prove us wrong.” RC builds are stable enough for production in most environments, and many integrators run them on customer sites, but they have not yet passed the final soak that turns them into a GA release.

Our standing advice has not changed. Run RC1 on a lab unit or a low-risk site first. If you have a fleet managed through InControl 2, use a firmware group so you can roll it out in stages and roll back in one click. Back up your configuration before you upgrade. And if a specific bug on the resolved list is hurting you today, the RC is a perfectly reasonable way to get the fix now rather than waiting for GA.

One more note on how to read Peplink release notes. Many entries carry a tag like “Fixed in: 8.6.0s049.” That means the fix already shipped as a special build (the “s” builds) on top of 8.6.0, usually to a customer who reported the problem through a support ticket. 8.6.1 is where those one-off patches get merged into the main line so everyone gets them. If you were given an 8.6.0s build by Peplink support, 8.6.1 is your path back to a standard release.

The two items new in RC 1

Strengthened authentication and request validation for firmware uploads (37827). This applies to all models. Firmware upload is one of the most sensitive functions on any router, because whoever can push firmware owns the device. Tightening who can call that function and how the request is validated closes off a class of attack where an authenticated but low-privilege session, or a crafted request, could push an image. No CVE is listed, but it sits alongside three separate security advisories in this same build, so we read it as part of a broader hardening pass.

Synergy Controller Wi-Fi DHCP fix (37839). In a Synergy Mode deployment where one controller manages multiple Synergized devices, Wi-Fi clients could fail to get an IP address. That is a show-stopper for anyone running Synergy across a multi-router site, and it is the reason this item made the cut for RC 1 rather than waiting for the next beta.

The features worth a deeper look

Native IPv6 on cellular (36889)

This is the headline feature of 8.6.1. Peplink has added IPv6 support on the cellular WAN for a wide range of modems, including the LTEA-US, LTEA-K, LTE-E, LTEA-D, GLTE-G, LTEA-Q, LTEA-E, LTEA-R, LTE-EJ, LTE-MX, LTE-MXS and LTE-US module codes. In model terms that covers the Balance 20X, 310 5G, 310 Fiber 5G, 310X, 380X and 580X, the BR1 Pro (CAT-20), BR1 Pro 5G and BR2 Pro, the Transit Pro E, the B One Plus and B One 5G, EPX, PDX, and all SDX, Dome and MBX models.

Why it matters: US carriers have been IPv6-first on their mobile cores for years. T-Mobile is effectively IPv6-only on the device side, with IPv4 delivered through 464XLAT translation. Verizon and AT&T hand out IPv6 to most modern devices by default. Until now a Peplink router would pull an IPv4 address (often a carrier-grade NAT address in the 100.64.0.0/10 range) and ignore the IPv6 side. That worked, but it meant every connection from your LAN went through at least one extra layer of translation, and any service that is reachable only over IPv6 was invisible.

With native IPv6 on the cellular WAN, the router can obtain a globally routable IPv6 prefix from the carrier and pass it through to LAN clients via Router Advertisements. Practically, that means lower latency to IPv6-native services, fewer NAT-related breakages for things like VoIP and VPN, and a path toward reaching devices behind cellular without a SpeedFusion tunnel or FusionHub (with the usual caveat that carriers still filter inbound traffic on most consumer plans).

A companion change in the same build, 37760, updates IPv6 LAN Router Advertisement intervals and lifetimes to follow whatever the ISP provides rather than using fixed values. That sounds like a footnote but it fixes a real class of problem. If the router advertises a prefix with a longer lifetime than the upstream actually granted, clients keep using an address the carrier has already withdrawn, and you get the kind of intermittent “some sites load, some do not” complaint that is miserable to troubleshoot.

Our advice: enable IPv6 on the cellular WAN in a lab first and check that your firewall rules cover both address families. Inbound firewall policies written for IPv4 do not automatically apply to IPv6, and a globally routable prefix on your LAN is a different security posture from CGNAT.

Starlink integration gets more useful and less locked down

Four Starlink items landed in this build, and together they signal that Peplink is treating Starlink as a first-class WAN rather than a generic Ethernet uplink.

Starlink Inhibit RF control (37401). This is the standout. Starlink dishes have a software “inhibit RF” state that turns the transmitter off without powering the dish down. Peplink can now toggle it from the router. The use case is anyone who must be RF-silent under certain conditions: maritime vessels entering ports with transmit restrictions, aircraft on the ground, mobile command posts near sensitive equipment, or any deployment that cycles between satellite and cellular and wants the dish idle when it is not the active WAN. Tying this to the router means it can be automated rather than requiring someone to open the Starlink app.

Care plan requirement removed for LAN access to the Starlink Dish API (37094). Previously you needed an active Care plan for the router to talk to the dish’s local API. That requirement is gone. Any supported model can now query the dish for status, obstructions, and GPS whether or not it has Care coverage.

Better GPS status reporting (37184 and 37185). The router can now distinguish a dish that has GPS disabled by subscription (some Starlink plans do not expose location) from one that simply has not acquired a fix, and the dashboard only shows the “Starlink GPS unavailable” warning when Starlink GPS is actually enabled and no Starlink WAN is providing a location. Small change, but it removes a persistent, misleading alert from a lot of dashboards.

Synergy Mode no longer needs a Care plan or license (37239)

Synergy Mode lets one Peplink router act as a controller for other Peplink routers, pooling their cellular and WAN connections as if they were modules inside a single chassis. It has always been one of the more interesting things Peplink does, and it has always been gated behind Care plan and license requirements on both the controller and the Synergized devices.

Those requirements are gone. Any supported Synergy Controller (everything except FusionHub) can manage Synergized Balance, PDX, Dome, MBX, BR, Transit, Orbit, B One, MediaFast and UBR devices without a Care plan on either side.

Combined with the RC 1 DHCP fix above and the Beta 1 fix for BR1 Mini devices that could not join Synergy when the controller still had default admin credentials and LAN IP (37604), this is the most robust Synergy has been. If you have a site with a Balance and a couple of BR1s that you have been managing as separate routers, this is the release to try consolidating them.

PrimeCare Secure DNS now works with any Care plan (37249)

Secure DNS, Peplink’s DNS filtering feature, was previously a PrimeCare exclusive. Now any active Care plan qualifies, across essentially the whole product line except FusionHub. If you are on standard EssentialCare or an older plan and had assumed content filtering was off the table, check your Care status.

WAN health checks now use Google, Cloudflare and Quad9 (37381)

Peplink routers decide whether a WAN link is healthy by sending test queries, and the default DNS-based health check has historically used a set of public resolvers. This build updates the targets to Google (8.8.8.8), Cloudflare (1.1.1.1) and Quad9 (9.9.9.9). If your firewall or upstream provider blocks or rate-limits any of these, your WAN may start flapping after the upgrade. Check your health check settings, and if you have a policy reason to use your own resolvers, set them explicitly rather than relying on the defaults.

DNS-O-Matic is being retired (37764)

Peplink removed DNS-O-Matic from the Dynamic DNS options because the service is being discontinued. If you use DNS-O-Matic as an aggregator to push your WAN IP to multiple DDNS providers, you will need to reconfigure. Most people can point directly at their DDNS provider, and Peplink supports the common ones natively.

Docker memory becomes a shared pool (37098)

On models that support Docker containers (Balance 310 and up, BR1 Pro 5G, BR2 Pro, EPX with the EXM-LCDT module, and the SDX, MBX, Transit, Orbit, B One and MediaFast lines), memory allocation is now a shared limit across all containers rather than a fixed per-container slice. That is more forgiving when you run one heavy container and a couple of light ones, but it also means a runaway container can starve its neighbors. Watch your container memory graphs after the upgrade.

A related fix (37728) ensures a factory reset actually clears Docker storage on devices that do not have other MediaFast storage features. Before this fix, a reset could leave container images and volumes behind, which is a data hygiene problem if you are decommissioning or reselling a unit.

GPIO invert option for WAN Status mode (37260)

The GPIO digital output on the BR1 and BR2 families, the Balance 310, the MAX Orbit 2 and 4, and the MBX, Transit, B One and UBR lines can now be inverted when it is set to WAN Status mode. If your external indicator, relay or alarm expects active-low signaling, you no longer need an inverter in the wiring.

WINS server support (37393)

Peplink added WINS server support for the Balance 310, 310 5G HW3 and 580X HW2, the BR1 Pro (CAT-20), BR1 Pro 5G and BR2 Pro, and all Dome, Transit, Orbit and B One models. WINS is a legacy Windows name resolution service, and its appearance in a 2026 firmware tells you exactly who asked for it: industrial and enterprise customers with older Windows infrastructure that still relies on NetBIOS names. If that is you, the router can now hand out a WINS server address via DHCP.

InControl can apply feature keys on restricted devices (37535)

If you run devices with InControl 2 set to “Restricted to Status Reporting Only,” which some security-conscious organizations do so that the cloud can see but not touch the router, InControl can now still push feature activation keys. That lets you buy and apply a license without temporarily lifting the restriction.

Security advisories

Three items in this build are tagged as Security Advisory, all applying to all models. Peplink does not include details in the release notes, which is normal practice until a fix has been widely deployed, but the categories are telling.

DHCP client hostname handling (37662). A vulnerability in how the router processes hostnames from DHCP clients. Hostname fields are a classic injection vector because a device on the LAN controls the content and the router logs, displays, or passes it along.

Web Admin access control (36956). An access control weakness in the Web Admin interface. Any bug in this category deserves attention because Web Admin is the front door.

Management CLI (37657). Multiple vulnerabilities in the management CLI.

Two further items are not labeled as advisories but belong in the same conversation: hardened protections against potential remote code execution through API requests (37690), and an input validation fix in device configuration handling through the Device API (37611). Add the RC 1 firmware upload hardening (37827) and you have six security-relevant changes in one release.

Our take: if your routers expose Web Admin or the API to any untrusted network, and especially if you have Remote Assistance or public-facing management enabled, prioritize this upgrade. Also review your management access settings while you are in there. Web Admin should not be reachable from the WAN unless you have a specific reason, and the Peplink InControl remote web admin feature exists so you do not need that exposure. If you track router vulnerabilities across vendors, our free RouterCVE.com tool aggregates published CVEs for Peplink and other networking manufacturers.

Cellular fixes by carrier and modem

Cellular fixes are where Peplink’s global footprint shows. Most of these will not affect a US user, but they are worth knowing about if you deploy internationally or manage a fleet with mixed modem codes.

The one that matters most in the US is 37183: LTE-E, LTE-US, LTE-MX and LTE-MXS cellular firmware upgrades could fail on RAMIPS-based models running firmware 8.6.0. RAMIPS is the MediaTek platform underlying many of the smaller Peplink units. If you tried to update modem firmware on 8.6.0 and it silently failed or rolled back, this is why.

Also of note for US users: 5GD modules could fail to switch carrier profiles (37196). Carrier profile switching is what lets a single modem configure itself correctly for Verizon versus AT&T versus T-Mobile, and a failure there typically shows up as a modem that connects but performs poorly or cannot attach at all after a SIM swap.

For international deployments: cellular registration could be slow on Vodafone Italy (37264), LTEA-K modules could fail to get an IPv4 address on Optus in Australia (37792), LTEA-Q modules could not establish a data connection on KDDI in Japan (37186), and IMS could remain enabled on 5GK modules connected to a private network (37521). That last one is interesting for private 5G deployments: IMS is the carrier voice and messaging subsystem, and on a private network with no IMS core it should be off. Leaving it on can cause registration delays and log noise.

SpeedFusion and VPN fixes

Five SpeedFusion fixes landed, and two of them deserve a closer look because they explain problems people have been chasing.

SpeedFusion could drop IP-fragmented UDP packets on the receiving side (37705). Fragmentation happens when a packet is bigger than the path MTU. Inside a VPN tunnel that is common, because the tunnel headers eat into the available MTU. Dropping fragmented UDP silently breaks things like large DNS responses, some VoIP signaling, and certain video protocols in ways that look like random packet loss.

SpeedFusion Boost could drop traffic to ports 80, 2222, 5000 and 44444, or from clients on the FusionHub LAN (37703). Port 80 is HTTP. If you had web traffic mysteriously failing through a Boost-enabled tunnel while everything else worked, this is your bug.

Also fixed: SpeedFusion could drop traffic after the sending peer restarted a flow’s packet sequence (37628), SpeedFusion Connect tunnels could drop large packets (37406), and SpeedFusion Score per-WAN tests could fail when a standby WAN was part of the tunnel (37557).

On the FusionHub side, FIPS mode could not be enabled at all (37586), and InControl Remote Web Admin could fail on a FusionHub with FIPS on and Remote Assistance off (37674). We covered Peplink’s FIPS 140-3 work earlier this year, and both fixes matter for anyone deploying FusionHub in a government or regulated environment where FIPS is not optional.

LAN, VLAN and Wi-Fi fixes

Several LAN forwarding bugs got attention, and if you run a multi-VLAN network with Apple devices you will care about at least one of them.

Bonjour forwarding could advertise client-network services back to the service network (37668), and UDP and Bonjour forwarding could fail between VLANs with similar IDs (37746). Bonjour is how Apple devices, printers and many smart home products find each other, and it does not cross VLAN boundaries on its own. Peplink’s Bonjour forwarding bridges that gap, but the first bug created loops (your guest VLAN advertising its printers to the office VLAN) and the second silently broke forwarding for certain VLAN ID combinations.

Two VLAN bugs on specific hardware are fixed: the Balance 310 HW5 could drop tagged VLAN multicast when all LAN ports were set to Trunk Any (37259), and the Balance 310 5G HW3 could drop untagged LAN traffic after a reboot with VLAN access ports configured (37299). If you have a 310 5G HW3 that needed a second reboot to start passing traffic, that was this.

DHCP conflict detection could record a blank MAC address for an occupied IP (37439), which made the conflict log useless for finding the offending device.

On Wi-Fi: a Wi-Fi 6 stability issue when clients roamed between SSIDs on the same radio (37426), air-monitor settings disappearing on Wi-Fi 6 models after upgrading to 8.6.0 (37718), and Wi-Fi WAN failing to roam back to a Fast Transition (802.11r) access point after visiting one without Fast Transition (37663). That last one hits RVers and boaters who use Wi-Fi WAN to connect to campground and marina networks. If you associated with a non-802.11r AP once, the router could get stuck and refuse to roam back to a better one that supports fast roaming.

Everything else

Rounding out the list: B One and B One Plus could crash after a USB reset (35984). GPS forwarding could generate malformed TAIP LN sentences (37436), which matters if you feed Peplink GPS data to a fleet tracking system that speaks TAIP. InControl could report no GPS fix when the location was actually coming from a cellular module rather than a dedicated GPS receiver (37160). Both Balance 1350 EC units in an HA pair could become master after a reboot with LACP on the SFP ports (37788), which is precisely the split-brain scenario HA is supposed to prevent. The device could reboot during QoS initialization (37505). Repeated GPS queries over SNMP could cause excessive memory usage (37627), a slow leak that would eventually take a monitored router down. CLI SSH could fail to start after being enabled (37465). Heavy client recognition traffic could cause repeated InControl disconnections (37214). Ethernet ports on RAMIPS models could fail to negotiate 100 Mbps with Energy Efficient Ethernet enabled (37500). InControl 2 displayed PoE usage against the wrong port numbers (37263). The Port Settings page showed a WAN port as LAN on the MAX Transit Duo Pro (37588). And long text could be clipped on the Balance 580X front panel display (37514).

Supported devices

8.6.1 RC1 supports the Balance 20X, Two, 310 HW5, 310 5G, 310 Fiber 5G, 310X, 380X, 580X, 305 HW2, 380 HW6, 580 HW2 and HW3, 710 HW3, 1350 HW2, 2500, 1350 EC, 2500 EC and 5000 EC; SDX and SDX Pro; HD1 Dome Pro, Dome Pro Duo and Dome Pro LR; MBX and MBX Mini; BR1 Mini HW3, BR1 Mini Core HW3, BR1 Mini 5G, BR1 Mini M2M, BR1 IP55 HW4, BR1 Pro (CAT-20) HW7, BR1 Pro 5G, BR2 Pro HW4, BR2 HW4 and BR2 Micro; Transit Pro E HW2 and Transit Duo Pro; MAX Orbit 2, 4 and 8; B One, B One Plus and B One 5G; MediaFast 500 and 750; UBR Plus; and EPX, PDX and FusionHub.

Note that older hardware revisions are not on the list. A Balance 20X HW1 through HW3 is supported, but if you have a first-generation BR1 Mini or an older Balance 310 you are on a different firmware track. Check the hardware revision on the sticker or the Web Admin dashboard before you download. If your hardware has aged out of the current firmware line, every model on the supported list above is available on the 5Gstore Peplink landing page.

5Gstore Take

This is a release candidate that reads like a maintenance release with a few significant features attached. The security items alone justify planning an upgrade. Native cellular IPv6 and the Synergy Mode licensing change are the two things we expect customers to ask about most, and both are worth a lab test now so you are ready when GA arrives.

Our recommendation for most customers is to test RC1 on one device this week, watch it for a few days, and stage a fleet rollout once Peplink promotes it to GA. If one of the resolved issues above is actively costing you uptime, especially the SpeedFusion, VLAN or Wi-Fi WAN roaming fixes, go ahead and move that site to RC1 now.

If you would like help planning a firmware rollout, choosing between Peplink models, or building out a Synergy Mode or IPv6 deployment, reach out to our team. We carry the full Peplink line along with Cradlepoint, Teltonika, Semtech, Inseego, Digi and Katalyst, and we can help you pick the right hardware for the job.

Browse the full Peplink lineup. You can also explore our other manufacturers: Cradlepoint, Teltonika, Semtech (Sierra Wireless), Inseego, Digi, and Katalyst.

Running Starlink alongside your Peplink? Check Your Coverage Area.

To download the firmware or report an issue with the release candidate, use the Peplink support ticket system and follow the discussion on the Peplink forum.

Frequently Asked Questions

Is Peplink firmware 8.6.1 RC1 safe to run in production?
Release candidates are close to final and many integrators run them on live sites, but they are not yet GA. Test on a single device first, back up your configuration, and use InControl 2 firmware groups for staged rollouts.

What is new in 8.6.1 RC1 compared to 8.6.1 Beta 1?
Two items are tagged RC 1: strengthened authentication and request validation for firmware uploads (37827) and a fix for Wi-Fi clients failing to get an IP address when a Synergy Controller manages multiple Synergized devices (37839). Everything else carried over from Beta 1.

Which Peplink routers get IPv6 on cellular in 8.6.1?
Devices with cellular modules coded LTEA-US, LTEA-K, LTE-E, LTEA-D, GLTE-G, LTEA-Q, LTEA-E, LTEA-R, LTE-EJ, LTE-MX, LTE-MXS or LTE-US, including the Balance 20X, 310 5G, 310 Fiber 5G, 310X, 380X and 580X, BR1 Pro (CAT-20), BR1 Pro 5G, BR2 Pro, Transit Pro E, B One Plus, B One 5G, EPX, PDX, and all SDX, Dome and MBX models.

Does Synergy Mode still require a Care plan?
No. As of 8.6.1, Care plan and license requirements have been removed for both Synergy Controllers and Synergized devices.

What does “Fixed in: 8.6.0s0xx” mean in the release notes?
It means the fix already shipped as a special build on top of 8.6.0, usually through a support ticket. 8.6.1 merges those special builds into the main firmware line.

Are there security fixes in 8.6.1 RC1?
Yes. Three Security Advisory items cover DHCP client hostname handling, Web Admin access control and the management CLI. Additional hardening covers API request handling, Device API input validation and firmware upload authentication.

Where do I download Peplink 8.6.1 RC1?
Release candidate firmware is available through the Peplink support portal and forum. Open a ticket or check the Peplink forum for the download thread.