When OpenWiFi devices are unable to connect to the cloud during their initial power on from factory, this may be a result of Internet connectivity issues.

Certain WAN connections may require credentials such as a username and password or a mobile configuration or simply static address assignment instead of dynamic.

OpenWiFi 2.0 supports these scenarios. When a device does not have an existing configuration and is unable to contact the cloud for provisioning it enters "Maverick" mode.

For all Wi-Fi devices this means a Wi-Fi network with the SSID 'Maverick' will become available. Association with and logging in to the device will permit initial WAN connectivity to be entered.

Using Maverick

After association to the Maverick SSID, open a web browser to http://192.168.1.1 Log into the OpenWiFi device with username: root and password: openwifi

When the page above is displayed, begin to configure Uplink based on the WAN requirements of the deployment.

If connection uses Point to Point over Ethernet (PPPoE) username and password credentials, enter those values and save.

If the OpenWiFi device has a Cellular connection which is possible on device models with 4G and 5G radios, the network Access Point Name (APN) and PIN will be required. These values are supplied by your mobile network provider.

When dynamic address allocation is not available, static IP address assignment may be required. IPv4 and IPv6 are supported, enter these values with DNS address and save.

Otherwise leave the Uplink configuration to DHCP or cloud defaults.

Manual Redirector and Certificate Upload

If under rare circumstances it is not possible to discover the OpenWiFi cloud associated with the device or there is a need to replace device certificates, this may be configured in Settings.

System

It is possible to reset the device to defaults, or locally update firmware using the commands available from System.

****

All TIP OpenWiFi devices use the same cloud discovery mechanism on initial boot.

OpenWiFi devices ship from factory with a unique device certificate signed by the Telecom Infra Project Certificate Authority.

When a device boots for the first time, or is factory reset, a 'first-boot' process occurs within the device. First-boot initiates a connection over HTTPs to the Certificate Authority requesting the unique device record information. All connections to the Certificate Authority occur over mTLS encrypted session. Devices use their unique certificate identity to authenticate and retrieve the location of the assigned cloud.

Once the cloud location has been learned from first-boot, the device no longer depends on this cloud discovery and will return to the assigned cloud learned from first-boot.

Devices may periodically initiate connection to the Certificate Authority to validate their unique certificate status. This is a normal process involved in mutual TLS security models.

When an operator or end customer seeks to change the cloud associated with their device(s), the value of the cloud stored in the Certificate Authority device record is updated. A factory reset of the device will cause first-boot to re-occur which will then discover the new cloud.

TIP OpenWiFi ODM partners are able to manage device records directly using the Certificate Authority portal. All other users should send an email to licensekeys@telecominfraproject.com to request update of cloud discovery.

There could be reasons cloud discovery does not complete. These include:

• Lack of Internet Connectivity

  • Device may require additional WAN settings

  • Network may not be connected to Internet

• No Configuration of Cloud in Certificate Authority

  • Manufacturer may have left this value blank in the device record stored in Certificate Authority

When the cloud can not be automatically discovered, OpenWiFi devices will turn on a local admin web UI made available via SSID "Maverick".

The Maverick UI will support configuring WAN interface parameters, including DHCP, Static, PPPoE, and LTE/5G settings. Please see Local Device Settings for details on using Maverick. Additionally the Maverick UI supports direct entry of the cloud for cases when the cloud value has not been supplied during manufacture.

For non-Wi-Fi devices such as PoE access switches, the same cloud location information may be configured using local management interface.

Access Point Network OS (APNOS)

License: BSD-3-Clause

• Openwrt based APNOS: https://github.com/Telecominfraproject/wlan-ap/tree/release/v2.4.0

Controller SDK

License: BSD-3-Clause

• Gateway Service: https://github.com/Telecominfraproject/wlan-cloud-ucentralgw/tree/release/v2.4.0

• Gateway UI: https://github.com/Telecominfraproject/wlan-cloud-ucentralgw-ui/tree/release/v2.4.0

• Security Service: https://github.com/Telecominfraproject/wlan-cloud-ucentralsec/tree/release/v2.4.0

• Firmware Service: https://github.com/Telecominfraproject/wlan-cloud-ucentralfms/tree/release/v2.4.0

• Provisioning Service:https://github.com/Telecominfraproject/wlan-cloud-owprov/tree/main

• Provisioning UI: https://github.com/Telecominfraproject/wlan-cloud-owprov-ui/tree/main

Testing

License: BSD-3-Clause

• Open Test Harness and Test cases: https://github.com/Telecominfraproject/wlan-testing/tree/master

SDK Load Simulator

License: BSD-3-Clause

• OpenWiFi Load Simulator (OWLS): https://github.com/Telecominfraproject/wlan-cloud-owls/tree/main

Deployment

License: BSD-3-Clause

• Helm and Docker Compose Deployments: https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/tree/release/v2.4.0

OpenWiFi 2.0 Minimum Viable Product at the end of July, 2021 enables a cloud native and cloud agnostic Software Development Kit (SDK) with management and deployment support for a wide range of Access Point and PoE network switch platforms.

Initial release 2.0 SDK includes:

• Zero Touch Cloud Discovery

• Firmware Management

• User Interface

  • Device List

  • Device Reboot

  • Device LED Blink

  • Device Remote Packet Capture

  • Device Configuration

  • Device Factory Reset

  • Device Remote TTY shell

  • Remote Wi-Fi Scan

  • Associations

    • UE (Wi-Fi Clients)

    • Mesh and WDS Clients

    • MCS, NSS, RSSI, Channel, SSID, Tx/Rx

  • Device Health Check

  • Interface Statistics

  • Device Command History

Upcoming sprint for August includes Dynamic Provisioning service support for template based device configuration.

OpenWiFi 2.0 SDK is deployable as both a Docker Compose or a Helm on Kubernetes model. See Release 2.0 SDK section for installation instructions.

New in this Release

• Firmware

  • Basic Features for OpenWiFi Switching

  • Passpoint

    • NAPTR Functionality

    • Proxy Static Routing

    • HSP Auth / Acc Service Discovery

    • Last Resort Proxy

    • RADIUS OpenRoaming Compliance

  • External 3rd Party Captive Portal Redirect

  • Burst Rate Ad-Hoc Telemetry

  • Static Routing

  • CS1 Merge - Wi-Fi 6

  • IEEE802.1d STP Control

  • Timestamp on Health Check messages

  • L2 DHCP Relay

  • Station Association Idle and Session time

• SDK

  • OpenWiFi Provisioning Service

  • OpenWiFi Inventory Service

  • Multi Tenant Support

  • Service Group - Venues

  • Logical Regions - Entities

Initial Minimum Viable Product Release 2.0 does not include template driven device provisioning, this will be available in the next sprint.

Given many cloud and ODM partners wish to consume the 2.0 reference stack early, some with their own device provisioning logic as part of commercial cloud controllers, the following describes uCentral based management and telemetry, interactions with the OpenWiFi SDK processing provisioning and telemetry data.

Device Interactions with SDK

All devices are known to the cloud by their unique id and provisioned based on advertised capabilities. Each configuration generates a new unique hash value to ensure as devices report back to the cloud, their configuration state is guaranteed.

If the cloud sends invalid configuration data or the device has insufficient ability to complete the provisioning commands, the error handling process will send this response back to the cloud.

For example results returned to SDK from a device configuration error:

Release 2.0 SDK offers a number of ways to consume OpenWiFi. Available as a single Docker for just the uCentralGW or as a set of micro services offering increasing value to consume helps multiple eco-system partners use as much or as little as desired to integrate with or build a commercial product on the TIP OpenWiFi SDK.

Features of the 2.0 SDK at July MVP include:

• RBAC based security framework

• OpenAPI compliant Northbound

• Kafka Message Bus

• PGSql HA Cluster

• Firmware Manager

• Central Logging Dashboard

• User Interface

• Docker Compose & Helm DevOps Deployment Automation