mirror of
https://github.com/Telecominfraproject/wlan-docs.git
synced 2025-11-16 18:05:10 +00:00
GitBook: [#1] No subject
This commit is contained in:
Jaspreet Sachdev
committed by
gitbook-bot
gitbook-bot
parent
97caf995c6
commit
a3dea0eaea
25
sdk/getting-started.md
Normal file
25
sdk/getting-started.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
description: TIP OpenWiFi 2.x
|
||||
---
|
||||
|
||||
# Getting Started
|
||||
|
||||
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.
|
||||
|
||||
## Release 2.6 SDK includes:
|
||||
|
||||
* Zero Touch Cloud Discovery
|
||||
* Firmware Management
|
||||
* Venue Provisioning 
|
||||
* Analytics Aggregation
|
||||
* Venue Dashboards 
|
||||
* User Interface for Provisioning & Analytics
|
||||
* Gateway Service - RADIUS Proxy
|
||||
|
||||
|
||||
|
||||
OpenWiFi 2.0 SDK is deployable as both a Docker Compose or a Helm on Kubernetes model. See [this](broken-reference) section for installation instructions.
|
||||
|
||||
|
||||
|
||||
Find out what is [new](../release/whats-new.md) in our current release.
|
||||
181
sdk/monitoring/README.md
Normal file
181
sdk/monitoring/README.md
Normal file
@@ -0,0 +1,181 @@
|
||||
---
|
||||
description: OpenWiFi 2.0 Telemetry and Analysis
|
||||
---
|
||||
|
||||
# Monitoring
|
||||
|
||||
TIP OpenWiFi software stack is envisioned to have a rich telemetry data that can be extracted, transformed and stored for analytics purposes. This section will outline various integration using the current capabilities of the OpenWiFi release. These integrations will provide examples for the community to enrich, adopt and productize.
|
||||
|
||||
The current release of OpenWiFi utilizes both a rich open API and Kafka for retrieving telemetry information from Access Points and SDK services. For the purpose of this section and Release 2.0 we will be showcasing Kafka integration with 3rd-party monitoring subsystems.
|
||||
|
||||
## Kafka Data Source
|
||||
|
||||
The current release of 2.0 SDK architecture contains a Kafka broker for the purposes inter-services communication, state, healthcheck, device provisioning state producing and consuming Kafka topics. You can find the latest information related to Kafka topics here: [https://github.com/Telecominfraproject/wlan-cloud-ucentralgw/blob/master/KAFKA.md#kafka-integration](https://github.com/Telecominfraproject/wlan-cloud-ucentralgw/blob/master/KAFKA.md#kafka-integration)
|
||||
|
||||
The current Kafka topics used for this monitoring integration are:
|
||||
|
||||
* state
|
||||
* healthcheck
|
||||
|
||||
All Kafka messages carry a JSON payload, example of a healthcheck message is as follow:
|
||||
|
||||
```
|
||||
{
|
||||
"system":{
|
||||
"id":179033843641952,
|
||||
"host":"https://gw-ucentral-dev01.cicd.lab.wlan.tip.build:17002"
|
||||
},
|
||||
"payload":{
|
||||
"data":{
|
||||
"interfaces":{
|
||||
"up0v0":{
|
||||
"dhcp":false,
|
||||
"location":"/interfaces/0"
|
||||
}
|
||||
},
|
||||
"unit":{
|
||||
"memory":36
|
||||
}
|
||||
},
|
||||
"sanity":67,
|
||||
"serial":"112233445566",
|
||||
"uuid":1627357625
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
A state Kafka message looks like:
|
||||
|
||||
```
|
||||
{
|
||||
"system":{
|
||||
"id":179033843641952,
|
||||
"host":"https://gw-ucentral-dev01.cicd.lab.wlan.tip.build:17002"
|
||||
},
|
||||
"payload":{
|
||||
"serial":"112233445566",
|
||||
"state":{
|
||||
"interfaces":[
|
||||
{
|
||||
"clients":[
|
||||
{
|
||||
"ipv6_addresses":[
|
||||
"fe80:0:0:0:206:aeff:fee0:69ad"
|
||||
],
|
||||
"mac":"07:06:06:06:06:06",
|
||||
"ports":[
|
||||
"eth1"
|
||||
]
|
||||
},
|
||||
{
|
||||
"ipv4_addresses":[
|
||||
"192.168.4.1"
|
||||
],
|
||||
"mac":"01:02:03:04:05:06",
|
||||
"ports":[
|
||||
"eth1"
|
||||
]
|
||||
}
|
||||
],
|
||||
"counters":{
|
||||
"collisions":0,
|
||||
"multicast":63,
|
||||
"rx_bytes":14725,
|
||||
"rx_dropped":0,
|
||||
"rx_errors":0,
|
||||
"rx_packets":209,
|
||||
"tx_bytes":13571,
|
||||
"tx_dropped":0,
|
||||
"tx_errors":0,
|
||||
"tx_packets":80
|
||||
},
|
||||
"dns_servers":[
|
||||
"1.1.1.1",
|
||||
"9.9.9.9"
|
||||
],
|
||||
"ipv4":{
|
||||
"addresses":[
|
||||
"192.168.4.33/24"
|
||||
],
|
||||
"leasetime":600
|
||||
},
|
||||
"location":"/interfaces/0",
|
||||
"name":"up0v0",
|
||||
"uptime":31349
|
||||
},
|
||||
{
|
||||
"counters":{
|
||||
"collisions":0,
|
||||
"multicast":0,
|
||||
"rx_bytes":0,
|
||||
"rx_dropped":0,
|
||||
"rx_errors":0,
|
||||
"rx_packets":0,
|
||||
"tx_bytes":1058,
|
||||
"tx_dropped":0,
|
||||
"tx_errors":0,
|
||||
"tx_packets":5
|
||||
},
|
||||
"ipv4":{
|
||||
"addresses":[
|
||||
"192.168.1.1/24"
|
||||
]
|
||||
},
|
||||
"location":"/interfaces/1",
|
||||
"name":"down1v0",
|
||||
"uptime":31355
|
||||
}
|
||||
],
|
||||
"radios":[
|
||||
{
|
||||
"active_ms":24459917,
|
||||
"busy_ms":1173593,
|
||||
"channel":149,
|
||||
"channel_width":"80",
|
||||
"noise":4294967198,
|
||||
"phy":"soc/40000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0",
|
||||
"receive_ms":4647,
|
||||
"transmit_ms":88272,
|
||||
"tx_power":30
|
||||
},
|
||||
{
|
||||
"active_ms":24456321,
|
||||
"busy_ms":11878205,
|
||||
"channel":11,
|
||||
"channel_width":"20",
|
||||
"noise":4294967204,
|
||||
"phy":"platform/soc/a000000.wifi",
|
||||
"receive_ms":1329,
|
||||
"transmit_ms":73228,
|
||||
"tx_power":30
|
||||
},
|
||||
{
|
||||
"active_ms":24458178,
|
||||
"busy_ms":1162312,
|
||||
"channel":36,
|
||||
"channel_width":"80",
|
||||
"noise":4294967192,
|
||||
"phy":"platform/soc/a800000.wifi",
|
||||
"receive_ms":12339,
|
||||
"transmit_ms":86904,
|
||||
"tx_power":23
|
||||
}
|
||||
],
|
||||
"unit":{
|
||||
"load":[
|
||||
0.190921,
|
||||
0.263188,
|
||||
0.240726
|
||||
],
|
||||
"localtime":1627418941,
|
||||
"memory":{
|
||||
"free":348540928,
|
||||
"total":520409088
|
||||
},
|
||||
"uptime":31386
|
||||
}
|
||||
},
|
||||
"uuid":1627357625
|
||||
}
|
||||
}
|
||||
```
|
||||
21
sdk/monitoring/elk-integration.md
Normal file
21
sdk/monitoring/elk-integration.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
description: Kafka integration with ELK
|
||||
---
|
||||
|
||||
# ELK Integration
|
||||
|
||||
The following pipeline is used to leverage Kafka messages being emitted from OpenWiFi 2.0 for ELK (Elastic Logstash Kibana) stack integration :
|
||||
|
||||
|
||||
|
||||
TIP OpenWiFi project has deployed an ELK stack for community members to access [here](https://kibana.lab.wlan.tip.build).
|
||||
|
||||
The key for this integration is to use a plugin that enables Kafka to be used as an input for Logstash. This plugin can be found [here](https://www.elastic.co/guide/en/logstash/current/plugins-inputs-kafka.html). Once installed then Logstash can be configured to listen to the input source of the Kafka broker that is deployed as part of OpenWiFi SDK 2.0 release and its appropriate topics. Here is a [sample](https://github.com/Telecominfraproject/wlan-cloud-ucentral-analytics) Logstash configuration.
|
||||
|
||||
It is important to note that Logstash provides the ability to transform messages which then can be pushed to Elasticsearch for storage with effective indexing. Finally Kibana is used to create visualization such as this:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The following [repository](https://github.com/Telecominfraproject/wlan-cloud-ucentral-analytics) will be used to store necessary files for integration examples for monitoring.
|
||||
33
sdk/provisioning/README.md
Normal file
33
sdk/provisioning/README.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
description: uCentral Data Model Introduction
|
||||
---
|
||||
|
||||
# Provisioning for Integrators
|
||||
|
||||
OpenWiFi 2.x makes it possible for integrators of the SDK to implement commercial products leveraging OpenWiFi Gateway service with vendor supplied provisioning above OpenWiFi SDK. As a minimum, the OpenWiFi 2.0 SDK framework offers a Security service which handles all OpenAPI authentication northbound, and the Gateway service which provides all uCentral websocket interface functionality southbound.
|
||||
|
||||
.png>)
|
||||
|
||||
OpenWiFi also provides options to receive telemetry and events over both OpenAPI interface as well as Kafka message bus. When using Kafka, OpenWiFi Gateway directly publishes telemetry and event topics to the bus.
|
||||
|
||||
In future sprints of OpenWiFi dynamic device provisioning will be available as an added microservice.
|
||||
|
||||
## Gateway
|
||||
|
||||
OpenWiFi 2.0 Gateway implements the uCentral device management interface. uCentral specifies the data model and interface for management and telemetry of OpenWrt based devices. Gateway uCentral interface is a websocket JSON-RPC based design between OpenWiFi Gateway and the device running uCentral agent.
|
||||
|
||||
.png>)
|
||||
|
||||
All communications from Gateway to Device are secured using mutual Transport Layer Security (mTLS). In mTLS systems each endpoint is a unique device sharing the same signed root or intermediate trust. In OpenWiFi each device has a signed certificate, key and device identifier. These are validated by the uCentral-Gateway to establish mTLS session.
|
||||
|
||||
Upon successful connection the device exchanges its capabilities with the OpenWiFi SDK. OpenWIFi SDK, via the Gateway microservice will send the entire device provisioning data as a JSON payload. Within OpenWiFi devices, the uCentral agent has a reader and renderer process providing serialization and validation of data sent from cloud. If any data presented can not be processed by the local agent, this is returned within an ERROR message using the same websocket connection.
|
||||
|
||||
 (2).png>)
|
||||
|
||||
If the device agrees with provisioning information presented, the render process builds calls into the operating system configuration sub-system known as UCI. The Unified Configuration Interface ensures OpenWrt compliant syntax is persisted within the device.
|
||||
|
||||
Configuration source of truth is the OpenWiFi SDK. Consistency of device configuration is handled with an applied hash compared by the Gateway for each device. If the value differs on device from that of the stored information in cloud, the device will be immediately resent its configuration from the OpenWiFi SDK Gateway service.
|
||||
|
||||
Once present, all configuration data is preserved on device restart.
|
||||
|
||||
It is possible to generate device configurations outside of the OpenWiFi 2.0 SDK as shown in the minimum SDK image at the start of this page. This may occur for some integrations or may occur when the OpenWiFi Provisioning microservice is not present. In this way, integrators of commercial products are welcome to build device provisioning outside of OpenWiFi and use the OpenWiFi cloud to manage the scale, state, security and validation of device websocket communications.
|
||||
195
sdk/provisioning/creating-a-configuration.md
Normal file
195
sdk/provisioning/creating-a-configuration.md
Normal file
@@ -0,0 +1,195 @@
|
||||
---
|
||||
description: OpenWiFi 2.0 Device Configuration
|
||||
---
|
||||
|
||||
# Creating a Configuration
|
||||
|
||||
To introduce the Community to the uCentral data model structure, the below illustrates a basic Access Point configuration that assumes a typical enterprise Wi-Fi scenario of a ceiling mount or wall mount device presenting a single WAN interface with a private management network and separate Wi-Fi network on a virtual local area network.
|
||||
|
||||
## Start with Location and Radios
|
||||
|
||||
We will set the unit location and timezone, then proceed to configure radios.
|
||||
|
||||
```
|
||||
{
|
||||
"uuid": 2,
|
||||
"unit": {
|
||||
"location": "TIP Lab Network",
|
||||
"timezone": "EST+5EDT,M3.2.0/2,M11.1.0/2"
|
||||
},
|
||||
"radios": [
|
||||
{
|
||||
"band": "5G",
|
||||
"country": "CA",
|
||||
"channel": "auto",
|
||||
"channel-mode": "HE",
|
||||
"channel-width": 80,
|
||||
"require-mode": "HT",
|
||||
"rates": {
|
||||
"beacon": 6000,
|
||||
"multicast": 24000
|
||||
}
|
||||
},
|
||||
{
|
||||
"band": "2G",
|
||||
"country": "CA",
|
||||
"channel": 11,
|
||||
"channel-mode": "HE",
|
||||
"channel-width": 80,
|
||||
"require-mode": "HT",
|
||||
"rates": {
|
||||
"beacon": 6000,
|
||||
"multicast": 24000
|
||||
}
|
||||
}
|
||||
],
|
||||
```
|
||||
|
||||
In this example, a two radio device that indicates it is Wi-Fi 6 as the channel-mode values for both radios is "HE" which defines 802.11ax operation. Valid values are "HT" -High Throughput 802.11n mode, "VHT" - Very High Throughput 802.11ac mode, "HE" - High Efficiency 802.11ax mode.
|
||||
|
||||
Channel defines the specific channel number the radio shall operate on as an integer from 1 - 171 and may also be set to a string for "auto" mode. Channel width permits configuring the amount of RF channel the radio will operator over from 20-40-80-160 including 8080 mode (also known as 80+80) .
|
||||
|
||||
OpenWiFi radios may be set to require UE clients to associate to a minimum standard such as excluding any 802.11b associations depicted above with "require-mode" set to "HT" meaning 802.11n or higher clients may associate.
|
||||
|
||||
Control of beacon interval and multicast rates is possible per radio as shown in the "rates" section.
|
||||
|
||||
## Interfaces
|
||||
|
||||
OpenWiFi 2.0 offers a highly flexible model for arranging network interfaces. Multi-port devices may be easily provisioned for numerous types of network segmentation and logical network configuration. We will start with a simple WAN that has a management IP and also a VLAN sub-interface for a logical SSID in a subsequent step.
|
||||
|
||||
```
|
||||
"interfaces": [
|
||||
{
|
||||
"name": "WAN",
|
||||
"role": "upstream",
|
||||
"services": [ "lldp", "dhcp-snooping" ],
|
||||
"ethernet": [
|
||||
{
|
||||
"select-ports": [
|
||||
"WAN*"
|
||||
]
|
||||
}
|
||||
],
|
||||
"ipv4": {
|
||||
"addressing": "dynamic"
|
||||
}
|
||||
},
|
||||
```
|
||||
|
||||
In the above configuration block we have a WAN interface, its role is "upstream" meaning it faces the upstream in terms of service it provides (WAN). This has a direct alignment to how the device interprets a physical or logical port participates in bridge forwarding domains.
|
||||
|
||||
Note we want this port to have an IP address for its management, therefore the "ipv4" configuration is associated as a child of any Ethernet WAN ports and set to DHCP.
|
||||
|
||||
### Common Config - VLAN on WAN for SSID
|
||||
|
||||
Imagine the OpenWiFi device is an enterprise Access Point mounted on a ceiling. These devices do not always have a LAN port. Also in an enterprise, it is likely the Wi-Fi services are in their own network segments and not subject to Network Address Translation (NAT). Since the enterprise would also not want Wi-Fi on the same network as Management, an 802.1Q Virtual LAN is used.
|
||||
|
||||
```
|
||||
{
|
||||
"name": "WAN100",
|
||||
"role": "upstream",
|
||||
"services": [ "lldp", "dhcp-snooping" ],
|
||||
"vlan": {
|
||||
"id": 100
|
||||
},
|
||||
"ethernet": [
|
||||
{
|
||||
"select-ports": [
|
||||
"WAN*"
|
||||
]
|
||||
}
|
||||
],
|
||||
```
|
||||
|
||||
In this next section of configuration, an additional logical interface associated to the WAN ports for the VLAN id of "100" is shown. Note there is no IP address associated to this interface, it is a layer 2 interface that will emit on any and all WAN ports with VLAN id 100.
|
||||
|
||||
To associate the Wi-Fi with the VLAN interface define, we continue within the WAN100 interface adding SSID services.
|
||||
|
||||
```
|
||||
"ssids": [
|
||||
{
|
||||
"name": "TIP OpenWiFi",
|
||||
"wifi-bands": [
|
||||
"5G", "2G"
|
||||
],
|
||||
"bss-mode": "ap",
|
||||
"encryption": {
|
||||
"proto": "psk2",
|
||||
"key": "OpenWiFi",
|
||||
"ieee80211w": "optional"
|
||||
}
|
||||
},
|
||||
"services": [ "wifi-frames"]
|
||||
```
|
||||
|
||||
Within the "ssids" configuration block we can process an array of SSIDs. Often there may be separate "2G" and "5G" configurations. We have grouped them in this introductory example for simplicity however "2G", "5G", "5G-lower", "5G-upper", "6G" are all valid options.
|
||||
|
||||
The "name" value is the advertised SSID clients will discover for this access point. Hidden is supported by setting the "hidden-ssid" to true. Which operating mode is determined by "bss-mode". The "bss-mode" is a highly flexible operating parameter to determine "ap", "sta", mesh", "wds-ap", "wds-sta", "wds-repeater" radio modes of operation.
|
||||
|
||||
Security of the SSID is determined using the "encryption" section. Many options are possible, in this initial example, a WPA-PSK2 shared key encryption is shown. Lastly, for devices that support, 802.11w protected management frames are defined as optional for this SSID. This may also be disabled or required.
|
||||
|
||||
Metrics for wifi-frames will be described next.
|
||||
|
||||
### Sending Data
|
||||
|
||||
Add metrics to our configuration that will help expose state of the Wi-Fi network and its services to the cloud.
|
||||
|
||||
```
|
||||
"metrics": {
|
||||
"statistics": {
|
||||
"interval": 120,
|
||||
"types": [ "ssids", "lldp", "clients" ]
|
||||
},
|
||||
"health": {
|
||||
"interval": 120
|
||||
},
|
||||
"wifi-frames": {
|
||||
"filters": [ "probe",
|
||||
"auth",
|
||||
"assoc",
|
||||
"disassoc",
|
||||
"deauth",
|
||||
"local-deauth",
|
||||
"inactive-deauth",
|
||||
"key-mismatch",
|
||||
"beacon-report",
|
||||
"radar-detected"]
|
||||
},
|
||||
"dhcp-snooping": {
|
||||
"filters": [ "ack",
|
||||
"discover",
|
||||
"offer",
|
||||
"request",
|
||||
"solicit",
|
||||
"reply",
|
||||
"renew" ]
|
||||
}
|
||||
},
|
||||
```
|
||||
|
||||
Within metrics it is possible to define the interval for sending information to the cloud. Additionally the type of information sent is defined here. In this example configuration there are associated services to interfaces along the way. This included LLDP and dhcp-snooping and wifi-frames.
|
||||
|
||||
Within each uCentral device, the agent has a global health check feature that includes memory, cpu, temperature operating states in addition to performing various network and service health tests. The interval at which these reports are sent to the cloud is configured within health.
|
||||
|
||||
For all SSIDs that have wifi-frames associated as a service, the listed management frame types will be gathered and sent to the cloud, on each interval.
|
||||
|
||||
To assist with fingerprinting and client troubleshooting, dhcp-snooping sends the cloud all current client DHCP and DHCPv6 state.
|
||||
|
||||
### Global Services
|
||||
|
||||
The final section of the simple configuration example turns on LLDP and SSH where those services were associated to interfaces listed above.
|
||||
|
||||
```
|
||||
"services": {
|
||||
"lldp": {
|
||||
"describe": "TIP OpenWiFi",
|
||||
"location": "LivingLab"
|
||||
},
|
||||
"ssh": {
|
||||
"port": 22
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The complete simple configuration file as described in this page may be downloaded here:
|
||||
29
sdk/provisioning/data-model-introduction.md
Normal file
29
sdk/provisioning/data-model-introduction.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
description: OpenWiFi 2.0
|
||||
---
|
||||
|
||||
# Data Model Introduction
|
||||
|
||||
OpenWiFi 2.0 data model for device management is based on uCentral.
|
||||
|
||||
uCentral is set to become a leading component of OpenWrt, as such will have a diverse, and worldwide developer and support base in open source.
|
||||
|
||||
Within the model it is possible to provision or return state for all aspects of an OpenWiFi based device easily structured as a JSON payload.
|
||||
|
||||
The complete data model may be found here :[ ](https://github.com/Telecominfraproject/wlan-ucentral-schema)[https://github.com/Telecominfraproject/wlan-ucentral-schema](https://github.com/Telecominfraproject/wlan-ucentral-schema)
|
||||
|
||||
## Organization
|
||||
|
||||
Each device has a Universally Unique Identifier (UUID). For each device, the configuration presented either manually, via the future Provisioning service from OpenWiFi or via a commercial controller generation of provisioning data, the high level relationships of the schema may be understood as follows.
|
||||
|
||||
.png>)
|
||||
|
||||
The unique device record has a set of top level configurations. A device is referred to as a 'unit' that may have a Description, Location, TimeZone as example. Each unit may have globals for IPv4 and IPv6 networks that are derived to lower lever interfaces in later generation.
|
||||
|
||||
Services and Metrics are associated with logical and physical interfaces. Services enable configuration of features such as LLDP or SSH, rTTY, IGMP, 802.1x, RADIUS Proxy, WiFi-Steering, or NTP and are then associated with Interfaces as desired.
|
||||
|
||||
Interfaces define upstream and downstream configuration over both Wi-Fi logical (SSID) and wired physical ports.
|
||||
|
||||
Metrics enable visibility to the cloud for numerous states of the device. These are associated per interface and may be sent in 60 second or greater intervals and include Statistics of SSID, LLDP, Clients. Also include Health check reports of device load, network reachability, temperature. To assist with fingerprinting DHCP-Snooping exposes numerous interactions of IP binding to clients. Additionally wifi-frames expose all 802.11 management frames to the SDK Gateway.
|
||||
|
||||
It is also possible to configure config-raw elements that will parse direct UCI commands once the device provisioning has been completed by the uCentral agent.
|
||||
20
sdk/sdk.md
Normal file
20
sdk/sdk.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
description: TIP OpenWiFi 2.6
|
||||
---
|
||||
|
||||
# Release 2.6 SDK
|
||||
|
||||
Release 2.6 SDK offers a number of ways to consume OpenWiFi. Available as a single Docker for just the uCentralGW or as a set of microservices 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.
|
||||
|
||||
Initial features of the 2.0 SDK at 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
|
||||
|
||||
.png>)
|
||||
77
sdk/user-interface/README.md
Normal file
77
sdk/user-interface/README.md
Normal file
@@ -0,0 +1,77 @@
|
||||
---
|
||||
description: OpenWiFi 2.0
|
||||
---
|
||||
|
||||
# User Interface for Admins
|
||||
|
||||
Release 2.0 user interfaces (UI) are designed as a Single-Page Application (SPA). \
|
||||
The UI serves as an example user interface built using React to demonstrate several interactions using the northbound OpenAPI. \
|
||||
Release 2.0 to 2.5 had a first generation of the UI framework. This first generation UI framework is seen for the Gateway and Firmware service. With the introduction of 2.6 and the Provisioning and Analytics services, a new UI for those specific SDK services has been introduced. 
|
||||
|
||||
All UI interactions consume the OpenAPI of the SDK services. 
|
||||
|
||||
The following describes the likely starting point for an Administrator. Using the Provisioning service to define how the Wi-Fi networks in Entity, Venue and device provisioning terms may optionally be defined. 
|
||||
|
||||
## Login to OpenWiFi SDK - Provisioning
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Default username is: **`tip@ucentral.com`** and password is: **`openwifi`**
|
||||
|
||||
On first login, the default user account will prompt to change password. This behavior is also available for all admin defined accounts added to the system. 
|
||||
|
||||
## **Base Navigation**
|
||||
|
||||
On initial login the Provisioning service places the user on the Inventory screen. 
|
||||
|
||||
|
||||
|
||||
Inventory enables the admin to visually identify OpenWiFi devices not currently assigned to an Entity, Create a new device, execute commands per device, inspect device details and view the device active state as shown in the Gateway service. 
|
||||
|
||||
#### Device Actions
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### View Details
|
||||
|
||||
|
||||
|
||||
Within Device Details, found via the magnifying glass per Inventory row, association to an Entity Parent is possible. Additionally setting the device Firmware policy to inherit the rule assigned based on its membership to a Parent and to require Release Candidates or permit any nightly build upgrade to apply. Additionally the device may be enrolled within RRM should its Entity and Venue membership be part of RRM processing. Device Class determines if the device should be restricted to an Entity, Venue, and an end Subscriber. 
|
||||
|
||||
Device-Specific Configuration will expose any overriding configuration data present for this specific device. Device specific configuration will override inherited configurations from lower priority templates. 
|
||||
|
||||
Computed Configuration will display the enumeration of all provisioned templates the device is associated with. These templates are inherited as a result of device membership within an Entity, Child Entity, Venue and or Child Venue from which configuration templates may have been defined based on the admin deployment. 
|
||||
|
||||
|
||||
|
||||
### Bulk Inventory API
|
||||
|
||||
The service API could be used to bulk load record formats in a common .csv structure using JSON. For example
|
||||
|
||||
\`\`\`
|
||||
|
||||
"SerialNumber",Name,Description,DeviceType,NoteText for example: d1300f7b0732,Manufacturer,Desc, edgecore\_spw2ac1200,OutdoorAP
|
||||
|
||||
\`\`\`
|
||||
|
||||
For each inventory record, the \`\`\`deviceType\`\`\` must match a valid OpenWiFi device type. For example:
|
||||
|
||||
\`\`\`
|
||||
|
||||
"deviceTypes": \[ "cig\_wf160d", "cig\_wf188", "cig\_wf194c", "edgecore\_eap101", "edgecore\_eap102",
|
||||
|
||||
"edgecore\_ecs4100-12ph", "edgecore\_ecw5211",
|
||||
|
||||
> ...]
|
||||
|
||||
\`\`\`
|
||||
|
||||
When inventory is assigned to a Venue, it can be allocated into a top-level parent such as the operator. Then, based on role access, operation's teams may choose to assign the device to a child entity within an operating division, or setup the device as a tenant of a managed Wi-Fi service for example.
|
||||
|
||||
Choosing to assign the device to a specific MDU location as an example can be done in one step from above.
|
||||
|
||||
##
|
||||
24
sdk/user-interface/device-provisioning/README.md
Normal file
24
sdk/user-interface/device-provisioning/README.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Provisioning
|
||||
|
||||
The OpenWiFi solution can be applied to a diverse number of use cases from enterprise networks, service provider access, and hotspots. OpenWiFi offers a variety of managed services from small to very large venues of roaming, client shared-key management, client steering, mobile offload, QoS-based services, and Layer 2 and Layer 3 breakout and overlay options. 
|
||||
|
||||
The Provisioning service provides a view into the network as a whole, and venues with entity-based control.
|
||||
|
||||
The provisioning service for OpenWiFi supports weighted order inheritance of configuration templates. These services and networks provide the greatest level of flexibility.
|
||||
|
||||
The system functions from a starting point of managed inventory assigned into entities, venues and optionally end subscribers. From this association, inheritance of entity, venue and subscriber configuration becomes possible where one to many configurations are processed including one to one when an inventory device such as a P2P link or Subscriber Gateway have unique operating data.
|
||||
|
||||
These features are present from the service over the web interface as well as via API for controller integration and OSS/BSS integration purposes.
|
||||
|
||||
With template inheritance, the aggregate of all inherited templates in the device association to Entity, Child, Venue, Child, Device Specific is possible. Overlapping configuration is controlled by the inherited template weight.  
|
||||
|
||||
### Entities
|
||||
|
||||
Initial deployment of the Provisioning service will have an empty Entities tree. The Top Entity may be used for a number of actions or simply as a description for structure below this level. 
|
||||
|
||||
|
||||
|
||||
For example, an operator may choose to simply rename this Top Entity as "Operator Name" and set Firmware Upgrade and RRM policies to no actions accordingly. Creating child entities from this point defining perhaps an operational break down such as divisions within the operator, within which setting Firmware and or RRM rules may apply per division is possible. 
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
# Creating Entities
|
||||
|
||||
Entities represent a collection of resources for which certain business logic rules apply. 
|
||||
|
||||
Entities may hold: 
|
||||
|
||||
| Members of Entity | Description |
|
||||
| ----------------- | -------------------------------------------------------------------------- |
|
||||
| Entity | A child entity |
|
||||
| Venue | A logical aggregation of devices, configurations, locations with Analytics |
|
||||
| Configuration | Provisioning templates |
|
||||
| Inventory | Device members |
|
||||
| Locations | Device locations |
|
||||
| Contacts | Administrative contact information |
|
||||
| Resources | Global common resources such as RADIUS services |
|
||||
|
||||
@@ -0,0 +1,103 @@
|
||||
# Configurations
|
||||
|
||||
Device provisioning occurs based on inventory association to configuration templates.
|
||||
|
||||
Creating a template begins with the Configurations tab and creating a new template. 
|
||||
|
||||
|
||||
|
||||
### Create
|
||||
|
||||
Create Configuration dialog requires a name and one or multiple device types to apply configuration with. If device inventory within an Entity or a Venue exist with no configuration templates matching Device Types of the associated inventory, no associated provisioning will apply to those devices. This is the basic logic that enables unique Wi-Fi device type configurations to be layered through the system. 
|
||||
|
||||
###  
|
||||
|
||||
|
||||
|
||||
Limiting the configuration to a subset of device types is done through selection of available Device Types via pull down menu. 
|
||||
|
||||
|
||||
|
||||
A possible scenario may be that at such a top level, the operator wishes to set transmit power, MIMO operation where the Wi-Fi 6 2x2 top level configuration is defined. 
|
||||
|
||||
To include configuration parameters, select Add Subsection and choose the appropriate values. 
|
||||
|
||||
|
||||
|
||||
In this example we will choose Radios and define the MIMO and Tx Power. 
|
||||
|
||||
|
||||
|
||||
Begin with describing the Radio operating mode, assign a weight that may be either low enough to be overridden by further entity or venues or high enough to not be overridden, then Add Radio. 
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
OpenWiFi supports all possible Wi-Fi radio bands. Select the desired radio(s) and continue. 
|
||||
|
||||
#### Radio General
|
||||
|
||||
|
||||
|
||||
General properties, the following may be configured:
|
||||
|
||||
| Option | Description |
|
||||
| --------------- | ------------------------------------ |
|
||||
| Band | Frequency Band |
|
||||
| Bandwidth | 5,10,20 MHz channel narrow operation |
|
||||
| Country | Operating Country aka Country Code |
|
||||
| Channel-Mode | Operating Mode HT, VHT, HE |
|
||||
| Channel-Width | Total channel bandwidth |
|
||||
| Channel | Operating channel frequency |
|
||||
| MIMO | Values of 1x1 - 8x8 |
|
||||
| TX-Power | Transmission power in dBm |
|
||||
| Legacy-Rates | Allow 802.11b rates |
|
||||
| Maximum-Clients | Total UEs Permitted |
|
||||
| Multiple-BSSID | Multiple BSSID IE advertisment |
|
||||
|
||||
#### Radio Advanced 
|
||||
|
||||
|
||||
|
||||
Advanced Settings, the following may be configured:
|
||||
|
||||
| | |
|
||||
| ----------------- | --------------------------------------------------------------------------------------------------------------------- |
|
||||
| Beacon-Rate | Value 1-54Mb/s Beacon Frame Rate |
|
||||
| Beacon-Interval | Interval of Beacon Frames in ms |
|
||||
| DTIM-Period | Value 1-255 Delivery Traffic Information Message |
|
||||
| Hostapd-iface-raw | Directly configure hostapd parameters not part of OpenWiFi data model |
|
||||
| Multicast | Multicast frame rate in Mb/s |
|
||||
| EMA | Multi-BSSID broadcast using EMA |
|
||||
| BSS-Color | BSS Coloring 0-disable, 1-63 manual, 64 random |
|
||||
| Require-Mode | Minimum 802.11 UE standard permitted to associate. None - disabled, HT - a,b,g,n, VHT - a,b,g,n,ac, HE- a,b,g,n,ac,ax |
|
||||
|
||||
|
||||
|
||||
When complete, Save the "Top Level Wi-Fi 6 2x2" configuration for the device types chosen that align to such a radio mode. 
|
||||
|
||||
### Inheriting Advanced Radio Configuration
|
||||
|
||||
For purpose of demonstration, if the admin were to create another Configuration template with the same weight as the previous template defining the Advanced parameters, these could then be broken down for example by device type. 
|
||||
|
||||
Create another template as described for only one of the Wi-Fi 6 2x2 APs we have shown thus far. 
|
||||
|
||||
|
||||
|
||||
Setting specific configuration for the EAP 101 advanced radio parameters. For example, if a device in this entity is an EAP 101, it will have advanced radio properties of 12Mb/s beacon rate, 24Mb/s multicast rate, random BSS color and require HE mode. 
|
||||
|
||||
|
||||
|
||||
With these settings saved, multiple configuration templates are now shown that will influence radio operating parameters equally yet separately based on device type. 
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
# Metrics Settings Example
|
||||
|
||||
A common example is to inherit the desired telemetry for all devices spanning all types, at a top level. 
|
||||
|
||||
It remains possible to override the values shown here, perhaps to a faster interval, for the required telemetry data defined at the top level. 
|
||||
|
||||
|
||||
|
||||
### Create Configuration
|
||||
|
||||
Create a general configuration, select Metrics as the Configuration Section. 
|
||||
|
||||
|
||||
|
||||
Within the Subsections select all metrics types to be included and a weight for this template.
|
||||
|
||||
Available metrics:
|
||||
|
||||
| Metric | Description |
|
||||
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| WiFi Frames | Select Management Frame reports to send. Values include: Probe, Auth, Assoc, DeAuth, Disassoc, Local-Deauth, Inactive-Deauth, Key-Mismatch, Beacon-Report, Radar-Detected |
|
||||
| Statistics | Set Interval of all Statistics and types including: SSID, LLDP, Clients |
|
||||
| DHCP Snooping | Select the DHCP & DHCPv6 frames to send in telemetry including: ACK, DISCOVER, OFFER, REQUEST, REPLY, RENEW, SOLICIT |
|
||||
| Health | Interval to send automated health check score |
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
 
|
||||
|
||||
|
||||
|
||||
 
|
||||
@@ -0,0 +1,34 @@
|
||||
# Creating Venues
|
||||
|
||||
Venues are an important concept in OpenWIFi Provisioning. Venues inherit access to Analytics where incoming telemetry and client events are aggregated from the message bus, transformed and correlated based on the members of the Venue resulting in Venues Dashboard, Live Client quality connection analysis, and client tracking through the venue.
|
||||
|
||||
{% hint style="info" %}
|
||||
Venues may not exist beneath the root entity. Create an entity prior to defining a venue
|
||||
{% endhint %}
|
||||
|
||||
###  Create a Venue
|
||||
|
||||
Within a non-root entity, Create a Venue. 
|
||||
|
||||
|
||||
|
||||
Once the Venue exists, navigate into the Venue.
|
||||
|
||||
### Venue Configurations
|
||||
|
||||
Within a Venue, the RRM and Firmware management rules may be defined. Note Analytics are now an available option within the Venue. To track device and client statistics, enable Analytics.
|
||||
|
||||
|
||||
|
||||
Choose Edit and Start Monitoring. This will enable the admin to determine the interval of analytic data aggregation, and the data retention window in days. 
|
||||
|
||||
|
||||
|
||||
When Analytics are enabled, the Dashboard is populated. As devices are associated to the Venue, their telemetry data is aggregated by Analytics service and correlated for display via Dashboard, Live View and Client Lifecycle.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
# Configurations
|
||||
|
||||
Within the example Venue, creating configuration templates for SSIDs and or other configuration sections are possible. These configurations are inherited by device memberships at the Venue level. 
|
||||
|
||||
It is therefore possible to define many Venues, Child Venues, and Inventory associations that will then inherit global templates from entities in addition to aggregation of Venue templates. 
|
||||
|
||||
@@ -0,0 +1,41 @@
|
||||
# VAP - SSID
|
||||
|
||||
An SSID may be associated to any defined interface. This association ties the dataplane of the VAP together with the underlying interface services. 
|
||||
|
||||
Most common SSID configuration parameters have been exposed via the Provisioning UI. Consult the OpenWiFi data model for the full list of available configurations. 
|
||||
|
||||
From an interface select Add SSID.
|
||||
|
||||
|
||||
|
||||
Assigning the name of the SSID is also the name of the Wi-Fi network itself. Operating band of the SSID is configurable by radio. 
|
||||
|
||||
#### SSID Configuration Options
|
||||
|
||||
| Option | Description |
|
||||
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Name | SSID name |
|
||||
| BSS-Mode | <p>Operating mode of the wireless interface<br>Options: ap, sta, mesh, wds-ap, wds-sta</p> |
|
||||
| WiFi-Bands | Radio selection(s) of the SSID |
|
||||
| Authentication Protocol | <p>Wireless encryption of the BSS<br>Options: None, WPA-PSK, WPA2-PSK, PSK2-RADIUS, WPA-PSK/WPA2-PSK Personal Mixed, WPA-Enterprise, WPA2-Enterprise EAP-TLS, WPA-Enterprise-Mixed, SAE, WPA2/WPA3 Transitional, WPA3-Enterprise EAP-TLS, WPA3-192-Enterprise EAP-TLS</p> |
|
||||
| Authentication Key | Pre-Share dKey (when applicable) |
|
||||
| Authentication IEEE80211w | <p>Management Frame Protection <br>Options: disabled, optional, required</p> |
|
||||
| Advanced | |
|
||||
| Hidden-SSID | Disable Beacon Frame Broadcast |
|
||||
| Services | Services associated to the SSID logical interface |
|
||||
| Maximum-Clients | Total associations permitted to the SSID |
|
||||
| Purpose | <p>Role the SSID performs<br>Options: Default, Onboarding-AP, Onboarding-sta</p> |
|
||||
| Isolate-Clients | BSS client isolation |
|
||||
| Power-Save | Unscheduled Automatic Power Save Delivery |
|
||||
| Broadcast-Time | Beacon Time Broadcast |
|
||||
| Unicast-Conversion | Convert Multicast to Unicast over BSS |
|
||||
| Proxy-ARP | BSS respond to host ARP on behalf of another client |
|
||||
| Disassoc-Low-Ack | Disassociate stations based on excessive transmission failures or other indications of connection loss |
|
||||
| Vendor-Elements | This option allows embedding custom vendor specific IEs inside the beacons of a BSS in AP mode. |
|
||||
| Multi-PSK | Per device shared key to associate with unique VLAN |
|
||||
| Rate Limit | Ingress-rate and Egress-rate in Mb/s |
|
||||
| RRM | <p>Neighbor reporting<br>LCI measurement element content<br>Civic-Location element content<br>FTM-Responder Fine Timing Measurement<br>Stationary-AP</p> |
|
||||
| Roaming | <p>Message-Exchange <br>Generate PSK<br>Domain-Identifier<br>PMK-R0-Key-Holder<br>PMK-R1-Key-Holder</p> |
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
# WAN
|
||||
|
||||
Configure WAN interface as an upstream interface role type. 
|
||||
|
||||
OpenWiFi has the concept of a virtual dataplane where the definition of the interface role as upstream or downstream defines if the port involved will be mapped to WAN or LAN operation. 
|
||||
|
||||
It is possible to re-map any LAN port to function as a normal WAN port in this way. 
|
||||
|
||||
|
||||
|
||||
When the above Interfaces configuration section is created, respond to the dialog prompt to define an upstream WAN then select from the available configuration options to suit the local environment.
|
||||
|
||||
|
||||
|
||||
Within WAN(upstream) select the port(s) for use as WAN. 
|
||||
|
||||
A variety of Services features may be associated to logical interfaces. For this example, enable LLDP. 
|
||||
|
||||
IP Addressing set as IPv4 Dynamic will cause the WAN port to use DHCP for its provisioned internet access. IPv6 dual stack is also supported. 
|
||||
|
||||
|
||||
|
||||
58
sdk/user-interface/devices-view/README.md
Normal file
58
sdk/user-interface/devices-view/README.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
description: OpenWiFi 2.0 SDK
|
||||
---
|
||||
|
||||
# Devices
|
||||
|
||||
Each device presents Metrics and Health check data to the Gateway. Devices view displays this information in the following organization:
|
||||
|
||||
* Status
|
||||
* Configuration
|
||||
* Logs
|
||||
* Health
|
||||
* Commands
|
||||
* Statistics
|
||||
* Command History
|
||||
|
||||
.png>)
|
||||
|
||||
## Status
|
||||
|
||||
Connection status reflects the Gateway to Device current communications status. Uptime and Last Contact reflect communication state. Load indicates processing load on the device. Memory Used indicates free memory on the device.
|
||||
|
||||
|
||||
|
||||
## Configuration
|
||||
|
||||
Device UUID, Serial Number, MAC Address and Device Type are displayed. Last configuration update date and timestamp reflects the last time a "configure" action completed on the device. Password may be set and device notes may be added.
|
||||
|
||||
|
||||
|
||||
## Logs
|
||||
|
||||
Log history of the device is presented within Logs. Expand the tile selecting the down arrow.
|
||||
|
||||
.png>)
|
||||
|
||||
## Health
|
||||
|
||||
Health score is an active tile reflecting the device health out of a score reported by the device to Gateway. Health metrics are configured on the device based on chosen data model options. When the device falls out of 100%, this tile changes to red. Expanding the tile will present all health reports. Those with less than 100% score will contain reasons for the result from this interface.
|
||||
|
||||
|
||||
|
||||
## Commands
|
||||
|
||||
Commands tile provides a number of administrative actions for the user:
|
||||
|
||||
| Command | Action |
|
||||
| ---------------- | ------------------------------------------------------- |
|
||||
| Reboot | Warm Restart remote device |
|
||||
| Firmware Upgrade | Initiate firmware upgrade process |
|
||||
| WiFi Scan | Initiate remote scan of surrounding Wi-Fi |
|
||||
| Connect | Initiate an rTTY Remote Shell session |
|
||||
| Blink | Set LEDs to On, Off or Blinking state |
|
||||
| Trace | Initiate a remote Packet Capture |
|
||||
| Factory Reset | Hard Reset remote device - destroys device local config |
|
||||
| Configure | Upload Device Configuration |
|
||||
|
||||
|
||||
25
sdk/user-interface/devices-view/command-history.md
Normal file
25
sdk/user-interface/devices-view/command-history.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
description: OpenWiFi SDK 2.0
|
||||
---
|
||||
|
||||
# Command History
|
||||
|
||||
Multiple events are recorded in the Command History tile. Each line item will have a Result, Details, and Delete action.
|
||||
|
||||
|
||||
|
||||
When an rTTY session is executed, this is a displayed command history. Selecting the Result icons will display the Success or Fail of the command.
|
||||
|
||||
|
||||
|
||||
Each provisioning event is reflected as a configure command history. To see the entire JSON payload and the result, including success or error with message, simply select Details to expand the dialog below with this data. A date and time in the third column indicates when the configure command was executed successfully.
|
||||
|
||||
|
||||
|
||||
If a provisioning event has failed to complete, its command history for configure will show as pending.
|
||||
|
||||
|
||||
|
||||
Remote packet capture is shown as the trace command history. When packet captures are persisted in the OpenWiFi SDK, they may be downloaded again through the cloud download icon.
|
||||
|
||||
|
||||
69
sdk/user-interface/devices-view/commands.md
Normal file
69
sdk/user-interface/devices-view/commands.md
Normal file
@@ -0,0 +1,69 @@
|
||||
---
|
||||
description: OpenWiFi 2.0 SDK
|
||||
---
|
||||
|
||||
# Commands
|
||||
|
||||
Within the devices view, the Commands tile offers a number of features and administrative actions. Each of these represent API calls exposed on the OpenAPI northbound interface from the SDK.
|
||||
|
||||
## Reboot
|
||||
|
||||
Selecting the Reboot action will prompt the below dialog. Options presented permit an immediate reboot or a scheduled reboot based on date and time.
|
||||
|
||||
.png>)
|
||||
|
||||
## Firmware Upgrade
|
||||
|
||||
Multiple methods exist to execute a remote Firmware Upgrade of a device. When selecting Firmware Upgrade via the Commands tile, a simple dialog to upgrade immediately or at a scheduled time is presented. Alternatively using the Firmware Management Service provides a complete solution including managed access to all TIP firmware images.
|
||||
|
||||
|
||||
|
||||
## Wi-Fi Scan
|
||||
|
||||
OpenWiFi devices may perform channel scanning and return this neighbor and RF data to the SDK in an on demand or ongoing manner.
|
||||
|
||||
.png>)
|
||||
|
||||
### Wi-Fi Scan Results
|
||||
|
||||
Scan operations function over all channels. If 5GHz channels do not display in the returned results ( either via the UI or over API ) this indicates the device is configured in a DFS channel for which it may not return survey scans at this time.
|
||||
|
||||
.png>)
|
||||
|
||||
## Connect
|
||||
|
||||
OpenWiFi enables remote connection to any managed device using rTTY encrypted shell session. Selecting Connect will cause a browser tab to open with the login session to current device.
|
||||
|
||||
|
||||
|
||||
## Blink
|
||||
|
||||
To assist with remote identification of devices in the network, it is possible to turn the LED lights On, Off, of continuous blinking. This may be run on-demand or scheduled.
|
||||
|
||||
|
||||
|
||||
## Trace
|
||||
|
||||
Trace feature enables a remote packet capture to occur on the managed device, over a specified period of time or amount of traffic, returning the "pcap" packet capture file locally to the OpenWiFi admin user.
|
||||
|
||||
|
||||
|
||||
Once complete the user is asked to open or save the packet capture file locally.
|
||||
|
||||
 (1).png>)
|
||||
|
||||
## Factory Reset
|
||||
|
||||
It is possible to revert a device to initial out of box state from the OpenWiFi SDK. Sending a Factory Reset will remove all configuration on the device and optionally reset the discovered cloud stored as the 'Redirector' in the device configuration.
|
||||
|
||||
.png>)
|
||||
|
||||
{% hint style="info" %}
|
||||
Note: When Redirector is not kept, devices will re-contact the Certificate Authority to re-discover their OpenWiFi cloud address
|
||||
{% endhint %}
|
||||
|
||||
## Configure
|
||||
|
||||
Prior to the introduction of OpenWiFi 2.0 Provisioning Service, device configuration is done through creation of the JSON provisioning file and either loading that file or applying its contents using the dialog presented via Configure. The same options exist when using the API directly.
|
||||
|
||||
.png>)
|
||||
37
sdk/user-interface/devices-view/statistics.md
Normal file
37
sdk/user-interface/devices-view/statistics.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
description: OpenWiFi 2.0 SDK
|
||||
---
|
||||
|
||||
# Statistics
|
||||
|
||||
Each device page presents statistics in traffic terms per interface as a line graph of bandwidth over time.
|
||||
|
||||
|
||||
|
||||
The generated image may be downloaded for offline use.
|
||||
|
||||
|
||||
|
||||
Accessing Wi-Fi Analysis and Last Statistics may be found at the top right of Statistics tile.
|
||||
|
||||
|
||||
|
||||
## Wi-Fi Analysis
|
||||
|
||||
Operating channels, channel width, noise floor and transmit power are the first values reported in Radios table.
|
||||
|
||||
Viewing associations, from the Associations table, and their use is important in terms of bandwidth and connection quality. Wi-Fi Analysis helps visualize each client association, this could be an end user device or a WDS or Mesh association.
|
||||
|
||||
Each association is known by their MAC address or BSSID value. The mode of connection will indicate if an end user client device entering the "ap" or if a client is associated as "wds" or "mesh.
|
||||
|
||||
|
||||
|
||||
The access point view of RSSI, Rx and Tx Rate, Modulation Coding Scheme and Number of Spatial Streams are exposed for each association.
|
||||
|
||||
Using the slider along the top, the last 15 to 30 minutes of performances data may be viewed.
|
||||
|
||||
## Latest Statistics
|
||||
|
||||
The option to view Latest Statistics is at time of the MVP release, intended to help the Community see on a per device basis how much, or how little depending on device configuration, is being sent to the OpenWiFi Gateway in terms of telemetry.
|
||||
|
||||
|
||||
35
sdk/user-interface/firmware.md
Normal file
35
sdk/user-interface/firmware.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
description: OpenWiFi 2.0 SDK
|
||||
---
|
||||
|
||||
# Firmware
|
||||
|
||||
Firmware management service integrates across all OpenWiFi Gateways deployed in a cluster enabling updates to running firmware either from the latest published version, or any other released version.
|
||||
|
||||
## Dashboard
|
||||
|
||||
Firmware dashboard provides a single view for overall health of deployed device firmware. Latest firmware charts, device firmware version distribution, distribution of device by type and current connected devices.
|
||||
|
||||
|
||||
|
||||
## Device Table
|
||||
|
||||
From the Devices table, any device with a newer firmware published by TIP OpenWiFi is indicated with a yellow icon. Selecting this icon presents the option to upgrade to latest or specify which firmware to use.
|
||||
|
||||
|
||||
|
||||
When the upgrade has been sent successfully, a green Success dialog will display in the upper right on the screen. Devices with latest firmware version will show a green firmware icon in the Devices row.
|
||||
|
||||
## Firmware Management Service
|
||||
|
||||
Viewing the contents of Firmware Management Service is available from the left navigation, select Firmware.
|
||||
|
||||
Once in Firmware, it is possible to search by device model for all known firmware revisions.
|
||||
|
||||
|
||||
|
||||
If in the Device Table reference above, instead of selecting Upgrade to Latest, the specific URI location of any available firmware is found using the Firmware table.
|
||||
|
||||
Selecting Details will present information for any firmware row, including the URI which may be copied into the Choose Custom Firmware dialog prompt accordingly.
|
||||
|
||||
|
||||
69
sdk/user-interface/gateway.md
Normal file
69
sdk/user-interface/gateway.md
Normal file
@@ -0,0 +1,69 @@
|
||||
# Gateway
|
||||
|
||||
|
||||
|
||||
The OpenWiFi solution can be applied to a diverse number of use cases from enterprise networks, service provider access, and hotspots. OpenWiFi offers a variety of managed services from small to very large venues of roaming, client shared-key management, client steering, mobile offload, QoS-based services, and Layer 2 and Layer 3 breakout and overlay options. The Provisioning service provides a view into the network as a whole, and venues with entity-based control.
|
||||
|
||||
The provisioning service for OpenWiFi supports weighted order inheritance of configuration templates. These services and networks provide the greatest level of flexibility.
|
||||
|
||||
The system functions from a starting point of managed inventory assigned to entities, venues and optionally end subscribers. From this association, inheritance of entity, venue and subscriber configuration becomes possible where one to many configurations are processed including one to one when an inventory device such as a P2P link or Subscriber Gateway have unique operating data.
|
||||
|
||||
These features are present from the service over the web interface as well as via API for controller integration and OSS/BSS integration purposes.
|
||||
|
||||
Device provisioning is highly configurable and scalable.
|
||||
|
||||
## Inventory
|
||||
|
||||
You can manage device inventory for both assigned and unassigned states. As devices are added to the system, they become available to venues for association and service provisioning.
|
||||
|
||||
Each inventory record, regardless of assignment state can be viewed in the OpenWifi dashboard.
|
||||
|
||||
<img src="../../.gitbook/assets/image13.png" alt="" data-size="original">{width="6.4in" height="3.0in"}Use the SDK UI to assign a device to a venue, review device configurations, update record tags or delete a device.
|
||||
|
||||
|
||||
|
||||
### Bulk Inventory API
|
||||
|
||||
The TIP OpenWiFi inventory service API could be used to bulk load record formats in a common .csv structure using JSON. For example
|
||||
|
||||
\`\`\`
|
||||
|
||||
"SerialNumber",Name,Description,DeviceType,NoteText for example: d1300f7b0732,Manufacturer,Desc, edgecore\_spw2ac1200,OutdoorAP
|
||||
|
||||
\`\`\`
|
||||
|
||||
For each inventory record, the \`\`\`deviceType\`\`\` must match a valid OpenWiFi device type. For example:
|
||||
|
||||
\`\`\`
|
||||
|
||||
"deviceTypes": \[ "cig\_wf160d", "cig\_wf188", "cig\_wf194c", "edgecore\_eap101", "edgecore\_eap102",
|
||||
|
||||
"edgecore\_ecs4100-12ph", "edgecore\_ecw5211",
|
||||
|
||||
> ...]
|
||||
|
||||
\`\`\`
|
||||
|
||||
When inventory is assigned to a venue, it can be allocated into a top-level parent such as the operator. Then, based on role access, operation's teams may choose to assign the device to a child entity within an operating division, or setup the device as a tenant of a managed Wi-Fi service for example.
|
||||
|
||||
Choosing to assign the device to a specific MDU location as an example can be done in one step from above.
|
||||
|
||||
## Creating Entities and Venues
|
||||
|
||||
Devices can be assigned to the MDU—which may be an actual venue such as a building or a tenant operator with child venues.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Provisioning Templates
|
||||
|
||||
Use the Create Configuration window to create a configuration template for a specific venue or device.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
For example, a configuration template for a local area network could include: address translation and local DHCP for on-premises devices, WAN interface with DHCP for IPv4/IPv6 service, and a basic Wi-Fi configuration.
|
||||
6
sdk/user-interface/inventory-association.md
Normal file
6
sdk/user-interface/inventory-association.md
Normal file
@@ -0,0 +1,6 @@
|
||||
# Inventory Association
|
||||
|
||||
Within a Venue, devices inherit the sum of Configurations present in the Venue, and Entity structure holding the Venue matching their device type. 
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user