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:
Gateway Services and Device-Side Agents
Designing for Real Operational Conditions
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.
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
Validated With Mango Cloud
We have also built unit, integration and system-level testing around the implementation.
The integration environment brings together:
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.
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.
