OpenWiFi
2.4.0
2.4.0
  • OpenWiFi Release 2.4 GA
  • Ordering OpenWiFi APs
  • Device Partner Information
  • Cloud Partner Information
  • Getting Started
    • Cloud Discovery
      • Discovery without Cloud
    • Release 2.0 SDK
    • Access Points
      • Local Device Settings
    • Repositories
  • Provisioning
    • Data Model Introduction
    • Creating a Configuration
  • User Interface
    • Devices
      • Commands
      • Statistics
      • Command History
    • Firmware
  • API
    • OpenAPI Definitions
    • Security Service
    • Gateway Service
    • Firmware Management Service
  • Monitoring
    • ELK Integration
  • SDK Installation
    • Overview
    • Deploy using Docker Compose
    • Deploy using Helm
  • Configuration Examples
    • Basic Device Provisioning
      • Bridge Mode SSID
      • NAT Gateway Mode SSID
      • Multi-VLAN SSID
    • Device Feature Configuration Examples
      • Zero Touch Provisioning
      • DHCP Relay
      • Services
      • Metrics
      • GRE
      • L2TP
      • VxLAN
      • WDS
      • Mesh
      • QoS
      • Dynamic Air Time Fairness
      • Dynamic Subscriber QoS
      • Captive Portal
        • External Captive Portal
      • ExpressWiFi
      • Roaming RRM and SON
      • RADIUS Authenticated SSID
        • Dynamic VLANs with RADIUS
      • Multi-PSK (MDU Shared Key)
      • Dynamic Air-Time Policy
      • Passpoint®
        • Configuration Introduction
        • Advertising Services
        • Passpoint® Configuration
      • Switching
        • Port Speed
  • Release Notes
    • Features
    • Security
    • Resolved Issues
  • Test Automation Framework
    • Overview
Powered by GitBook
On this page
  1. Getting Started

Cloud Discovery

TIP OpenWiFi 2.0

PreviousGetting StartedNextDiscovery without Cloud

Last updated 3 years ago

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.

Device First Boot / Factory Cloud Discovery