scottk/wlan-docs
1
0
Fork 0
mirror of https://github.com/Telecominfraproject/wlan-docs.git synced 2025-11-02 19:57:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

GitBook: [2.1.0] 46 pages and 5 assets modified

Browse Source
This commit is contained in:
Chris Busch
2021-08-10 13:47:36 +00:00
committed by gitbook-bot
parent a178373fca
commit 7028223f6d
48 changed files with 1459 additions and 1504 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
.gitbook/assets/image (22) (1).png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 125 KiB

0
.gitbook/assets/image (33).png → .gitbook/assets/image (34) (1).png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 101 KiB

After

Width:  |  Height:  |  Size: 101 KiB

0
.gitbook/assets/image (32).png → .gitbook/assets/image (36) (1).png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 147 KiB

After

Width:  |  Height:  |  Size: 147 KiB

4
README.md
View File

@@ -2,7 +2,7 @@
description: Telecom Infra Project OpenWiFi
---
# OpenWiFi Release 2.0
# OpenWiFi Release 2.1
## What is OpenWiFi?
@@ -12,7 +12,7 @@ TIP OpenWiFi is an open source community project that believes in democratizing
TIP OpenWiFi is the industry's first CI/CD open source Wi-Fi eco-system. Built nightly with a strong community of Wi-Fi leaders, new features are unit tested in automated RF chambers and checked from cloud to ground for Wi-Fi performance and conformance.
OpenWiFi 2.0 introduces management and telemetry based on uCentral offering expanded selection of managed devices including smaller APs and PoE access switches.
OpenWiFi 2.0 introduces management and telemetry based on uCentral offering expanded selection of managed devices including smaller APs and PoE access switches.
### High Level Features

2
SUMMARY.md
View File

@@ -1,6 +1,6 @@
# Table of contents
* [OpenWiFi Release 2.0](README.md)
* [OpenWiFi Release 2.1](README.md)
* [Ordering OpenWiFi APs](ordering-open-wi-fi-aps.md)
* [Getting Started](getting-started/README.md)
* [Cloud Discovery](getting-started/cloud-discovery/README.md)

30
api/README.md
View File

@@ -4,49 +4,49 @@ description: OpenWiFi 2.0 SDK
# API
OpenWiFi services follow the OpenAPI 3.0 definition.
OpenWiFi services follow the OpenAPI 3.0 definition.
The complete API is described here: [OpenWiFi SDK OpenAPI](https://github.com/Telecominfraproject/wlan-cloud-ucentralgw/blob/master/openapi/ucentral/ucentral.yaml)
### Devices
## Devices
OpenWiFi devices are Access Points or Switches \(and other forms in the future\), that support the uCentral configuration schema. Devices contact a controller using the uCentral protocol.
### Communication
## Communication
The communication between the controller and the devices use the uCentral protocol. This protocol is defined in this [document](https://github.com/Telecominfraproject/wlan-cloud-ucentralgw/blob/main/PROTOCOL.md).
### Device Configuration
## Device Configuration
A device is configured by ingesting a uCentral configuration. That configuration will be provided by the SDK Gateway as a result of a command through the API. Command processing occurs when the device's configuration is older than what is known in the SDK Gateway. The uCentral schema is a JSON document containing parameters to set on a particular device.
### SDK Gateway Communication
## SDK Gateway Communication
In order to speak to the Gateway, you must implement a client that uses the OpenAPI definition for the gateway. You can find its [definition here](https://github.com/Telecominfraproject/wlan-cloud-ucentralgw/blob/main/openapi/ucentral/ucentral.yaml). You cannot talk to a device directly.
### API Basics
## API Basics
#### Device `serialNumber`
### Device `serialNumber`
Throughout the API, the `serialNumber` of the device is used as the key. The `serialNumber` is actual the MAC address of the device, without its `:`. The `serialNumber` is guaranteed to be unique worldwide. The device uses its serial number to identify itself to the controller.
#### Device Configuration
### Device Configuration
The configuration can be supplied when the device is created. After the device is created, the only way to modify the configuration is by using the `/device/{serialNumber}/configure` endpoint. The Gateway maintains the versioning of the configuration through the use of a `uuid`. The Gateway maintains that number and will ignore anything your supply. The controller also does minimum validation on the configuration: it must be a valid JSON document and must have a `uuid` field which will be ignored.
#### Device Capabilities
### Device Capabilities
Device capabilities are uploaded to the Gateway when the device performs its initial connection. Capabilities tell the Gateway what the device is able to support. The Gateway uses this information to provide a configuration matched to the device type.
#### Command Queue
### Command Queue
The Gateway will send commands to the devices. These commands are kept in a table and are sent at the appropriate time or immediately when the device connects.
The Gateway will send commands to the devices. These commands are kept in a table and are sent at the appropriate time or immediately when the device connects.
For example, you could ask a device to change its configuration, however it might be unreachable. Upon next device connection, this configure command will be sent. The list of commands is retrieved using the `/commands` endpoint.
#### Commands
### Commands
Several commands maybe sent to a device: reboot, configure, factory reset, firmware upgrade, LEDs, trace, message request, etc. The API endpoint `/device/{serialNumber}/{command}` details all the available commands.
#### Device Specific Collections
### Device Specific Collections
For each device, a number of collections are collected and kept in the database. Here's a brief list:
@@ -55,7 +55,7 @@ For each device, a number of collections are collected and kept in the database.
* `healthchecks`: periodically, a device will run a self-test and report its results. These includes anything that maybe going wrong with the current device configuration. A `sanity` level is associated to the degree of health of the device. 100 meaning a properly operating device.
* `status`: tells you where the device is and how much data is used for protocol communication.
### The API is for an operator
## The API is for an operator
This API is meant for an operator who would have to help a subscriber in configuring devices, reboot, manage firmware, etc.
This API is meant for an operator who would have to help a subscriber in configuring devices, reboot, manage firmware, etc.

26
api/openapi-definitions.md
View File

@@ -4,30 +4,30 @@ description: OpenWiFi 2.0 SDK
# OpenAPI Definitions
### Where is the OpenAPI?
## Where is the OpenAPI?
This uses OpenAPI definition 3.0 and can be found [here](https://github.com/Telecominfraproject/wlan-cloud-ucentralgw/blob/main/openapi/ucentral/ucentral.yaml). All endpoints begin with `/api/v1`.
### API Flow
## API Flow
API endpoints are secured with bearer-token authentication using end-point `/oauth2`.
API endpoints are secured with bearer-token authentication using end-point `/oauth2`.
Once you obtain `access-token`, you will need to pass it in the headers under `Authorization: Bearer <place your token here>`.
### Basic Entities
## Basic Entities
The API revolves around `devices`, `commands`, and `default_configurations`.
To retrieve a list of `devices` to know what is available and then use the endpoint `device` to access all device specific information.
To retrieve `commands` and `default_configurations` follow those endpoints.
To retrieve a list of `devices` to know what is available and then use the endpoint `device` to access all device specific information.
To retrieve `commands` and `default_configurations` follow those endpoints.
Most operations rely on the `serialNumber` of a device. That `serialNumber` is unique and generated on the device. Serial Number matches the device's MAC address.
* `devices`: The list of all devices in the system. This maybe very large, pagination is recommended.
* `commands`: The list of commands issued by the system. This list could also be large.
* `default_configurations`: A list of default configurations used to supply existing devices.
### Relationships
## Relationships
A device is a physical \(or potentially logical\) entity using the ucentral protocol.
Currently, APs and Switches are the only devices used. A device has several attributes.
A device is a physical \(or potentially logical\) entity using the ucentral protocol.
Currently, APs and Switches are the only devices used. A device has several attributes.
Additionally, other collections are supported for each device:
* `logs`: Specific for a device. Logs originate from the device or associated with the device by some mechanism.
@@ -35,7 +35,7 @@ Additionally, other collections are supported for each device:
* `statistics`: Periodically produced by the devices and document actual state data from each device.
* `capabilities`: This details the actual data model supported by the device.
The `device` entry point is also used to query about the `status` of the device and used to inject certain commands for a specific device.
The `device` entry point is also used to query about the `status` of the device and used to inject certain commands for a specific device.
Commands supported for each device:
* `reboot`: This will force the device to reboot.
@@ -49,7 +49,7 @@ Commands supported for each device:
The `file` end point is used to retrieve and remove files produced by the Gateway. Currently this is limited to the results of a `trace` command. The file name will always match the `uuid` of the command that produced it. If several files are needed, the files will be named `uuid`, `uuid.1`, `uuid.2`, etc.
### Dates
## Dates
All dates should use the format defined in [RFC3339](https://tools.ietf.org/html/rfc3339). All times are UTC based. Here is an example:
@@ -57,11 +57,11 @@ All dates should use the format defined in [RFC3339](https://tools.ietf.org/html
1985-04-12T23:20:50.52Z
```
### Command `when` parameter
## Command `when` parameter
Most commands use a `when` parameter to suggest to the device when to perform the command. This is a _suggestion_ only. The device may decide to perform the command when it is optimal for itself. It maybe busy doing something and decline to do a reboot for several minutes for example. The device may reply with the actual `when` it will perform the command.
### Configuration UUID
## Configuration UUID
The gateway manages the configuration UUID. So if you set a UUID for a configuration, it will be ignored. The gateway uses UUID as versioning. The UUID is unique within a single device. The resulting UUID or a configuration change is returned as part of the `configure` command.

6
configuration-examples/basic-device-provisioning/README.md
View File

@@ -6,9 +6,9 @@ description: OpenWiFi 2.0
One of the benefits of the new data plane in OpenWiFi 2.0 is the flexibility of physical port to logical forwarding that is easily conveyed through configuration structures.
New protocol support is both easily added to the system as well as associated with interfaces by their role in the device.
New protocol support is both easily added to the system as well as associated with interfaces by their role in the device.
The following sections offer feature configuration examples.
The following sections offer feature configuration examples.
For complete reference to the device data model please refer [here.](../../provisioning/data-model-introduction.md)
For complete reference to the device data model please refer [here.](../../provisioning/data-model-introduction.md)

236
configuration-examples/basic-device-provisioning/bridge-mode-ssid.md
View File

@@ -4,141 +4,141 @@ description: OpenWiFi 2.0
# Bridge Mode SSID
Creating logical bridges may be done through association to named "interfaces".
To associate a logical SSID interface directly to the WAN, place SSID configuration within the interface have a "role" of upstream.
Creating logical bridges may be done through association to named "interfaces".
To associate a logical SSID interface directly to the WAN, place SSID configuration within the interface have a "role" of upstream.
{% tabs %}
{% tab title="SSID to WAN" %}
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "OpenWifi",
"wifi-bands": [
"2G", "5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
}
]
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "OpenWifi",
"wifi-bands": [
"2G", "5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
}
]
```
{% endtab %}
{% tab title="Dual SSID to WAN" %}
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "OpenWifi_2GHz",
"wifi-bands": [
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "OpenWifi_2GHz",
"wifi-bands": [
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
},
{
"name": "OpenWifi_5GHz",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
}
]
"name": "OpenWifi_5GHz",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
}
]
```
{% endtab %}
{% tab title="Dual SSID Bridge Rate-Limit to WAN" %}
```
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "OpenWifi_2GHz",
"wifi-bands": [
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
},
"rate-limit": {
"ingress-rate": 100,
"egress-rate": 100
}
},
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"name": "OpenWifi_5GHz",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
},
"rate-limit": {
"ingress-rate": 250,
"egress-rate": 250
}
}
]
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "OpenWifi_2GHz",
"wifi-bands": [
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
},
"rate-limit": {
"ingress-rate": 100,
"egress-rate": 100
}
},
{
"name": "OpenWifi_5GHz",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
},
"rate-limit": {
"ingress-rate": 250,
"egress-rate": 250
}
}
]
```
{% endtab %}
{% endtabs %}

176
configuration-examples/basic-device-provisioning/multi-vlan-ssid.md
View File

@@ -4,26 +4,26 @@ description: OpenWiFi 2.0
# Multi-VLAN SSID
The most common use case for VLANs and Wi-Fi is likely the service provider, venue, enterprise where Wi-Fi traffic is not subject to address translation. This is the example that will be shown, however it is entirely possible to create multiple downstream VLANs with SSIDs as well. Simply replace the logic of upstream to downstream where desired.
The most common use case for VLANs and Wi-Fi is likely the service provider, venue, enterprise where Wi-Fi traffic is not subject to address translation. This is the example that will be shown, however it is entirely possible to create multiple downstream VLANs with SSIDs as well. Simply replace the logic of upstream to downstream where desired.
{% tabs %}
{% tab title="Single SSID VLAN" %}
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp", "dhcp-snooping" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp", "dhcp-snooping" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
},
{
"name": "WAN100",
@@ -38,41 +38,41 @@ The most common use case for VLANs and Wi-Fi is likely the service provider, ven
]
}
],
"ssids": [
{
"name": "VLAN 100 Wi-Fi",
"wifi-bands": [
"2G", "5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
"ssids": [
{
"name": "VLAN 100 Wi-Fi",
"wifi-bands": [
"2G", "5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
}
]
},
]
},
```
{% endtab %}
{% tab title="Dual SSID - Dual VLAN" %}
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp", "dhcp-snooping" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp", "dhcp-snooping" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
},
{
"name": "WAN100",
@@ -87,53 +87,53 @@ The most common use case for VLANs and Wi-Fi is likely the service provider, ven
]
}
],
"ssids": [
{
"name": "VLAN 100 Wi-Fi",
"wifi-bands": [
"2G", "5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
"ssids": [
{
"name": "VLAN 100 Wi-Fi",
"wifi-bands": [
"2G", "5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
}
]
},
{
"name": "WAN200",
"role": "upstream",
"vlan": {
"id": 200
},
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ssids": [
{
"name": "VLAN 200 Wi-Fi",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
}
]
},
]
},
{
"name": "WAN200",
"role": "upstream",
"vlan": {
"id": 200
},
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ssids": [
{
"name": "VLAN 200 Wi-Fi",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
}
]
},
```
{% endtab %}
{% endtabs %}
In all cases the WAN port without VLAN id is using DHCP to obtain a management IP address.
In all cases the WAN port without VLAN id is using DHCP to obtain a management IP address.
Each additional "upstream" role interface with an SSID associated have no IP configuration.

128
configuration-examples/basic-device-provisioning/nat-gateway-mode-ssid.md
View File

@@ -9,77 +9,77 @@ Creating a NAT Gateway is easily done via association to an interface having a r
{% tabs %}
{% tab title="Dual SSID NAT" %}
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
},
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh", "lldp" ],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
"ipv4": {
"addressing": "static",
"subnet": "192.168.1.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
},
"ssids": [
{
"name": "OpenWifi_2GHz",
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh", "lldp" ],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
"ipv4": {
"addressing": "static",
"subnet": "192.168.1.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
},
"ssids": [
{
"name": "OpenWifi_2GHz",
"role": "downstream",
"wifi-bands": [
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
},
{
"name": "OpenWifi_5GHz",
"wifi-bands": [
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
},
{
"name": "OpenWifi_5GHz",
"role": "downstream",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
}
]
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
}
}
]
}
}
```
{% endtab %}
{% endtabs %}
Based on the above Dual SSID NAT configuration, a unique 2GHz and 5GHz SSID are created and logically bound to the same NAT LAN side network.
Based on the above Dual SSID NAT configuration, a unique 2GHz and 5GHz SSID are created and logically bound to the same NAT LAN side network.
The NAT service is inherited by the downstream role with DHCP addressing defined according to the range set within the downstream "ipv4" configuration.
The NAT service is inherited by the downstream role with DHCP addressing defined according to the range set within the downstream "ipv4" configuration.

86
configuration-examples/captive-portal.md
View File

@@ -4,54 +4,54 @@ description: OpenWiFi 2.0
# Captive Portal
OpenWiFi supports multiple models for Captive Portal. A built-in captive portal is described below. With multiple overlay tunnel services such as GRE and L2TP in addition to VLAN features, OpenWiFi is also easily deployed with any number of Captive Portal appliance solutions in either in-band or out-of-band style deployments.
OpenWiFi supports multiple models for Captive Portal. A built-in captive portal is described below. With multiple overlay tunnel services such as GRE and L2TP in addition to VLAN features, OpenWiFi is also easily deployed with any number of Captive Portal appliance solutions in either in-band or out-of-band style deployments.
### Local Captive Portal
## Local Captive Portal
Creating a local captive portal involves associating the "captive" service with an interface. In the example below, "captive" is enabled on a downstream role interface. Any associated SSID on LAN side of this Access Point will be subject to configuration of the local captive portal. This would also apply to LAN interfaces if also associated with "captive".
```text
{
"name": "captive",
"role": "downstream",
"captive": {
"max-clients": 32,
"gateway-name": "Lobby Wi-Fi Welcome",
"upload-rate": 10,
"download-rate": 20,
"upload-quota": 300,
"download-quota": 300
},
"ipv4": {
"addressing": "static",
"subnet": "192.168.2.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
},
"ssids": [
{
"name": "Office Lobby Wi-Fi",
"wifi-bands": [
"5G",
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "none",
"ieee80211w": "optional"
},
"roaming": {
"message-exchange": "ds",
"generate-psk": true
}
}
]
}
],
{
"name": "captive",
"role": "downstream",
"captive": {
"max-clients": 32,
"gateway-name": "Lobby Wi-Fi Welcome",
"upload-rate": 10,
"download-rate": 20,
"upload-quota": 300,
"download-quota": 300
},
"ipv4": {
"addressing": "static",
"subnet": "192.168.2.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
},
"ssids": [
{
"name": "Office Lobby Wi-Fi",
"wifi-bands": [
"5G",
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "none",
"ieee80211w": "optional"
},
"roaming": {
"message-exchange": "ds",
"generate-psk": true
}
}
]
}
],
```
Local captive portal will redirect to a default landing page and display the name as configured in "gateway-name". Per associated user bandwidth and usage quota limits and total association limits may all be defined.
Local captive portal will redirect to a default landing page and display the name as configured in "gateway-name". Per associated user bandwidth and usage quota limits and total association limits may all be defined.

120
configuration-examples/expresswifi.md
View File

@@ -12,73 +12,73 @@ For information about becoming an expressWIFI partner please visit their [site.]
![](../.gitbook/assets/image%20%2840%29.png)
### Configuration
## Configuration
ExpressWiFi builds a captive portal experience using a control plane protocol called OpenFlow.
Configuring OpenWiFi for use with expressWiFi is as simple as defining a downstream interface and associating with an SSID and the open-flow service.
ExpressWiFi builds a captive portal experience using a control plane protocol called OpenFlow.
Configuring OpenWiFi for use with expressWiFi is as simple as defining a downstream interface and associating with an SSID and the open-flow service.
{% tabs %}
{% tab title="expressWIFI" %}
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
},
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh", "lldp", "open-flow"],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
"ipv4": {
"addressing": "static",
"subnet": "192.168.1.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh", "lldp", "open-flow"],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
"ipv4": {
"addressing": "static",
"subnet": "192.168.1.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
},
"ssids": [
{
"name": "ExpressWiFi",
"wifi-bands": [
"5G", "2G"
],
"bss-mode": "ap"
}
]
}
],
"services": {
"lldp": {
"describe": "OpenWiFi - expressWiFi",
"location": "Hotspot"
},
"ssh": {
"port": 22
},
"open-flow": {
"controller": " IP / FQDN of expressWiFi Controller "
}
}
"ssids": [
{
"name": "ExpressWiFi",
"wifi-bands": [
"5G", "2G"
],
"bss-mode": "ap"
}
]
}
],
"services": {
"lldp": {
"describe": "OpenWiFi - expressWiFi",
"location": "Hotspot"
},
"ssh": {
"port": 22
},
"open-flow": {
"controller": " IP / FQDN of expressWiFi Controller "
}
}
```
{% endtab %}
{% endtabs %}

98
configuration-examples/gre.md
View File

@@ -4,60 +4,60 @@ description: OpenWiFi 2.0
# GRE
OpenWiFi 2.0 supports Generic Routing Encapsulation as an available "tunnel" protocol type.
OpenWiFi 2.0 supports Generic Routing Encapsulation as an available "tunnel" protocol type.
This makes it possible to configure GRE for multiple types of deployments as any interface may be encapsulated by the "tunnel" parameter.
This makes it possible to configure GRE for multiple types of deployments as any interface may be encapsulated by the "tunnel" parameter.
For example, to send all content of a specific SSID over an GRE tunnel, the following configuration would apply.
For example, to send all content of a specific SSID over an GRE tunnel, the following configuration would apply.
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
},
{
"name": "GRE",
"role": "upstream",
"vlan": {
"id": 20
},
"tunnel": {
"proto": "gre",
"peer-address": "far end IP address"
},
"ssids": [
{
"name": "Tunneled SSID via GRE from VLAN 20 Interface",
"wifi-bands": [
"2G", "5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "none",
"ieee80211w": "optional"
},
"rate-limit": {
"ingress-rate": 100,
"egress-rate": 100
},
"roaming": {
"message-exchange": "ds",
"generate-psk": true
}
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
]
},
],
"ipv4": {
"addressing": "dynamic"
}
},
{
"name": "GRE",
"role": "upstream",
"vlan": {
"id": 20
},
"tunnel": {
"proto": "gre",
"peer-address": "far end IP address"
},
"ssids": [
{
"name": "Tunneled SSID via GRE from VLAN 20 Interface",
"wifi-bands": [
"2G", "5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "none",
"ieee80211w": "optional"
},
"rate-limit": {
"ingress-rate": 100,
"egress-rate": 100
},
"roaming": {
"message-exchange": "ds",
"generate-psk": true
}
}
]
},
```
In the above example, the WAN untagged port will request DHCP in addition to present a VLAN interface with id 20 that both initiates the GRE tunnel as well as passes SSID traffic over that tunnel.

107
configuration-examples/l2tp.md
View File

@@ -4,63 +4,62 @@ description: OpenWiFi 2.0
# L2TP
Layer 2 Tunneling Protocol may be associated to any interface using the "tunnel" configuration option.
Layer 2 Tunneling Protocol may be associated to any interface using the "tunnel" configuration option.
This makes it possible to configure L2TP for multiple types of deployments as any interface may be encapsulated by the "tunnel" parameter.
This makes it possible to configure L2TP for multiple types of deployments as any interface may be encapsulated by the "tunnel" parameter.
For example, to send all content of a specific SSID over an L2TP tunnel, the following configuration would apply.
For example, to send all content of a specific SSID over an L2TP tunnel, the following configuration would apply.
```text
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh" ],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
"ipv4": {
"addressing": "static",
"subnet": "192.168.1.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
}
},
{
"name": "L2TP",
"role": "downstream",
"tunnel": {
"proto": "l2tp",
"server": " far end IP address ",
"user-name": "secret-l2tp-username",
"password": "secrectPassword"
},
"ipv4": {
"addressing": "static",
"subnet": "192.168.10.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
},
"ssids": [
{
"name": "Tunneled SSID",
"wifi-bands": [
"5G", "2G"
],
"bss-mode": "ap"
}
]
}
],
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh" ],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
"ipv4": {
"addressing": "static",
"subnet": "192.168.1.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
}
},
{
"name": "L2TP",
"role": "downstream",
"tunnel": {
"proto": "l2tp",
"server": " far end IP address ",
"user-name": "secret-l2tp-username",
"password": "secrectPassword"
},
"ipv4": {
"addressing": "static",
"subnet": "192.168.10.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
},
"ssids": [
{
"name": "Tunneled SSID",
"wifi-bands": [
"5G", "2G"
],
"bss-mode": "ap"
}
]
}
],
```

114
configuration-examples/mesh.md
View File

@@ -4,7 +4,7 @@ description: OpenWiFi 2.0
# Mesh
OpenWiFi Mesh has been designed to eliminate configuration complexity while also remaining capable of advanced topology designs including Multi-Gateway, Multi-SSID, VLAN, and Zero Touch Mesh onboarding.
OpenWiFi Mesh has been designed to eliminate configuration complexity while also remaining capable of advanced topology designs including Multi-Gateway, Multi-SSID, VLAN, and Zero Touch Mesh onboarding.
The physical wired interface\(s\) to participate in the mesh topology egress are defined with the protocol "mesh".
@@ -13,69 +13,69 @@ The logical wireless interface\(s\) to participate in mesh topology are defined
{% tabs %}
{% tab title="Basic Mesh" %}
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"tunnel": {
"proto": "mesh"
},
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "transit",
"wifi-bands": [
"5G"
],
"bss-mode": "mesh",
"encryption": {
"proto": "psk2",
"key": "meshpassword",
"ieee80211w": "optional"
}
},
"proto": "mesh"
},
"services": [ "lldp" ],
"ethernet": [
{
"name": "2GHz Clients",
"wifi-bands": [
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "transit",
"wifi-bands": [
"5G"
],
"bss-mode": "mesh",
"encryption": {
"proto": "psk2",
"key": "meshpassword",
"ieee80211w": "optional"
}
},
{
"name": "2GHz Clients",
"wifi-bands": [
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWiFi",
"ieee80211w": "optional"
}
},
{
"name": "5GHz Clients",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWiFi",
"ieee80211w": "optional"
}
"ieee80211w": "optional"
}
},
{
"name": "5GHz Clients",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWiFi",
"ieee80211w": "optional"
}
}
]
},
}
]
},
```
{% endtab %}
{% endtabs %}
In this basic mesh, dual SSIDs are configured for clients while an SSID for mesh transit is configured for IEEE802.11s client associations. Additional mesh clients simply use the same approach, no other configuration is required for the client to participate in this mesh.
In this basic mesh, dual SSIDs are configured for clients while an SSID for mesh transit is configured for IEEE802.11s client associations. Additional mesh clients simply use the same approach, no other configuration is required for the client to participate in this mesh.
Advanced examples with VLANs and roaming are all possible by adding additional configuration steps.
Advanced examples with VLANs and roaming are all possible by adding additional configuration steps.

112
configuration-examples/metrics.md
View File

@@ -4,72 +4,72 @@ description: OpenWiFi 2.0
# Metrics
### Metrics
## Metrics
Several metrics are reported during intervals to the OpenWiFi Gateway. In general metrics contain traffic counters, neighbor tables, discovered clients.
Several metrics are reported during intervals to the OpenWiFi Gateway. In general metrics contain traffic counters, neighbor tables, discovered clients.
Each OpenWiFi device is capable of sending statistics on SSID, LLDP, and associated Clients learned by the device.
Each OpenWiFi device is capable of sending statistics on SSID, LLDP, and associated Clients learned by the device.
Additionally, OpenWiFi devices expose all 802.11 management data within wifi-frames and to assist network troubleshooting and client fingerprinting solutions OpenWiFi provides dhcp-snooping for all possible client exchanges over DHCP and DHCPv6.
Additionally, OpenWiFi devices expose all 802.11 management data within wifi-frames and to assist network troubleshooting and client fingerprinting solutions OpenWiFi provides dhcp-snooping for all possible client exchanges over DHCP and DHCPv6.
```text
"metrics": {
"statistics": {
"interval": 60,
"types": [ "ssids", "lldp", "clients" ]
},
"health": {
"interval": 300
},
"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" ]
}
"metrics": {
"statistics": {
"interval": 60,
"types": [ "ssids", "lldp", "clients" ]
},
"health": {
"interval": 300
},
"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" ]
}
```
The metrics data is sent to OpenWiFi Gateway at the intervals set where configurable.
The metrics data is sent to OpenWiFi Gateway at the intervals set where configurable.
Metrics must be associated with the interfaces they are to report on. For example, to send DHCP data from LAN to OpenWiFi Gateway, the following configuration would apply.
```text
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh", "lldp", "dhcp-snooping" ],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
"ipv4": {
"addressing": "static",
"subnet": "192.168.1.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
}
}
],
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh", "lldp", "dhcp-snooping" ],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
"ipv4": {
"addressing": "static",
"subnet": "192.168.1.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
}
}
],
```

58
configuration-examples/multi-psk-mdu-multiple-shared-key.md
View File

@@ -4,38 +4,38 @@ description: OpenWiFi 2.0
# Multi-PSK \(MDU Shared Key\)
Multiple Pre Shared Key is a popular configuration option in Multi Dwelling Unit, dormitory or similar environment where it is costly to implement complex 802.1x security however that same level of per-client security is highly desired.
Multiple Pre Shared Key is a popular configuration option in Multi Dwelling Unit, dormitory or similar environment where it is costly to implement complex 802.1x security however that same level of per-client security is highly desired.
A SSID when configured for multi-psk can have multiple PSK/VID mappings. Each one of them can be bound to a specific MAC or be a wildcard.
```text
"ssids": [
{
"name": "MDU Wi-Fi",
"wifi-bands": [
"5G",
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"ieee80211w": "optional",
"key": "OpenWifi"
},
"multi-psk": [
{
"key": "akey",
"vlan-id": 100
},
{
"key": "bkey"
}
],
"roaming": {
"message-exchange": "ds",
"generate-psk": true
}
}
]
"ssids": [
{
"name": "MDU Wi-Fi",
"wifi-bands": [
"5G",
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"ieee80211w": "optional",
"key": "OpenWifi"
},
"multi-psk": [
{
"key": "akey",
"vlan-id": 100
},
{
"key": "bkey"
}
],
"roaming": {
"message-exchange": "ds",
"generate-psk": true
}
}
]
```

2
configuration-examples/p4.md
View File

@@ -4,5 +4,5 @@ description: OpenWiFi 2.0
# P4
Content coming soon...
Content coming soon...

2
configuration-examples/passpoint-r1/README.md
View File

@@ -4,7 +4,7 @@ description: OpenWiFi 2.0
# Passpoint®
Passpoint® brings seamless, automatic and secure Wi-Fi connectivity using either pre-provisioned credentials or the SIM card in a mobile device. Passpoint provides simple, fast online sign-up and provisioning that is only required upon a user’s first visit to a Passpoint network. Once a Passpoint enabled device contains the Wi-Fi AP or network credentials, it will discover and securely connect when the user is nearby—without requiring additional user action. This makes staying connected while mobile infinitely easier, and because Passpoint employs enterprise-level security, users can feel confident their data is better protected.
Passpoint® brings seamless, automatic and secure Wi-Fi connectivity using either pre-provisioned credentials or the SIM card in a mobile device. Passpoint provides simple, fast online sign-up and provisioning that is only required upon a user’s first visit to a Passpoint network. Once a Passpoint enabled device contains the Wi-Fi AP or network credentials, it will discover and securely connect when the user is nearby—without requiring additional user action. This makes staying connected while mobile infinitely easier, and because Passpoint employs enterprise-level security, users can feel confident their data is better protected.
Passpoint® also delivers more value to carriers, service providers, and IT managers of enterprise networks, enabling:

12
configuration-examples/passpoint-r1/advertising-services.md
View File

@@ -4,17 +4,17 @@ description: OpenWiFi 2.0
# Advertising Services
Passpoint® requires ANQP to supply three information elements from the Access Point.
Passpoint® requires ANQP to supply three information elements from the Access Point.
#### PLMN-Id
## PLMN-Id
Public Land Mobile Network Id is defined by 3GPP and comprised of two, three digit numbers to uniquely identify the Mobile Network Operator \(MNO\).
#### Realm
## Realm
A Fully Qualified Domain Name \(FQDN\) is a realm representing the service provider of the Wi-Fi service. Non MNO operators are an example of 'realm-based' service advertisements. Examples include Cable MSOs, Enterprises or other on MNO providers. Authentication methods used with realm-based configuration are EAP-TLS and EAP-TTLS.
A Fully Qualified Domain Name \(FQDN\) is a realm representing the service provider of the Wi-Fi service. Non MNO operators are an example of 'realm-based' service advertisements. Examples include Cable MSOs, Enterprises or other on MNO providers. Authentication methods used with realm-based configuration are EAP-TLS and EAP-TTLS.
#### OI / RCOI
## OI / RCOI
Organization Id or as defined by Wireless Broadband Alliance, Roaming Consortium Organization Id indicate the federated identity capable of authentication. Examples would be OpenRoaming, Eduroam and follow the Passpoint® EAP authentication methods.
Organization Id or as defined by Wireless Broadband Alliance, Roaming Consortium Organization Id indicate the federated identity capable of authentication. Examples would be OpenRoaming, Eduroam and follow the Passpoint® EAP authentication methods.

9
configuration-examples/passpoint-r1/configuration-introduction.md
View File

@@ -4,11 +4,11 @@ description: OpenWiFi 2.0
# Configuration Introduction
TIP OpenWiFi devices implement support for both the air interface and systems interfaces necessary to support Passpoint® Release 2 and above. Once also termed Hotspot 2.0, IEEE 802.11u specified added air interface fields exposing Access Network Query Protocol interactions for clients to discovery Access Point capabilities.
TIP OpenWiFi devices implement support for both the air interface and systems interfaces necessary to support Passpoint® Release 2 and above. Once also termed Hotspot 2.0, IEEE 802.11u specified added air interface fields exposing Access Network Query Protocol interactions for clients to discovery Access Point capabilities.
Wi-Fi Alliance expanded ANQP to include Online Signup \(OSU\) concepts to leverage seamless onboarding and client security for Passpoint® networks. Following on from these efforts, Wireless Broadband Alliance has provided the necessary system interfaces for identity, security, mobile offload within a common federated operator solution known as OpenRoaming.
Wi-Fi Alliance expanded ANQP to include Online Signup \(OSU\) concepts to leverage seamless onboarding and client security for Passpoint® networks. Following on from these efforts, Wireless Broadband Alliance has provided the necessary system interfaces for identity, security, mobile offload within a common federated operator solution known as OpenRoaming.
TIP OpenWiFi enables operators to deploy the full range of Passpoint® and OpenRoaming solutions.
TIP OpenWiFi enables operators to deploy the full range of Passpoint® and OpenRoaming solutions.
<table>
<thead>
@@ -80,7 +80,6 @@ TIP OpenWiFi enables operators to deploy the full range of Passpoint® and OpenR
<td style="text-align:left">OSU</td>
<td style="text-align:left">
<p>Online Signup - Advertised over ANQP contains:</p>
<p></p>
<ul>
<li>OSU SSID</li>
<li>OSU URI</li>
@@ -98,5 +97,3 @@ TIP OpenWiFi enables operators to deploy the full range of Passpoint® and OpenR
</tbody>
</table>

204
configuration-examples/passpoint-r1/passpoint-r-configuration.md
View File

@@ -4,7 +4,7 @@ description: OpenWiFi 2.0
# Passpoint® Configuration
Ahead of the Provisioning service coming in release 2.1 sprint, it is possible to configure all Passpoint attributes as OpenWiFi has tested in prior OpenWiFi releases.
Ahead of the Provisioning service coming in release 2.1 sprint, it is possible to configure all Passpoint attributes as OpenWiFi has tested in prior OpenWiFi releases.
Capabilities for Hotspot 2.0 / Passpoint® include:
@@ -21,108 +21,106 @@ Capabilities for Hotspot 2.0 / Passpoint® include:
* firendly-name
* icons
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "OpenRoaming",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "wpa-mixed",
"ieee80211w": "optional"
},
"radius": {
"nas-identifier": "TIPLABAP101",
"chargeable-user-id": true,
"authentication": {
"host": "IP Address of RADIUS",
"port": 11812,
"secret": "passphrase",
"request-attribute": [
{
"id": 126,
"value": "s:TIP"
}
]
},
"accounting": {
"host": "IP Address of RADIUS",
"port": 11813,
"secret": "passphrase",
"request-attribute": [
{
"id": 126,
"value": "s:TIP"
}
],
"interval": 600
}
},
"pass-point": {
"venue-name": [
"eng:Example passpoint_venue",
"fra:Exemple de lieu"
],
"venue-group": 2,
"venue-type": 8,
"venue-url": [
"http://www.example.com/info-fra",
"http://www.example.com/info-eng"
],
"auth-type": {
"type": "terms-and-conditions"
},
"domain-name": "onboard.example.com",
"nai-realm": [
"0,oss.example.com,21[5:7][2:4]"
],
"osen": false,
"anqp-domain": 1234,
"anqp-3gpp-cell-net": [
"310,260",
"310,410"
],
"friendly-name": [
"eng:TIPLabs",
"fra:TIPLabs"
],
"icons": [
{
"icon": "iVBORw0KGgoAAAANSUhEUgAAACIAAAAiCAYAAAA6RwvCAAAACXBIWXMAAAsSAAALEgHS3X78AAAEDklEQVRYhc1YTUgUcRR/q7uGUzsuYSClNRcbymS3wII6KNF0Cly7dHSNioIiD3Ppg9IOETHQB50S2vUqhBt1qBZ0pWuQG3VYJJ1SI8h0d4qRsnbjrW+Xv+N87VbYg2H/M/P/v/d732/W499+KA9rTFo64fECLSqBoitCBwDEAGCbxZYxAOjjZDVpxYMXpYIhqiq1BYEYtQGB1I57dEWIOPErG4iuCAKBuM08TgFAFyerHrxwDQCPmPdROmNJ3jIAoFZ9JhZAEB2crGaKDzhZjQNAnM5E6TGetQTjyiK6IsSIoZkbwiwIljhZxXOD9KgdrWklw9EiuiKEAaCbbrMUnKhxCAAynKyqDixuM+cRiOl+UyCEvI+EBRkQ6IJxurfMBJZwv66UDBHRFWHczIKrXEN+nSItgsyrGAOiRLwoPedF6YoVEIM7kGdSV4SQLRCK7KhhT4rqQcwExGMAkACgnxelUxZYUPs7ZFEg5VbxMlqk1wBgNyerIU5WO8ysAQA36XcRAIbMUKAbOFntJTe/L4Ix1hYjkE5mHbYQXiItnXhB67taOmGaOQwgleKuxN8UiMGXKRfZUAmxigXY82zW8EzOT7oRwotS0bwRXpRuOFmFUtdUBuuajRTVeB0sU9sA1QhborQ1lVFx04PlGClGf0xLJ2zjyYlKrjkz0jC/wZcrmG0p55m8L5fFZ5PbjYeHtxZk1HpzkwlGRgnI8Dt/0TVIY/cBrjkx5UXpAS07eVEKubHK67l1JRnAyKjYNRSoPXRbjRWTFyXHOLEiFsgvKmJ4zTqAMFZgPFOHzZAXpYDNUbCSwQJBrYJUgrfYgAhR9wXGInEahILMOysylVGWa0jbOGnfz2QNUoQ0bedFaVUvcSLXQAhEkoajQS2dYMs1UDELU3PrZord3wVCAw6aNKWlEzhXBHRFKMwk8p75q9jEtHRCpXEQwUR5UQo7s3UBBKczFHbiyL4ZqoYpZu6MZH9U4ZQOQxP+BRqQBUrhQhev9eaHRuUdL3VFwPnVNogtgVATHD490tA6NMFv4WtycKHtyz2mnwSeqhve4mLmm4+b/uqDYpnH2DkXWniz+NPjO/qkMTT9zdtpNoO4tYiAzOPLhQ4iOzPZ86H5RuZ98th2reXy3rlXz8Iflpr8S1n2Q+pS29yu9b7c/K88VHc9bpq1m+CdgKhN/iW4vv/z9IHNi1MX277UsYMvCe06G1zQWuu/PzQR9Ch+ZKaG8+YWotLHOqcZ12qKFxoGmjOfTk70HG/J9B1vyaBV+unzoETF7xcLHpHW+u/xyZ537VRjIlSDygKCKZpsGGjupfqwTAOSrXlXUjMYJjLkc6tcIECpOupe8J8RGyPo/+y/EGJBK6a5/+b/EU8+v+Y4AADgN/LdfxH+Qd9IAAAAAElFTkSuQmCC",
"width": 32,
"height": 32,
"type": "image/png",
"language": "fra"
},
{
"icon": "iVBORw0KGgoAAAANSUhEUgAAACIAAAAiCAYAAAA6RwvCAAAACXBIWXMAAAsSAAALEgHS3X78AAAEDklEQVRYhc1YTUgUcRR/q7uGUzsuYSClNRcbymS3wII6KNF0Cly7dHSNioIiD3Ppg9IOETHQB50S2vUqhBt1qBZ0pWuQG3VYJJ1SI8h0d4qRsnbjrW+Xv+N87VbYg2H/M/P/v/d732/W499+KA9rTFo64fECLSqBoitCBwDEAGCbxZYxAOjjZDVpxYMXpYIhqiq1BYEYtQGB1I57dEWIOPErG4iuCAKBuM08TgFAFyerHrxwDQCPmPdROmNJ3jIAoFZ9JhZAEB2crGaKDzhZjQNAnM5E6TGetQTjyiK6IsSIoZkbwiwIljhZxXOD9KgdrWklw9EiuiKEAaCbbrMUnKhxCAAynKyqDixuM+cRiOl+UyCEvI+EBRkQ6IJxurfMBJZwv66UDBHRFWHczIKrXEN+nSItgsyrGAOiRLwoPedF6YoVEIM7kGdSV4SQLRCK7KhhT4rqQcwExGMAkACgnxelUxZYUPs7ZFEg5VbxMlqk1wBgNyerIU5WO8ysAQA36XcRAIbMUKAbOFntJTe/L4Ix1hYjkE5mHbYQXiItnXhB67taOmGaOQwgleKuxN8UiMGXKRfZUAmxigXY82zW8EzOT7oRwotS0bwRXpRuOFmFUtdUBuuajRTVeB0sU9sA1QhborQ1lVFx04PlGClGf0xLJ2zjyYlKrjkz0jC/wZcrmG0p55m8L5fFZ5PbjYeHtxZk1HpzkwlGRgnI8Dt/0TVIY/cBrjkx5UXpAS07eVEKubHK67l1JRnAyKjYNRSoPXRbjRWTFyXHOLEiFsgvKmJ4zTqAMFZgPFOHzZAXpYDNUbCSwQJBrYJUgrfYgAhR9wXGInEahILMOysylVGWa0jbOGnfz2QNUoQ0bedFaVUvcSLXQAhEkoajQS2dYMs1UDELU3PrZord3wVCAw6aNKWlEzhXBHRFKMwk8p75q9jEtHRCpXEQwUR5UQo7s3UBBKczFHbiyL4ZqoYpZu6MZH9U4ZQOQxP+BRqQBUrhQhev9eaHRuUdL3VFwPnVNogtgVATHD490tA6NMFv4WtycKHtyz2mnwSeqhve4mLmm4+b/uqDYpnH2DkXWniz+NPjO/qkMTT9zdtpNoO4tYiAzOPLhQ4iOzPZ86H5RuZ98th2reXy3rlXz8Iflpr8S1n2Q+pS29yu9b7c/K88VHc9bpq1m+CdgKhN/iW4vv/z9IHNi1MX277UsYMvCe06G1zQWuu/PzQR9Ch+ZKaG8+YWotLHOqcZ12qKFxoGmjOfTk70HG/J9B1vyaBV+unzoETF7xcLHpHW+u/xyZ537VRjIlSDygKCKZpsGGjupfqwTAOSrXlXUjMYJjLkc6tcIECpOupe8J8RGyPo/+y/EGJBK6a5/+b/EU8+v+Y4AADgN/LdfxH+Qd9IAAAAAElFTkSuQmCC",
"width": 32,
"height": 32,
"type": "image/png",
"language": "eng"
}
]
}
}
]
},
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "OpenRoaming",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "wpa-mixed",
"ieee80211w": "optional"
},
"radius": {
"nas-identifier": "TIPLABAP101",
"chargeable-user-id": true,
"authentication": {
"host": "IP Address of RADIUS",
"port": 11812,
"secret": "passphrase",
"request-attribute": [
{
"id": 126,
"value": "s:TIP"
}
]
},
"accounting": {
"host": "IP Address of RADIUS",
"port": 11813,
"secret": "passphrase",
"request-attribute": [
{
"id": 126,
"value": "s:TIP"
}
],
"interval": 600
}
},
"pass-point": {
"venue-name": [
"eng:Example passpoint_venue",
"fra:Exemple de lieu"
],
"venue-group": 2,
"venue-type": 8,
"venue-url": [
"http://www.example.com/info-fra",
"http://www.example.com/info-eng"
],
"auth-type": {
"type": "terms-and-conditions"
},
"domain-name": "onboard.example.com",
"nai-realm": [
"0,oss.example.com,21[5:7][2:4]"
],
"osen": false,
"anqp-domain": 1234,
"anqp-3gpp-cell-net": [
"310,260",
"310,410"
],
"friendly-name": [
"eng:TIPLabs",
"fra:TIPLabs"
],
"icons": [
{
"icon": "iVBORw0KGgoAAAANSUhEUgAAACIAAAAiCAYAAAA6RwvCAAAACXBIWXMAAAsSAAALEgHS3X78AAAEDklEQVRYhc1YTUgUcRR/q7uGUzsuYSClNRcbymS3wII6KNF0Cly7dHSNioIiD3Ppg9IOETHQB50S2vUqhBt1qBZ0pWuQG3VYJJ1SI8h0d4qRsnbjrW+Xv+N87VbYg2H/M/P/v/d732/W499+KA9rTFo64fECLSqBoitCBwDEAGCbxZYxAOjjZDVpxYMXpYIhqiq1BYEYtQGB1I57dEWIOPErG4iuCAKBuM08TgFAFyerHrxwDQCPmPdROmNJ3jIAoFZ9JhZAEB2crGaKDzhZjQNAnM5E6TGetQTjyiK6IsSIoZkbwiwIljhZxXOD9KgdrWklw9EiuiKEAaCbbrMUnKhxCAAynKyqDixuM+cRiOl+UyCEvI+EBRkQ6IJxurfMBJZwv66UDBHRFWHczIKrXEN+nSItgsyrGAOiRLwoPedF6YoVEIM7kGdSV4SQLRCK7KhhT4rqQcwExGMAkACgnxelUxZYUPs7ZFEg5VbxMlqk1wBgNyerIU5WO8ysAQA36XcRAIbMUKAbOFntJTe/L4Ix1hYjkE5mHbYQXiItnXhB67taOmGaOQwgleKuxN8UiMGXKRfZUAmxigXY82zW8EzOT7oRwotS0bwRXpRuOFmFUtdUBuuajRTVeB0sU9sA1QhborQ1lVFx04PlGClGf0xLJ2zjyYlKrjkz0jC/wZcrmG0p55m8L5fFZ5PbjYeHtxZk1HpzkwlGRgnI8Dt/0TVIY/cBrjkx5UXpAS07eVEKubHK67l1JRnAyKjYNRSoPXRbjRWTFyXHOLEiFsgvKmJ4zTqAMFZgPFOHzZAXpYDNUbCSwQJBrYJUgrfYgAhR9wXGInEahILMOysylVGWa0jbOGnfz2QNUoQ0bedFaVUvcSLXQAhEkoajQS2dYMs1UDELU3PrZord3wVCAw6aNKWlEzhXBHRFKMwk8p75q9jEtHRCpXEQwUR5UQo7s3UBBKczFHbiyL4ZqoYpZu6MZH9U4ZQOQxP+BRqQBUrhQhev9eaHRuUdL3VFwPnVNogtgVATHD490tA6NMFv4WtycKHtyz2mnwSeqhve4mLmm4+b/uqDYpnH2DkXWniz+NPjO/qkMTT9zdtpNoO4tYiAzOPLhQ4iOzPZ86H5RuZ98th2reXy3rlXz8Iflpr8S1n2Q+pS29yu9b7c/K88VHc9bpq1m+CdgKhN/iW4vv/z9IHNi1MX277UsYMvCe06G1zQWuu/PzQR9Ch+ZKaG8+YWotLHOqcZ12qKFxoGmjOfTk70HG/J9B1vyaBV+unzoETF7xcLHpHW+u/xyZ537VRjIlSDygKCKZpsGGjupfqwTAOSrXlXUjMYJjLkc6tcIECpOupe8J8RGyPo/+y/EGJBK6a5/+b/EU8+v+Y4AADgN/LdfxH+Qd9IAAAAAElFTkSuQmCC",
"width": 32,
"height": 32,
"type": "image/png",
"language": "fra"
},
{
"icon": "iVBORw0KGgoAAAANSUhEUgAAACIAAAAiCAYAAAA6RwvCAAAACXBIWXMAAAsSAAALEgHS3X78AAAEDklEQVRYhc1YTUgUcRR/q7uGUzsuYSClNRcbymS3wII6KNF0Cly7dHSNioIiD3Ppg9IOETHQB50S2vUqhBt1qBZ0pWuQG3VYJJ1SI8h0d4qRsnbjrW+Xv+N87VbYg2H/M/P/v/d732/W499+KA9rTFo64fECLSqBoitCBwDEAGCbxZYxAOjjZDVpxYMXpYIhqiq1BYEYtQGB1I57dEWIOPErG4iuCAKBuM08TgFAFyerHrxwDQCPmPdROmNJ3jIAoFZ9JhZAEB2crGaKDzhZjQNAnM5E6TGetQTjyiK6IsSIoZkbwiwIljhZxXOD9KgdrWklw9EiuiKEAaCbbrMUnKhxCAAynKyqDixuM+cRiOl+UyCEvI+EBRkQ6IJxurfMBJZwv66UDBHRFWHczIKrXEN+nSItgsyrGAOiRLwoPedF6YoVEIM7kGdSV4SQLRCK7KhhT4rqQcwExGMAkACgnxelUxZYUPs7ZFEg5VbxMlqk1wBgNyerIU5WO8ysAQA36XcRAIbMUKAbOFntJTe/L4Ix1hYjkE5mHbYQXiItnXhB67taOmGaOQwgleKuxN8UiMGXKRfZUAmxigXY82zW8EzOT7oRwotS0bwRXpRuOFmFUtdUBuuajRTVeB0sU9sA1QhborQ1lVFx04PlGClGf0xLJ2zjyYlKrjkz0jC/wZcrmG0p55m8L5fFZ5PbjYeHtxZk1HpzkwlGRgnI8Dt/0TVIY/cBrjkx5UXpAS07eVEKubHK67l1JRnAyKjYNRSoPXRbjRWTFyXHOLEiFsgvKmJ4zTqAMFZgPFOHzZAXpYDNUbCSwQJBrYJUgrfYgAhR9wXGInEahILMOysylVGWa0jbOGnfz2QNUoQ0bedFaVUvcSLXQAhEkoajQS2dYMs1UDELU3PrZord3wVCAw6aNKWlEzhXBHRFKMwk8p75q9jEtHRCpXEQwUR5UQo7s3UBBKczFHbiyL4ZqoYpZu6MZH9U4ZQOQxP+BRqQBUrhQhev9eaHRuUdL3VFwPnVNogtgVATHD490tA6NMFv4WtycKHtyz2mnwSeqhve4mLmm4+b/uqDYpnH2DkXWniz+NPjO/qkMTT9zdtpNoO4tYiAzOPLhQ4iOzPZ86H5RuZ98th2reXy3rlXz8Iflpr8S1n2Q+pS29yu9b7c/K88VHc9bpq1m+CdgKhN/iW4vv/z9IHNi1MX277UsYMvCe06G1zQWuu/PzQR9Ch+ZKaG8+YWotLHOqcZ12qKFxoGmjOfTk70HG/J9B1vyaBV+unzoETF7xcLHpHW+u/xyZ537VRjIlSDygKCKZpsGGjupfqwTAOSrXlXUjMYJjLkc6tcIECpOupe8J8RGyPo/+y/EGJBK6a5/+b/EU8+v+Y4AADgN/LdfxH+Qd9IAAAAAElFTkSuQmCC",
"width": 32,
"height": 32,
"type": "image/png",
"language": "eng"
}
]
}
}
]
},
```

143
configuration-examples/radius-authenticated-ssid/README.md
View File

@@ -4,86 +4,86 @@ description: OpenWiFi 2.0
# RADIUS Authenticated SSID
When authenticating clients with back office RADIUS systems, the configuration of OpenWiFi permits this on a per SSID basis.
When authenticating clients with back office RADIUS systems, the configuration of OpenWiFi permits this on a per SSID basis.
{% tabs %}
{% tab title="Simple RADIUS" %}
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "OpenWifi",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "wpa2",
"ieee80211w": "optional"
},
"radius": {
"authentication": {
"host": "192.168.178.192",
"port": 1812,
"secret": "secret"
},
"accounting": {
"host": "192.168.178.192",
"port": 1813,
"secret": "secret"
}
}
}
]
},
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "OpenWifi",
"wifi-bands": [
"5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "wpa2",
"ieee80211w": "optional"
},
"radius": {
"authentication": {
"host": "192.168.178.192",
"port": 1812,
"secret": "secret"
},
"accounting": {
"host": "192.168.178.192",
"port": 1813,
"secret": "secret"
}
}
}
]
},
```
{% endtab %}
{% tab title="EAP-Local SSID" %}
```text
"ssids": [
{
"name": "OpenWifi",
"wifi-bands": [
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "wpa2",
"ieee80211w": "optional"
},
"certificates": {
"ca-certificate": "/etc/ucentral/cas.pem",
"certificate": "/etc/ucentral/cert.pem",
"private-key": "/etc/ucentral/key.pem"
},
"radius": {
"local": {
"server-identity": "OpenWiFi-Local-EAP",
"users": [
{
"user-name": "open",
"password": "wifi"
}
]
}
}
}
]
},
"ssids": [
{
"name": "OpenWifi",
"wifi-bands": [
"2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "wpa2",
"ieee80211w": "optional"
},
"certificates": {
"ca-certificate": "/etc/ucentral/cas.pem",
"certificate": "/etc/ucentral/cert.pem",
"private-key": "/etc/ucentral/key.pem"
},
"radius": {
"local": {
"server-identity": "OpenWiFi-Local-EAP",
"users": [
{
"user-name": "open",
"password": "wifi"
}
]
}
}
}
]
},
```
{% endtab %}
{% endtabs %}
@@ -151,7 +151,6 @@ Many parameters are possible with RADIUS authentications given the many methods
<li>port ( example 1813)</li>
<li>secret ( Shared secret with RADIUS server )</li>
</ul>
<p></p>
<p>Additional methods within Access-Request sent in Accounting</p>
<ul>
<li>request-attribute ( id of RADIUS server )

86
configuration-examples/radius-authenticated-ssid/dynamic-vlans-with-radius.md
View File

@@ -4,54 +4,54 @@ description: OpenWiFi 2.0
# Dynamic VLANs with RADIUS
In many deployment scenarios, user authentication is centralized with RADIUS systems. In addition, users may have association to their own networks or private networks. A common approach for this is to dynamically assign VLANs to Wi-Fi subscribers as they join the OpenWiFi network.
In many deployment scenarios, user authentication is centralized with RADIUS systems. In addition, users may have association to their own networks or private networks. A common approach for this is to dynamically assign VLANs to Wi-Fi subscribers as they join the OpenWiFi network.
To configure Dynamic VLANs with RADIUS, associate an SSID with RADIUS authentication, and associate the interface to "upstream" role as dynamic VLANs are most likely to be applicable across the service provider, venue, enterprise network.
To configure Dynamic VLANs with RADIUS, associate an SSID with RADIUS authentication, and associate the interface to "upstream" role as dynamic VLANs are most likely to be applicable across the service provider, venue, enterprise network.
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "OpenWifi",
"wifi-bands": [
"5G", "2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "wpa2",
"ieee80211w": "optional"
},
"radius": {
"authentication": {
"host": "192.168.178.192",
"port": 1812,
"secret": "secret"
},
"accounting": {
"host": "192.168.178.192",
"port": 1813,
"secret": "secret"
}
}
}
]
},
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
},
"ssids": [
{
"name": "OpenWifi",
"wifi-bands": [
"5G", "2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "wpa2",
"ieee80211w": "optional"
},
"radius": {
"authentication": {
"host": "192.168.178.192",
"port": 1812,
"secret": "secret"
},
"accounting": {
"host": "192.168.178.192",
"port": 1813,
"secret": "secret"
}
}
}
]
},
```
### RADIUS Access-Accept
## RADIUS Access-Accept
OpenWiFi devices will determine a VLAN is associated to the authentication of a subscriber when the access-accept message returns the following attribute value pairs:

139
configuration-examples/roaming-rrm-and-son.md
View File

@@ -6,27 +6,27 @@ description: OpenWiFi 2.0
Radio Resource Management and Self Organizing Network features in OpenWiFi 2.0 operate by default in local mode from the Access Point device without dependency on the cloud. Data and state related to client steering and roaming is also possible in co-operation with the cloud when so configured.
Metrics and telemetry are sent to the cloud as desired based on configuration however operation of 802.11k/v/r behavior and autonomous channel control are built in features of all OpenWiFi 2.0 Access Points.
Metrics and telemetry are sent to the cloud as desired based on configuration however operation of 802.11k/v/r behavior and autonomous channel control are built in features of all OpenWiFi 2.0 Access Points.
### Steering
## Steering
OpenWiFi services feature "wifi-steering" determines the operating parameters of RRM on the Access Point.
OpenWiFi services feature "wifi-steering" determines the operating parameters of RRM on the Access Point.
```text
"services": {
"services": {
"wifi-steering": {
"mode": "local",
"network": "upstream",
"assoc-steering": true,
"required-snr": -75,
"required-probe-snr": -70,
"required-roam-snr": -85,
"load-kick-threshold": 90
},
"mode": "local",
"network": "upstream",
"assoc-steering": true,
"required-snr": -75,
"required-probe-snr": -70,
"required-roam-snr": -85,
"load-kick-threshold": 90
},
```
When mode is set to local, the Access Point handles steering decisions autonomously with the surrounding OpenWifi devices.
Which network association, in this case "upstream" will steering be operating on. Note in prior examples most service provider, venue, enterprise services operate on the WAN side upstream network of the Access Point.
When mode is set to local, the Access Point handles steering decisions autonomously with the surrounding OpenWifi devices.
Which network association, in this case "upstream" will steering be operating on. Note in prior examples most service provider, venue, enterprise services operate on the WAN side upstream network of the Access Point.
| Parameter | Value |
| :--- | :--- |
@@ -38,97 +38,94 @@ Which network association, in this case "upstream" will steering be operating on
| required-roam-snr | minimum signal level in dBm client roaming threshold |
| load-kick-threshold | minimum channel load as % available before clients are kicked |
### Apply Wi-Fi Steering to enable 802.11r Fast Roaming SSIDs
## Apply Wi-Fi Steering to enable 802.11r Fast Roaming SSIDs
```text
"ssids": [
{
"name": "OpenWiFi Roaming",
"wifi-bands": [
"2G", "5G"
],
"ssids": [
{
"name": "OpenWiFi Roaming",
"wifi-bands": [
"2G", "5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWiFi",
"ieee80211w": "optional"
},
"roaming": {
"message-exchange": "air",
"generate-psk": true,
"domain-identifier": "EFAB"
},
"services": [ "wifi-steering" ]
"roaming": {
"message-exchange": "air",
"generate-psk": true,
"domain-identifier": "EFAB"
},
"services": [ "wifi-steering" ]
}
]
},
]
},
```
Each SSID to participate in roaming must have "services" : \[ "wifi-steering" \] associated.
Each SSID to participate in roaming must have "services" : \[ "wifi-steering" \] associated.
Additional fast roaming configuration is possible including setting message-exchange either to "air" or "ds" to determine pre authenticated message exchange occurs over the air or distribution system.
Additional fast roaming configuration is possible including setting message-exchange either to "air" or "ds" to determine pre authenticated message exchange occurs over the air or distribution system.
The generate-psk option generates FT response locally for PSK networks. This avoids use of PMK-R1 push/pull from other APs with FT-PSK networks.
The generate-psk option generates FT response locally for PSK networks. This avoids use of PMK-R1 push/pull from other APs with FT-PSK networks.
Configuring domain-identifier sets Mobility Domain identifier \(dot11FTMobilityDomainID, MDID\) permitting segmentation of fast roaming RF topologies.
Configuring domain-identifier sets Mobility Domain identifier \(dot11FTMobilityDomainID, MDID\) permitting segmentation of fast roaming RF topologies.
When pmk-r0-key-holder and pmk-r1-key-holder are left un-configured, the pairwise master key R0 and R1 will generate a deterministic key automatically for fast mobility domain exchange over the air.
When pmk-r0-key-holder and pmk-r1-key-holder are left un-configured, the pairwise master key R0 and R1 will generate a deterministic key automatically for fast mobility domain exchange over the air.
### RRM 802.11k
## RRM 802.11k
To enable 80211k parameters, associate these on a participating SSID basis.
```text
"ssids": [
{
"name": "OpenWiFi Roaming",
"wifi-bands": [
"2G", "5G"
],
"ssids": [
{
"name": "OpenWiFi Roaming",
"wifi-bands": [
"2G", "5G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWiFi",
"ieee80211w": "optional"
},
"roaming": {
"message-exchange": "air",
"generate-psk": true,
"domain-identifier": "EFAB"
},
"rrm": {
"neighbor-reporting": true,
"ftm-responder": true,
"stationary-ap": true
},
"services": [ "wifi-steering" ]
"roaming": {
"message-exchange": "air",
"generate-psk": true,
"domain-identifier": "EFAB"
},
"rrm": {
"neighbor-reporting": true,
"ftm-responder": true,
"stationary-ap": true
},
"services": [ "wifi-steering" ]
}
]
},
]
},
```
In addition to 802.11k features for neighbor reporting, fine timing measurement responder and stationary ap indication, OpenWiFi also supports LCI measurement, Civic Location subelement as well.
In addition to 802.11k features for neighbor reporting, fine timing measurement responder and stationary ap indication, OpenWiFi also supports LCI measurement, Civic Location subelement as well.
### Automatic Channel Balancing
## Automatic Channel Balancing
As part of "wifi-steering" feature, autonomous channel management algorithm may be enabled to establish a self organizing Wi-Fi network.
As part of "wifi-steering" feature, autonomous channel management algorithm may be enabled to establish a self organizing Wi-Fi network.
The auto-channel setting operates in co-ordination with other OpenWiFi Access Points by enumerating the newest AP in the network, then running neighbor and RF scans to determine the best channel of operation. Once the newest AP completes this process, the next AP is sequence will run the same algorithm for channel balancing until all APs in the network complete. The entire process may take up to 5 minutes the first time a network is powered on. The algorithm will re-run every 12 hours.
The auto-channel setting operates in co-ordination with other OpenWiFi Access Points by enumerating the newest AP in the network, then running neighbor and RF scans to determine the best channel of operation. Once the newest AP completes this process, the next AP is sequence will run the same algorithm for channel balancing until all APs in the network complete. The entire process may take up to 5 minutes the first time a network is powered on. The algorithm will re-run every 12 hours.
```text
"services": {
"services": {
"wifi-steering": {
"mode": "local",
"network": "upstream",
"auto-channel": true,
"assoc-steering": true,
"required-snr": -75,
"required-probe-snr": -70,
"required-roam-snr": -85,
"load-kick-threshold": 90
},
"mode": "local",
"network": "upstream",
"auto-channel": true,
"assoc-steering": true,
"required-snr": -75,
"required-probe-snr": -70,
"required-roam-snr": -85,
"load-kick-threshold": 90
},
```

152
configuration-examples/services.md
View File

@@ -4,129 +4,127 @@ description: OpenWiFi 2.0
# Services
OpenWiFi devices have global services that operate either independently system wide or as an association to a physical or logical interface.
OpenWiFi devices have global services that operate either independently system wide or as an association to a physical or logical interface.
Within the "services" configuration block, define the operating mode for each service, then associate a service with an interface.
### SSH
## SSH
Secure shell may optionally be enabled on OpenWiFi devices, associated to specific interface\(s\), and optionally support operator defined keys or password authentication.
```text
"services": {
"ssh": {
"port": 22,
"authorized-keys": {
"items": [
"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQC0ghdSd2D2y08TFowZLMZn3x1/Djw3BkNsIeHt/Z+RaXwvfV1NQAnNdaOngMT/3uf5jZtYxhpl+dbZtRhoUPRvKflKBeFHYBqjZVzD3r4ns2Ofm2UpHlbdOpMuy9oeTSCeF0IKZZ6szpkvSirQogeP2fe9KRkzQpiza6YxxaJlWw== user@example",
"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJ4FDjyCsg+1Mh2C5G7ibR3z0Kw1dU57kfXebLRwS6CL bob@work",
"ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBP/JpJ/KHtKKImzISBDwLO0/EwytIr4pGZQXcP6GCSHchLMyfjf147KNlF9gC+3FibzqKH02EiQspVhRgfuK6y0= alice@home"
]
}
}
}
"services": {
"ssh": {
"port": 22,
"authorized-keys": {
"items": [
"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQC0ghdSd2D2y08TFowZLMZn3x1/Djw3BkNsIeHt/Z+RaXwvfV1NQAnNdaOngMT/3uf5jZtYxhpl+dbZtRhoUPRvKflKBeFHYBqjZVzD3r4ns2Ofm2UpHlbdOpMuy9oeTSCeF0IKZZ6szpkvSirQogeP2fe9KRkzQpiza6YxxaJlWw== user@example",
"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJ4FDjyCsg+1Mh2C5G7ibR3z0Kw1dU57kfXebLRwS6CL bob@work",
"ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBP/JpJ/KHtKKImzISBDwLO0/EwytIr4pGZQXcP6GCSHchLMyfjf147KNlF9gC+3FibzqKH02EiQspVhRgfuK6y0= alice@home"
]
}
}
}
```
#### Associate Service to Interface
### Associate Service to Interface
```text
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh" ],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh" ],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
```
###
## NTP
### NTP
Network time protocol for OpenWiFi devices may be configured to listen for time synchronization from NTP sources and may also be configured to supply NTP source.
Network time protocol for OpenWiFi devices may be configured to listen for time synchronization from NTP sources and may also be configured to supply NTP source.
```text
"services": {
"ntp": {
"servers": [
"0.openwrt.pool.ntp.org",
"1.openwrt.pool.ntp.org"
]
}
}
"services": {
"ntp": {
"servers": [
"0.openwrt.pool.ntp.org",
"1.openwrt.pool.ntp.org"
]
}
}
```
#### Associate to an Interface
### Associate to an Interface
```text
{
"name": "WAN",
"role": "downstream",
"services": [ "ntp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
{
"name": "WAN",
"role": "downstream",
"services": [ "ntp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
},
```
### LLDP
## LLDP
Link Layer Discovery Protocol describes interfaces and capabilities between directly attached neighbors over Layer 2.
Link Layer Discovery Protocol describes interfaces and capabilities between directly attached neighbors over Layer 2.
```text
"lldp": {
"describe": "OpenWiFi",
"location": "Stadium Level 2"
},
"lldp": {
"describe": "OpenWiFi",
"location": "Stadium Level 2"
},
```
Associate "lldp" as a services attribute to any interface.
### MDNS
## MDNS
To assist in device or service discovery over smaller networks, multicast DNS \(mDNS\) protocol if often used. In an mDNS environment there is no local name server for resources to leverage. mDNS zero-configuration service effectively behaves as unicast Domain Name Service \(DNS\).
To assist in device or service discovery over smaller networks, multicast DNS \(mDNS\) protocol if often used. In an mDNS environment there is no local name server for resources to leverage. mDNS zero-configuration service effectively behaves as unicast Domain Name Service \(DNS\).
```text
"mdns": {
"enable": true
},
"mdns": {
"enable": true
},
```
Associate "mdns" as a services attribute to any interface.
### Syslog
## Syslog
Remote syslog systems may be configured to receive device logs in a central location. This content is standard device log and not related to telemetry for metrics and service information received by the OpenWiFi Gateway. Valid port range is from 100 - 65535 with operation over UDP or TCP.
Remote syslog systems may be configured to receive device logs in a central location. This content is standard device log and not related to telemetry for metrics and service information received by the OpenWiFi Gateway. Valid port range is from 100 - 65535 with operation over UDP or TCP.
```text
"log": {
"host": "Syslog Server IP",
"port": 514,
"proto": "udp"
},
"log": {
"host": "Syslog Server IP",
"port": 514,
"proto": "udp"
},
```
Associate "log" as a services attribute to appropriate interface.
Associate "log" as a services attribute to appropriate interface.
### IGMP
## IGMP
When enabled the OpenWiFi device will process IGMP Proxy.
When enabled the OpenWiFi device will process IGMP Proxy.
```text
"igmp": {
"enable": true
},
"igmp": {
"enable": true
},
```
Associate "igmp" as a services attribute to any interface participating in IGMP Proxy.

78
configuration-examples/vxlan.md
View File

@@ -4,57 +4,57 @@ description: OpenWiFi 2.0
# VxLAN
VXLAN’s goal is allowing dynamic large scale isolated virtual L2 networks to be created for virtualized and multi-tenant environments. It does this by encapsulating Ethernet frames in VXLAN packets which when deployed in Wi-Fi topologies can create highly extensible Layer 2 inter-network domains over large campus, MDU, venue service networks.
VXLAN’s goal is allowing dynamic large scale isolated virtual L2 networks to be created for virtualized and multi-tenant environments. It does this by encapsulating Ethernet frames in VXLAN packets which when deployed in Wi-Fi topologies can create highly extensible Layer 2 inter-network domains over large campus, MDU, venue service networks.
VxLAN header uses a 24-bit VNID as a unique layer 2 forwarding domain value. VxLAN maintains layer 2 isolation between the forwarding domains and does not leak MAC addresses into upstream switches. Through the use of 24 bits in VNID VxLAN scales up to 16 million unique LAN forwarding domains.
The VXLAN encapsulation method is IP based and provides for a virtual L2 network. With VXLAN the full Ethernet Frame \(with the exception of the Frame Check Sequence: FCS\) is carried as the payload of a UDP packet. VXLAN utilizes a 24-bit VXLAN header, to identify virtual networks. This header provides for up to 16 million virtual L2 networks.
The VXLAN encapsulation method is IP based and provides for a virtual L2 network. With VXLAN the full Ethernet Frame \(with the exception of the Frame Check Sequence: FCS\) is carried as the payload of a UDP packet. VXLAN utilizes a 24-bit VXLAN header, to identify virtual networks. This header provides for up to 16 million virtual L2 networks.
Frame encapsulation is done by an entity known as a VxLAN Tunnel Endpoint \(VTEP.\) A VTEP has two logical interfaces: an uplink and a downlink. The uplink is responsible for receiving VxLAN frames and acts as a tunnel endpoint with an IP address used for routing VxLAN encapsulated frames.
Frame encapsulation is done by an entity known as a VxLAN Tunnel Endpoint \(VTEP.\) A VTEP has two logical interfaces: an uplink and a downlink. The uplink is responsible for receiving VxLAN frames and acts as a tunnel endpoint with an IP address used for routing VxLAN encapsulated frames.
The VTEP in a TIP OpenWiFi device would be a management interface or designated uplink port\(s\). VTEP in an AP would be the AP WAN interface, or otherwise designated management interface \(such as sub-interface on bridge wan\).
In a traditional L2 switch a behavior known as flood and learn is used for unknown destinations \(i.e. a MAC not stored in the MAC table\). This means that if there is a miss when looking up the MAC the frame is flooded out all ports except the one on which it was received. When a response is sent the MAC is then learned and written to the table.
In a traditional L2 switch a behavior known as flood and learn is used for unknown destinations \(i.e. a MAC not stored in the MAC table\). This means that if there is a miss when looking up the MAC the frame is flooded out all ports except the one on which it was received. When a response is sent the MAC is then learned and written to the table.
The next frame for the same MAC will not incur a miss because the table will reflect the port it exists on. VXLAN preserves this behavior over an IP network using IP multicast groups.
The next frame for the same MAC will not incur a miss because the table will reflect the port it exists on. VXLAN preserves this behavior over an IP network using IP multicast groups.
### Configure VxLAN
## Configure VxLAN
OpenWiFi device will establish a VTEP adjacency to the upstream switch. It is anticipated that any Wi-Fi networks in a VxLAN topology are associated to "upstream" interface\(s\).
OpenWiFi device will establish a VTEP adjacency to the upstream switch. It is anticipated that any Wi-Fi networks in a VxLAN topology are associated to "upstream" interface\(s\).
The following example creates a VxLAN endpoint from a WAN upstream port that will participate in VLAN 100, encapsulate this into VxLAN where it may be distributed across the campus or venue transparently.
The following example creates a VxLAN endpoint from a WAN upstream port that will participate in VLAN 100, encapsulate this into VxLAN where it may be distributed across the campus or venue transparently.
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
},
{
"name": "VXLAN",
"role": "upstream",
"vlan": {
"id": 100
},
"tunnel": {
"proto": "vxlan",
"peer-address": "192.168.178.9",
"peer-port": 4789
},
"ipv4": {
"addressing": "static",
"subnet": "10.0.0.1/24"
}
},
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
},
{
"name": "VXLAN",
"role": "upstream",
"vlan": {
"id": 100
},
"tunnel": {
"proto": "vxlan",
"peer-address": "192.168.178.9",
"peer-port": 4789
},
"ipv4": {
"addressing": "static",
"subnet": "10.0.0.1/24"
}
},
```

206
configuration-examples/wds-topologies.md
View File

@@ -4,123 +4,123 @@ description: OpenWiFi 2.0
# WDS
Wireless Distribution System \(WDS\) supports an Access Point, Station and Repeater mode of operation. OpenWiFi 2.0 supports all three.
Wireless Distribution System \(WDS\) supports an Access Point, Station and Repeater mode of operation. OpenWiFi 2.0 supports all three.
In the below example, the LAN side of the Access Point at the top of the topology will be wirelessly bridged to the LAN side of the Access Point Station at the bottom of the topology.
In the below example, the LAN side of the Access Point at the top of the topology will be wirelessly bridged to the LAN side of the Access Point Station at the bottom of the topology.
{% tabs %}
{% tab title="WDS-AP" %}
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
},
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh", "lldp" ],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
"ssids": [
{
"name": "OpenWifi_WDS_AP",
"wifi-bands": [
"5G"
],
"bss-mode": "wds-ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
},
"roaming": {
"message-exchange": "ds",
"generate-psk": true
}
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "static",
"subnet": "192.168.10.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
}
}
],
],
"ipv4": {
"addressing": "dynamic"
}
},
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh", "lldp" ],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
"ssids": [
{
"name": "OpenWifi_WDS_AP",
"wifi-bands": [
"5G"
],
"bss-mode": "wds-ap",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
},
"roaming": {
"message-exchange": "ds",
"generate-psk": true
}
}
],
"ipv4": {
"addressing": "static",
"subnet": "192.168.10.1/24",
"dhcp": {
"lease-first": 10,
"lease-count": 100,
"lease-time": "6h"
}
}
}
],
```
{% endtab %}
{% tab title="WDS-STA" %}
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
},
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh", "lldp" ],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
"ssids": [
{
"name": "OpenWifi_WDS_AP",
"wifi-bands": [
"5G"
],
"bss-mode": "wds-sta",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
},
"roaming": {
"message-exchange": "ds",
"generate-psk": true
}
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
}
],
"ipv4": {
"addressing": "dynamic"
}
},
{
"name": "LAN",
"role": "downstream",
"services": [ "ssh", "lldp" ],
"ethernet": [
{
"select-ports": [
"LAN*"
]
}
],
"ssids": [
{
"name": "OpenWifi_WDS_AP",
"wifi-bands": [
"5G"
],
"bss-mode": "wds-sta",
"encryption": {
"proto": "psk2",
"key": "OpenWifi",
"ieee80211w": "optional"
},
"roaming": {
"message-exchange": "ds",
"generate-psk": true
}
}
],
}
```
{% endtab %}
{% endtabs %}
In this configuration, LAN clients of the WDS Station AP receive IP addresses from the WDS Access Point AP from its LAN side DHCP service, via WDS link at 5GHz.
In this configuration, LAN clients of the WDS Station AP receive IP addresses from the WDS Access Point AP from its LAN side DHCP service, via WDS link at 5GHz.

6
getting-started/README.md
View File

@@ -4,9 +4,9 @@ description: OpenWiFi 2.0
# 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.
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:
## Initial release 2.0 SDK includes:
* Zero Touch Cloud Discovery
* Firmware Management
@@ -31,5 +31,3 @@ Upcoming sprint for August includes Dynamic Provisioning service support for tem
OpenWiFi 2.0 SDK is deployable as both a Docker Compose or a Helm on Kubernetes model. See [Release 2.0 SDK](sdk/) section for installation instructions.

16
getting-started/access-points/README.md
View File

@@ -4,21 +4,21 @@ description: OpenWiFi 2.0
# Access Points
Initial Minimum Viable Product Release 2.0 does not include template driven device provisioning, this will be available in the next sprint.
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.
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
## Device Interactions with SDK
![OpenWiFi with uCentral Management](../../.gitbook/assets/image%20%2822%29.png)
OpenWiFi 2.0 follows the uCentral system. Complete data model is available [here](http://ucentral.io/docs/ucentral-schema.html). Upon discovery of the cloud, a device default or specific configuration is transferred.
OpenWiFi 2.0 follows the uCentral system. Complete data model is available [here](http://ucentral.io/docs/ucentral-schema.html). Upon discovery of the cloud, a device default or specific configuration is transferred.
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.
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.
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:
For example results returned to SDK from a device configuration error:
```text
"results": {
@@ -30,5 +30,3 @@ For example results returned to SDK from a device configuration error:
],
```

38
getting-started/access-points/local-device-settings.md
View File

@@ -4,20 +4,20 @@ description: OpenWiFi 2.0 Devices
# Local Device Settings
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.
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.
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.
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.
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
## Using Maverick
![Maverick Login Page](../../.gitbook/assets/screen-shot-2021-07-29-at-5.04.23-pm.png)
After association to the Maverick SSID, open a web browser to `http://192.168.1.1`
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`**
![Logged into Maverick](../../.gitbook/assets/screen-shot-2021-07-29-at-5.06.35-pm.png)
@@ -30,41 +30,29 @@ If connection uses Point to Point over Ethernet \(PPPoE\) username and password
![PPPoE Uplink](../../.gitbook/assets/screen-shot-2021-07-29-at-5.09.14-pm.png)
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.
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.
![Cellular Uplink](../../.gitbook/assets/screen-shot-2021-07-29-at-5.11.05-pm.png)
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.
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.
![Uplink Static IP](../../.gitbook/assets/screen-shot-2021-07-29-at-5.12.39-pm.png)
Otherwise leave the Uplink configuration to DHCP or cloud defaults.
Otherwise leave the Uplink configuration to DHCP or cloud defaults.
![Uplink DHCP](../../.gitbook/assets/screen-shot-2021-07-29-at-5.13.40-pm.png)
### Manual Redirector and Certificate Upload
## 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.
![Local Redirector Setting](../../.gitbook/assets/screen-shot-2021-07-29-at-5.16.01-pm.png)
### System
## System
It is possible to reset the device to defaults, or locally update firmware using the commands available from System.
It is possible to reset the device to defaults, or locally update firmware using the commands available from System.
![System Commands](../../.gitbook/assets/screen-shot-2021-07-29-at-5.17.13-pm.png)
\*\*\*\*

22
getting-started/cloud-discovery/README.md
View File

@@ -4,25 +4,21 @@ description: OpenWiFi 2.0
# Cloud Discovery
All TIP OpenWiFi devices use the same cloud discovery mechanism on initial boot.
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.
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.
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.
![Device First Boot / Factory Cloud Discovery](../../.gitbook/assets/image%20%2824%29.png)
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.
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.
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.

10
getting-started/cloud-discovery/discovery-without-cloud.md
View File

@@ -4,7 +4,7 @@ description: OpenWiFi 2.0
# Discovery without Cloud
There could be reasons cloud discovery does not complete.
There could be reasons cloud discovery does not complete.
These include:
* Lack of Internet Connectivity
@@ -15,13 +15,13 @@ These include:
![Manual Cloud Entry](../../.gitbook/assets/image%20%2825%29.png)
When the cloud can not be automatically discovered, OpenWiFi devices will turn on a local admin web UI made available via SSID "Maverick".
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](../access-points/local-device-settings.md) for details on using Maverick.
[
The Maverick UI will support configuring WAN interface parameters, including DHCP, Static, PPPoE, and LTE/5G settings. Please see [Local Device Settings](../access-points/local-device-settings.md) for details on using Maverick.
[
](../access-points/local-device-settings.md)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.
For non-Wi-Fi devices such as PoE access switches, the same cloud location information may be configured using local management interface.
![Admin / User Entered WAN or Cloud](../../.gitbook/assets/image%20%2823%29.png)

4
getting-started/sdk/README.md
View File

@@ -4,7 +4,7 @@ description: TIP OpenWiFi
# Release 2.0 SDK
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.
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:
@@ -19,5 +19,3 @@ Features of the 2.0 SDK at July MVP include:
![OpenWiFi 2.0 SDK](../../.gitbook/assets/image%20%2835%29.png)

56
getting-started/sdk/deploy-using-docker-compose.md
View File

@@ -8,40 +8,40 @@ The [wlan-cloud-ucentral-deploy repository](https://github.com/Telecominfraproje
### Volumes
The deployment creates local volumes to persist mostly application and database data. In addition to that several bind mounts are created:
`docker-compose/certs/` directory used by multiple services
The deployment creates local volumes to persist mostly application and database data. In addition to that several bind mounts are created:
`docker-compose/certs/` directory used by multiple services
Service specific data directories and configuration files located under `docker-compose/` mounted into the appropriate containers.
{% hint style="info" %}
Be aware that the deployment uses bind mounts on the host to mount certificate and configuration data for the micro services and therefore these files and directories will be owned by the user in the container.
Be aware that the deployment uses bind mounts on the host to mount certificate and configuration data for the micro services and therefore these files and directories will be owned by the user in the container.
Since the files are under version control, you may have to change the ownership to your user again before pulling changes.
{% endhint %}
### Configuration
Changing image tags used in the deployments may be performed in `docker-compose/.env`.
Changing image tags used in the deployments may be performed in `docker-compose/.env`.
By default this file specifies the micro service image tags according to the release branch you have checked out.
By default this file specifies the micro service image tags according to the release branch you have checked out.
Additional configuration changes such as database settings or passwords are found in the various other service specific `.env` files.
Additional configuration changes such as database settings or passwords are found in the various other service specific `.env` files.
The rest of the configuration is done through the config files located in the appropriate subdirectories of the Compose project directory.
### Ports
Exposed port dependencies by application are listed below:
`127.0.0.1:80/tcp` - OpenWiFi-UI
`127.0.0.1:5912/tcp` - rttys dev
`127.0.0.1:5913/tcp` - rttys user
`0.0.0.0:15002/tcp` - OpenWiFi-uCentralGW websocket
`127.0.0.1:16002/tcp` - OpenWiFi-uCentralGW REST API public
`0.0.0.0:16003/tcp` - OpenWiFi-uCentralGW fileupload
`127.0.0.1:16102/tcp` - OpenWiFi-uCentralGW alivecheck
`127.0.0.1:16001/tcp` - OpenWiFi-uCentralSec REST API public
`127.0.0.1:16101/tcp` - OpenWiFi-uCentralSec alivecheck
Exposed port dependencies by application are listed below:
`127.0.0.1:80/tcp` - OpenWiFi-UI
`127.0.0.1:5912/tcp` - rttys dev
`127.0.0.1:5913/tcp` - rttys user
`0.0.0.0:15002/tcp` - OpenWiFi-uCentralGW websocket
`127.0.0.1:16002/tcp` - OpenWiFi-uCentralGW REST API public
`0.0.0.0:16003/tcp` - OpenWiFi-uCentralGW fileupload
`127.0.0.1:16102/tcp` - OpenWiFi-uCentralGW alivecheck
`127.0.0.1:16001/tcp` - OpenWiFi-uCentralSec REST API public
`127.0.0.1:16101/tcp` - OpenWiFi-uCentralSec alivecheck
{% hint style="info" %}
By default only the websocket and fileupload component of the OpenWiFi uCentralGW \(Gateway\) micro service are exposed on all interfaces. All other exposed services listen on localhost. You can change that according to your needs in the `ports` sections of`docker-compose/docker-compose.yml`.
@@ -49,9 +49,9 @@ By default only the websocket and fileupload component of the OpenWiFi uCentralG
### Certificates
The repository includes a TIP Root CA Digicert-signed \(for the Gateway websocket to devices\) and a self-signed certificate \(for the REST API northbound and other components\), which you can use to create a local deployment out of the box.
The repository includes a TIP Root CA Digicert-signed \(for the Gateway websocket to devices\) and a self-signed certificate \(for the REST API northbound and other components\), which you can use to create a local deployment out of the box.
The certificates are valid for the `*.wlan.local` domain.
The certificates are valid for the `*.wlan.local` domain.
## How to
@@ -71,12 +71,14 @@ ucentral_ucentralsec.wlan.local_1 /bin/sh -c /ucentral/ucent ... Up 127
ucentral_zookeeper_1 /docker-entrypoint.sh zkSe ... Up 2181/tcp, 2888/tcp, 3888/tcp, 8080/tcp
```
5. Since the certificate for the REST API and other components is self-signed, you have to add it to the system trust store of the containers communicating together internally via TLS. The `add-ca-cert.sh` script located in the Compose project directory does the work for you.
You also have to trust the self-signed REST API certificate on your local machine. To achieve that you either have to add `certs/restapi-ca.pem` to your trusted browser certificates or add certificate exceptions in your browser by visiting `https://ucentral.wlan.local:16001` and `https://ucentral.wlan.local:16002` and accepting the self-signed SSL certificate warnings \(make sure to visit both and add the exceptions\).
6. Connect to your AP via SSH and add a static hosts entry in `/etc/hosts` for `ucentral.wlan.local` which points to the address of the host the Compose deployment runs on.
7. While staying in the SSH session, copy the content of `certs/restapi-ca.pem` on your local machine to your clipboard and append it to the file `/etc/ssl/cert.pem` on the AP. This way your AP will also trust the self-signed certificate.
8. Go to `http://ucentral.wlan.local` to visit the UI and login with username `tip@ucentral.com` and password `openwifi` if you didn't change the default credentials in the uCentralSec configuration.
9. To use the curl test scripts which are included in the micro service repositories make sure to set the following environment variables before issuing a request:
1. Since the certificate for the REST API and other components is self-signed, you have to add it to the system trust store of the containers communicating together internally via TLS. The `add-ca-cert.sh` script located in the Compose project directory does the work for you.
You also have to trust the self-signed REST API certificate on your local machine. To achieve that you either have to add `certs/restapi-ca.pem` to your trusted browser certificates or add certificate exceptions in your browser by visiting `https://ucentral.wlan.local:16001` and `https://ucentral.wlan.local:16002` and accepting the self-signed SSL certificate warnings \(make sure to visit both and add the exceptions\).
2. Connect to your AP via SSH and add a static hosts entry in `/etc/hosts` for `ucentral.wlan.local` which points to the address of the host the Compose deployment runs on.
3. While staying in the SSH session, copy the content of `certs/restapi-ca.pem` on your local machine to your clipboard and append it to the file `/etc/ssl/cert.pem` on the AP. This way your AP will also trust the self-signed certificate.
4. Go to `http://ucentral.wlan.local` to visit the UI and login with username `tip@ucentral.com` and password `openwifi` if you didn't change the default credentials in the uCentralSec configuration.
5. To use the curl test scripts which are included in the micro service repositories make sure to set the following environment variables before issuing a request:
```text
export UCENTRALSEC="ucentral.wlan.local:16001"

10
getting-started/sdk/deploy-using-helm.md
View File

@@ -17,16 +17,16 @@ There are multiple ways you can install OpenWiFi SDK with assembly charts:
1. One way is by installing directly from the assembly chart’s repository. For that, you’ll need to install and extra Helm plugin that is used to pull the latest charts code from all the referenced micro services: [https://github.com/aslafy-z/helm-git](https://github.com/aslafy-z/helm-git).
2. Another way, which is considered more stable, is by installing from a prepackaged bundle that is published to [https://tip.jfrog.io/ui/native/tip-wlan-cloud-ucentral-helm/](https://tip.jfrog.io/ui/native/tip-wlan-cloud-ucentral-helm/) on every official uCentral release. For this approach to work, you don’t need to install any additional plugins or dependencies, just to make sure you’ve got Helm installed on your local system.
#### Directly from the Assembly repository
### Directly from the Assembly repository
1. Install the helm-git pluging according to the official documentation
2. Run helm upgrade --install tip-ucentral git+https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/@chart?ref=main
3. You can also reference any other open branch from the deployment repository. For example, if you want to deploy using the assembly code from the v2.0.0-rc1 branch, you can just run helm upgrade --install tip-ucentral git+https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/@chart?ref=v2.0.0-rc1
2. Run helm upgrade --install tip-ucentral git+[https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/@chart?ref=main](https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/@chart?ref=main)
3. You can also reference any other open branch from the deployment repository. For example, if you want to deploy using the assembly code from the v2.0.0-rc1 branch, you can just run helm upgrade --install tip-ucentral git+[https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/@chart?ref=v2.0.0-rc1](https://github.com/Telecominfraproject/wlan-cloud-ucentral-deploy/@chart?ref=v2.0.0-rc1)
#### Using the pre-built Helm package
### Using the pre-built Helm package
1. This method doesn’t require to install anything locally other than Helm
2. Start by adding the wlan-cloud-ucentral Helm repository to your local list of repositories by running helm repo add tip-ucentral https://tip.jfrog.io/artifactory/tip-wlan-cloud-ucentral-helm/
2. Start by adding the wlan-cloud-ucentral Helm repository to your local list of repositories by running helm repo add tip-ucentral [https://tip.jfrog.io/artifactory/tip-wlan-cloud-ucentral-helm/](https://tip.jfrog.io/artifactory/tip-wlan-cloud-ucentral-helm/)
3. helm upgrade --install tip-ucentral wlan-cloud-ucentral to install the latest version, or specify the release you want to install by adding the --version x.y.z flag.
## Chart configuration using the Values file

6
monitoring/README.md
View File

@@ -4,13 +4,13 @@ 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.
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 third party monitoring subsystems.
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 third 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 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:

6
monitoring/elk-integration.md
View File

@@ -4,15 +4,15 @@ 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 :
The following pipeline is used to leverage Kafka messages being emitted from OpenWiFi 2.0 for ELK \(Elastic Logstash Kibana\) stack integration :
![](../.gitbook/assets/kafka-elk-pipeline.png)
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.
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:
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:
![](../.gitbook/assets/kibana.png)

22
provisioning/README.md
View File

@@ -11,30 +11,28 @@ As a minimum, the OpenWiFi 2.0 SDK framework offers a Security service which han
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 micro service.
In future sprints of OpenWiFi dynamic device provisioning will be available as an added micro service.
### Gateway
## 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.
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.
![Southbound Interface to Devices](../.gitbook/assets/image%20%2831%29.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.
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 micro service 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.
Upon successful connection the device exchanges its capabilities with the OpenWiFi SDK. OpenWIFi SDK, via the Gateway micro service 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.
![High Level SDK Gateway to uCentral Agent](../.gitbook/assets/image%20%2830%29.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.
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.
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 micro service 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.
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 micro service 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.

251
provisioning/creating-a-configuration.md
View File

@@ -4,83 +4,83 @@ 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.
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
## Start with Location and Radios
We will set the unit location and timezone, then proceed to configure radios.
```text
{
"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
}
}
],
"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.
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.
Control of beacon interval and multicast rates is possible per radio as shown in the "rates" section.
### Interfaces
## 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.
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.
```text
"interfaces": [
{
"name": "WAN",
"role": "upstream",
"services": [ "lldp", "dhcp-snooping" ],
"ethernet": [
{
"select-ports": [
"WAN*"
]
}
],
"ipv4": {
"addressing": "dynamic"
}
"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.
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.
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
### 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.
@@ -88,7 +88,7 @@ Imagine the OpenWiFi device is an enterprise Access Point mounted on a ceiling.
{
"name": "WAN100",
"role": "upstream",
"services": [ "lldp", "dhcp-snooping" ],
"services": [ "lldp", "dhcp-snooping" ],
"vlan": {
"id": 100
},
@@ -98,7 +98,7 @@ Imagine the OpenWiFi device is an enterprise Access Point mounted on a ceiling.
"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.
@@ -106,98 +106,95 @@ In this next section of configuration, an additional logical interface associate
To associate the Wi-Fi with the VLAN interface define, we continue within the WAN100 interface adding SSID services.
```text
"ssids": [
{
"name": "TIP OpenWiFi",
"wifi-bands": [
"5G", "2G"
],
"bss-mode": "ap",
"encryption": {
"proto": "psk2",
"key": "OpenWiFi",
"ieee80211w": "optional"
}
},
"services": [ "wifi-frames"]
"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.
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.
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.
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
### Sending Data
Add metrics to our configuration that will help expose state of the Wi-Fi network and its services to the cloud.
Add metrics to our configuration that will help expose state of the Wi-Fi network and its services to the cloud.
```text
"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" ]
}
},
"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 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.
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.
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.
To assist with fingerprinting and client troubleshooting, dhcp-snooping sends the cloud all current client DHCP and DHCPv6 state.
#### Global Services
### Global Services
The final section of the simple configuration example turns on LLDP and SSH where those services were associated to interfaces listed above.
The final section of the simple configuration example turns on LLDP and SSH where those services were associated to interfaces listed above.
```text
"services": {
"lldp": {
"describe": "TIP OpenWiFi",
"location": "LivingLab"
},
"ssh": {
"port": 22
}
}
"services": {
"lldp": {
"describe": "TIP OpenWiFi",
"location": "LivingLab"
},
"ssh": {
"port": 22
}
}
}
```
The complete simple configuration file as described in this page may be downloaded here:
The complete simple configuration file as described in this page may be downloaded here:
{% file src="../.gitbook/assets/simpleconfig\_openwifidocs.json" caption="SimpleConfig\_Wi-Fi\_VLAN" %}

27
provisioning/data-model-introduction.md
View File

@@ -4,29 +4,28 @@ description: OpenWiFi 2.0
# Data Model Introduction
OpenWiFi 2.0 data model for device management is based on uCentral.
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.
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.
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://ucentral.io/docs/ucentral-schema.html](https://ucentral.io/docs/ucentral-schema.html)
The complete data model may be found here : [https://ucentral.io/docs/ucentral-schema.html](https://ucentral.io/docs/ucentral-schema.html)
### Organization
## 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.
![uCentral Agent Schema Processing](../.gitbook/assets/image%20%2837%29.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.
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.
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.
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.
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.
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.

36
user-interface/README.md
View File

@@ -4,27 +4,27 @@ description: OpenWiFi 2.0
# User Interface
Release 2.0 uses a Single-Page Application \(SPA\) as an example user interface built using React to demonstrate several interactions using the northbound OpenAPI.
Release 2.0 uses a Single-Page Application \(SPA\) as an example user interface built using React to demonstrate several interactions using the northbound OpenAPI.
### Login to OpenWiFi SDK
## Login to OpenWiFi SDK
![Login Page](../.gitbook/assets/screen-shot-2021-07-28-at-4.40.17-pm.png)
Default username is: **`tip@ucentral.com`** and password is: **`openwifi`**
### **Base Navigation**
## **Base Navigation**
A left side navigation menu provides direction to major feature or service settings.
A left side navigation menu provides direction to major feature or service settings.
![Left Navigation](../.gitbook/assets/screen-shot-2021-07-29-at-3.21.37-pm.png)
### Internationalization
## Internationalization
OpenWiFi 2.0 SDK supports multiple languages. Simply select the desired language from the right drop down for pages to re-populate accordingly.
OpenWiFi 2.0 SDK supports multiple languages. Simply select the desired language from the right drop down for pages to re-populate accordingly.
![](../.gitbook/assets/screen-shot-2021-07-29-at-3.26.35-pm.png)
### Devices
## Devices
Upon login the first page presented is a Devices table. This table reflects all discovered and managed devices known by the OpenWiFi SDK.
@@ -34,33 +34,33 @@ Devices table indicates device Connected or Disconnected state in the first colu
Certificate column indicates invalid, valid with mismatch serial, or valid device certificate identity state as red crossed seal, yellow seal and green seal respectively.
Serial Number column links to the device record.
Serial Number column links to the device record.
Compatible model, Tx, Rx, and connected IP Address present basic information of the device type and its connection.
Compatible model, Tx, Rx, and connected IP Address present basic information of the device type and its connection.
Three final columns provide Details \(also obtained by selecting the serial number\), Wi-Fi Analysis presenting current Wi-Fi associations and their performance and Refresh commands.
Three final columns provide Details \(also obtained by selecting the serial number\), Wi-Fi Analysis presenting current Wi-Fi associations and their performance and Refresh commands.
### Displaying Associations
## Displaying Associations
From the Devices table, second from right column icon the WiFi Analysis may be accessed. This may also be accessed within the Device View page of a single record along the top right of Statistics section.
From the Devices table, second from right column icon the WiFi Analysis may be accessed. This may also be accessed within the Device View page of a single record along the top right of Statistics section.
![Wi-Fi Analysis](../.gitbook/assets/screen-shot-2021-08-01-at-12.04.36-pm.png)
Within the WiFi Analysis page, all active associations are displayed with the ability to view approximately the last 30 minutes of data reported from the Access Point.
Within the WiFi Analysis page, all active associations are displayed with the ability to view approximately the last 30 minutes of data reported from the Access Point.
For each association the device MAC address, mode of connection and SSID are displayed. This will include end devices as well as Wi-Fi infrastructure such as WDS and Mesh associations.
For each association the device MAC address, mode of connection and SSID are displayed. This will include end devices as well as Wi-Fi infrastructure such as WDS and Mesh associations.
![](../.gitbook/assets/screen-shot-2021-07-28-at-4.54.43-pm.png)
Associations have RSSI, Rx Rate & Bytes, Tx Rate & Bytes, MCS negotiated, Number Spatial Streams and IP Address information.
Associations have RSSI, Rx Rate & Bytes, Tx Rate & Bytes, MCS negotiated, Number Spatial Streams and IP Address information.
### Dashboard View
## Dashboard View
OpenWiFi SDK provides visual indications on the overall health of the deployed Wi-Fi network. this includes Device Status for connected and non-connected devices. Device health indicating percentage of devices failing a health check. Distribution of devices by vendor in the network and by model.
OpenWiFi SDK provides visual indications on the overall health of the deployed Wi-Fi network. this includes Device Status for connected and non-connected devices. Device health indicating percentage of devices failing a health check. Distribution of devices by vendor in the network and by model.
![Dashboard View](../.gitbook/assets/screen-shot-2021-08-01-at-12.06.15-pm.png)
Additionally, verified certificates or serial mismatch certificates, number of Command actions from all Gateways to devices and devices with greater than 75% memory utilization, greater than 50% less than 75% memory and less than 50% utilization are displayed.
Additionally, verified certificates or serial mismatch certificates, number of Command actions from all Gateways to devices and devices with greater than 75% memory utilization, greater than 50% less than 75% memory and less than 50% utilization are displayed.
![](../.gitbook/assets/screen-shot-2021-07-30-at-12.09.27-am.png)

31
user-interface/devices-view/README.md
View File

@@ -4,7 +4,7 @@ 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:
Each device presents Metrics and Health check data to the Gateway. Devices view displays this information in the following organization:
* Status
* Configuration
@@ -16,37 +16,36 @@ Each device presents Metrics and Health check data to the Gateway. Devices view
![Initial Device View](../../.gitbook/assets/screen-shot-2021-07-28-at-5.15.03-pm.png)
### Status
## 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.
Uptime and Last Contact reflect communication state.
Load indicates processing load on the device.
Memory Used indicates free memory on the device.
![Device Status](../../.gitbook/assets/screen-shot-2021-07-28-at-5.17.59-pm.png)
### Configuration
## 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.
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.
![Device view Configuration Panel](../../.gitbook/assets/screen-shot-2021-07-28-at-5.21.07-pm.png)
### Logs
## Logs
Log history of the device is presented within Logs. Expand the tile selecting the down arrow.
Log history of the device is presented within Logs. Expand the tile selecting the down arrow.
![](../../.gitbook/assets/screen-shot-2021-07-28-at-5.25.29-pm.png)
### Health
## 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.
![](../../.gitbook/assets/screen-shot-2021-07-28-at-5.24.00-pm.png)
### Commands
## Commands
Commands tile provides a number of administrative actions for the user:
@@ -57,9 +56,9 @@ Commands tile provides a number of administrative actions for the user:
| 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 |
| Trace | Initiate a remote Packet Capture |
| Factory Reset | Hard Reset remote device - destroys device local config |
| Configure | Upload Device Configuration |
![Commands Tile](../../.gitbook/assets/screen-shot-2021-07-28-at-5.25.50-pm.png)

4
user-interface/devices-view/command-history.md
View File

@@ -4,7 +4,7 @@ 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.
Multiple events are recorded in the Command History tile. Each line item will have a Result, Details, and Delete action.
![Command History Tile](../../.gitbook/assets/screen-shot-2021-07-29-at-3.10.22-pm.png)
@@ -24,5 +24,3 @@ Remote packet capture is shown as the trace command history. When packet capture
![trace Command History](../../.gitbook/assets/screen-shot-2021-07-29-at-3.16.52-pm.png)

42
user-interface/devices-view/commands.md
View File

@@ -4,50 +4,48 @@ 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.
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
## 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.
Selecting the Reboot action will prompt the below dialog. Options presented permit an immediate reboot or a scheduled reboot based on date and time.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-2.25.03-pm.png)
### Firmware Upgrade
## 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.
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.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-2.28.44-pm.png)
### 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.
## 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.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-2.31.03-pm.png)
#### Wi-Fi Scan Results
### 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.
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.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-2.33.58-pm.png)
### Connect
## 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.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-2.35.48-pm.png)
### Blink
## 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.
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.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-2.37.30-pm.png)
### Trace
## 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.
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.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-2.39.24-pm.png)
@@ -55,9 +53,9 @@ Once complete the user is asked to open or save the packet capture file locally.
![](../../.gitbook/assets/image%20%2838%29.png)
### Factory Reset
## 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.
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.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-2.46.29-pm.png)
@@ -65,11 +63,9 @@ It is possible to revert a device to initial out of box state from the OpenWiFi
Note: When Redirector is not kept, devices will re-contact the Certificate Authority to re-discover their OpenWiFi cloud address
{% endhint %}
### Configure
## 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.
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.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-2.48.31-pm.png)

18
user-interface/devices-view/statistics.md
View File

@@ -8,31 +8,31 @@ Each device page presents statistics in traffic terms per interface as a line gr
![](../../.gitbook/assets/screen-shot-2021-07-29-at-2.52.10-pm.png)
The generated image may be downloaded for offline use.
The generated image may be downloaded for offline use.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-2.53.14-pm.png)
Accessing Wi-Fi Analysis and Last Statistics may be found at the top right of Statistics tile.
Accessing Wi-Fi Analysis and Last Statistics may be found at the top right of Statistics tile.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-3.06.20-pm.png)
### Wi-Fi Analysis
## Wi-Fi Analysis
Operating channels, channel width, noise floor and transmit power are the first values reported in Radios table.
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.
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.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-2.57.34-pm.png)
The access point view of RSSI, Rx and Tx Rate, Modulation Coding Scheme and Number of Spatial Streams are exposed for each association.
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.
Using the slider along the top, the last 15 to 30 minutes of performances data may be viewed.
### Latest Statistics
## 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.
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.
![](../../.gitbook/assets/screen-shot-2021-07-29-at-3.04.42-pm.png)

22
user-interface/firmware.md
View File

@@ -4,33 +4,33 @@ 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.
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
## 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.
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.
![Firmware Dashboard](../.gitbook/assets/screen-shot-2021-08-01-at-12.07.27-pm.png)
### Device Table
## 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.
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.
![Firmware Control in Device Table](../.gitbook/assets/screen-shot-2021-08-01-at-12.08.45-pm.png)
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.
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
## Firmware Management Service
Viewing the contents of Firmware Management Service is available from the left navigation, select Firmware.
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.
Once in Firmware, it is possible to search by device model for all known firmware revisions.
![Firmware Management Service](../.gitbook/assets/screen-shot-2021-07-29-at-4.43.57-pm.png)
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.
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.
Selecting Details will present information for any firmware row, including the URI which may be copied into the Choose Custom Firmware dialog prompt accordingly.
![Firmware Entry Details](../.gitbook/assets/screen-shot-2021-07-29-at-4.46.01-pm.png)