Extending OpenLAN to the Gateway: Router Architects Contributes a Go- Based uCentral Client to TIP
Open networking becomes much more powerful when openness extends beyond
individual devices.
An access point may be open. A switch may be open. A gateway may be open.
But for operators, the real value comes when those components can be provisioned,
managed and operated through a consistent architecture.
That is one of the goals behind the Telecom Infra Project's OpenLAN initiative:
creating an open, interoperable networking ecosystem spanning Wi-Fi, LAN
switching and WAN gateways.
At Router Architects, we have been actively contributing to that ecosystem.
Our latest contribution is a Go-based implementation of the uCentral client for
OpenLAN Gateway, submitted to the Telecom Infra Project's olg-ucentral-client
repository.
The contribution creates an important piece of the management path between an
OpenLAN Gateway and an OpenWiFi-compatible cloud controller.
From OpenWiFi to a Complete OpenLAN Network
OpenLAN: Enabling Control in WiFi Infrastructure
OpenWiFi demonstrated what an open and disaggregated approach to managed Wi-
Fi could look like.
OpenLAN is extending that model further.
The broader objective is a network in which operators are not limited to a vertically
integrated stack from a single networking vendor.
Instead, access points, switches, gateways and cloud management can evolve as
interoperable components.
For an ISP, MSP or enterprise operator, the resulting architecture can look much
closer to:
Wi-Fi + Switching + Gateway → Common Cloud Management
OpenLAN Gateway is an important part of that model.
The gateway sits at a critical point in the network, handling functions such as routing,
WAN connectivity, security and potentially edge applications.
But making the gateway open is only part of the problem.
It also needs a robust mechanism through which a cloud controller can securely
configure the gateway, execute operational commands and receive results.
That is the problem the uCentral client helps solve.
What We Have Built
Router Architects has developed a Go implementation of the OpenLAN Gateway
uCentral client.
At a high level, the architecture is:
OpenLAN / OpenWiFi Cloud Controller
↓
WebSocket + uCentral JSON-RPC + mTLS
OLG uCentral Client
↓
NATS / JetStream
Gateway Services and Device-Side Agents
The uCentral client acts as the bridge between the cloud management plane and the
services running inside the gateway.
On the cloud side, it maintains a persistent WebSocket connection and processes
uCentral JSON-RPC commands.
On the gateway side, it uses NATS and JetStream to communicate with the services
responsible for actually carrying out those operations.
This separation is important.
The cloud management layer does not need to understand the internal
implementation of every gateway platform. Device-specific execution can remain
behind the NATS interface while uCentral provides the common management
contract.
Designing for Real Operational Conditions
A production cloud-to-device client needs to handle considerably more than
translating messages between two protocols.
The implementation includes support for areas such as:
persistent WebSocket connectivity and reconnection
TLS and mutual TLS authentication
uCentral JSON-RPC request processing
NATS and JetStream integration
command routing
request correlation
transaction management
duplicate request handling
operation persistence
payload and schema validation
queueing and backpressure
configurable transaction timeouts
capability discovery
security validation
failure propagation
concurrent and out-of-order responses
The current implementation supports uCentral operations including configuration,
reboot, factory reset, LED control, firmware upgrade, certificate update, reenrollment,
script execution, ping, trace, telemetry-related requests and remote terminal access.
For configuration operations, the client also integrates the generated validator from
the TIP OpenLAN uCentral schema, allowing configuration to be checked before it is
dispatched to the gateway services.
More Than a Protocol Adapter
Some of the most important engineering work happens around conditions that are
less visible than the primary command flow.
What happens if the cloud connection drops?
What happens when NATS reconnects?
What happens if two state-changing commands arrive at the same time?
What happens when responses arrive out of order?
What happens when a configuration payload is malformed or unexpectedly large?
What happens when the downstream execution fails?
The client includes explicit handling for these scenarios.
For example, state-changing operations can be serialized to prevent conflicting
changes to the gateway, while non-state-changing operations can continue
independently.
Completed requests can be cached and replayed, helping protect against duplicate
processing.
The outbound scheduler also provides multiple priority levels so command
responses are not blocked behind lower-priority operational traffic.
Payload limits, bounded decompression, URL validation and TLS validation provide
additional protection around the cloud-to-gateway interface.
These capabilities may not be visible in a network management dashboard, but they
are essential when moving from a working demonstration to infrastructure that
operators can depend on.
Testing the Complete Command Path
We have also built unit, integration and system-level testing around the
implementation.
The integration environment brings together:
Cloud JSON-RPC → uCentral Client → NATS / JetStream → Downstream
Execution → Result → Cloud Response
Tests cover scenarios including successful commands, command failures,
malformed requests, unsupported operations, concurrent requests, out-of-order
responses and invalid configurations.
Beyond simulated environments, we wanted to verify interoperability against an
actual cloud implementation.
That is where Mango Cloud becomes particularly useful.
Validated With Mango Cloud
As part of the system-level testing, we validated the configure and trace workflows
against Mango Cloud v1.0.
Mango Cloud is our open-source cloud management platform for
OpenLAN/OpenWiFi networks.
These tests exercise the complete operational path:
Mango Cloud
→ uCentral JSON-RPC
→ OpenLAN Gateway uCentral Client
→ NATS
→ Gateway-side execution
→ Result correlation
→ Response back to Mango Cloud
This matters because interoperability should not exist only at the level of an
architecture diagram or API specification.
The components need to work together.
By using Mango Cloud as a real OpenWiFi-compatible controller during
development, we can test both sides of that boundary: the cloud management
platform and the gateway management client.
It also brings us closer to the broader vision we have for Mango Cloud — a common
operational platform capable of managing more than Wi-Fi access points.
Toward One Operational Model for Wi-Fi, LAN and WAN
Operators rarely think about their networks as isolated product categories.
An end-user connectivity issue might originate at the access point, the Ethernet
switch, the gateway, the WAN connection or somewhere upstream.
Yet many networks are still managed through independent systems for each layer.
OpenLAN creates an opportunity to change that.
TIP describes OpenLAN as an open, interoperable ecosystem designed to provide
greater hardware, software and cloud choice while reducing vendor lock-in.
OpenLAN Gateway extends that architecture to routing, security and WAN gateway
functions.
We see cloud management as a critical part of making that architecture operational.
Our objective with Mango Cloud is therefore broader than simply building another
Wi-Fi controller.
We are working toward a platform capable of providing a common operational model
across:
Access Points
Switches
Gateways
and, over time, the services and automation surrounding them.
The OpenLAN Gateway uCentral client is one of the foundational components
needed to make that model possible.
Open Source Is Something You Build
For Router Architects, participation in open networking is not primarily about
consuming open-source software.
It is about engineering the infrastructure, solving the difficult integration problems,
testing interoperability and contributing that work back to the ecosystem.
The OpenLAN Gateway uCentral client contribution is another step in that direction.
There is still work ahead, and the contribution is currently going through the TIP
review process.
But the direction is clear:
Open devices.
Open management interfaces.
Interoperable cloud platforms.
And a common operational model across the network.
That is the kind of open networking infrastructure we want to help build.
Explore the contribution: Telecom Infra Project — olg-ucentral-client PR #2
Explore Mango Cloud: Open-source cloud management for OpenLAN/OpenWiFi
networks
About Router Architects: We build and contribute open connectivity infrastructure
spanning OpenWiFi, OpenLAN, cloud management, gateways and AI-powered
network operations.
