GitBook: [#29] Admin Usage
BIN
.gitbook/assets/Screen Shot 2022-07-19 at 2.36.39 PM.png
Normal file
|
After Width: | Height: | Size: 175 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-19 at 2.39.45 PM.png
Normal file
|
After Width: | Height: | Size: 375 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-19 at 2.42.29 PM.png
Normal file
|
After Width: | Height: | Size: 61 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-19 at 2.44.19 PM.png
Normal file
|
After Width: | Height: | Size: 168 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-19 at 3.00.27 PM.png
Normal file
|
After Width: | Height: | Size: 55 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 1.07.24 PM.png
Normal file
|
After Width: | Height: | Size: 234 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 1.21.43 PM.png
Normal file
|
After Width: | Height: | Size: 295 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 1.24.18 PM.png
Normal file
|
After Width: | Height: | Size: 95 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 1.25.43 PM.png
Normal file
|
After Width: | Height: | Size: 106 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 1.29.54 PM.png
Normal file
|
After Width: | Height: | Size: 161 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 1.37.02 PM.png
Normal file
|
After Width: | Height: | Size: 112 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 1.38.22 PM.png
Normal file
|
After Width: | Height: | Size: 173 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 11.17.24 AM.png
Normal file
|
After Width: | Height: | Size: 135 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 11.17.56 AM.png
Normal file
|
After Width: | Height: | Size: 69 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 11.27.42 AM.png
Normal file
|
After Width: | Height: | Size: 87 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 11.28.28 AM.png
Normal file
|
After Width: | Height: | Size: 158 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 11.34.02 AM.png
Normal file
|
After Width: | Height: | Size: 186 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 11.36.08 AM.png
Normal file
|
After Width: | Height: | Size: 230 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 11.37.22 AM.png
Normal file
|
After Width: | Height: | Size: 163 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 11.38.58 AM.png
Normal file
|
After Width: | Height: | Size: 103 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 11.40.03 AM.png
Normal file
|
After Width: | Height: | Size: 200 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 11.48.24 AM.png
Normal file
|
After Width: | Height: | Size: 114 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 12.01.11 PM.png
Normal file
|
After Width: | Height: | Size: 257 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 12.03.23 PM.png
Normal file
|
After Width: | Height: | Size: 124 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 12.04.00 PM.png
Normal file
|
After Width: | Height: | Size: 131 KiB |
BIN
.gitbook/assets/Screen Shot 2022-07-20 at 4.54.58 PM.png
Normal file
|
After Width: | Height: | Size: 278 KiB |
10
SUMMARY.md
@@ -30,8 +30,16 @@
|
||||
* [Data Model Introduction](sdk/provisioning/data-model-introduction.md)
|
||||
* [Creating a Configuration](sdk/provisioning/creating-a-configuration.md)
|
||||
* [User Interface for Admins](sdk/user-interface/README.md)
|
||||
* [Provisioning](sdk/user-interface/device-provisioning/README.md)
|
||||
* [Creating Entities](sdk/user-interface/device-provisioning/creating-entities/README.md)
|
||||
* [Configurations](sdk/user-interface/device-provisioning/creating-entities/configurations/README.md)
|
||||
* [Metrics Settings Example](sdk/user-interface/device-provisioning/creating-entities/configurations/metrics-settings-example.md)
|
||||
* [Creating Venues](sdk/user-interface/device-provisioning/creating-venues/README.md)
|
||||
* [Configurations](sdk/user-interface/device-provisioning/creating-venues/configurations/README.md)
|
||||
* [WAN](sdk/user-interface/device-provisioning/creating-venues/configurations/wan.md)
|
||||
* [VAP - SSID](sdk/user-interface/device-provisioning/creating-venues/configurations/vap-ssid.md)
|
||||
* [Firmware Management](sdk/user-interface/firmware.md)
|
||||
* [Device Provisioning](sdk/user-interface/device-provisioning.md)
|
||||
* [Gateway](sdk/user-interface/gateway.md)
|
||||
* [Devices](sdk/user-interface/devices-view/README.md)
|
||||
* [Commands](sdk/user-interface/devices-view/commands.md)
|
||||
* [Statistics](sdk/user-interface/devices-view/statistics.md)
|
||||
|
||||
@@ -2,64 +2,76 @@
|
||||
description: OpenWiFi 2.0
|
||||
---
|
||||
|
||||
# User Interface
|
||||
# User Interface for Admins
|
||||
|
||||
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 user interfaces (UI) are designed as a Single-Page Application (SPA). \
|
||||
The UI serves as an example user interface built using React to demonstrate several interactions using the northbound OpenAPI. \
|
||||
Release 2.0 to 2.5 had a first generation of the UI framework. This first generation UI framework is seen for the Gateway and Firmware service. With the introduction of 2.6 and the Provisioning and Analytics services, a new UI for those specific SDK services has been introduced. 
|
||||
|
||||
## Login to OpenWiFi SDK
|
||||
All UI interactions consume the OpenAPI of the SDK services. 
|
||||
|
||||

|
||||
The following describes the likely starting point for an Administrator. Using the Provisioning service to define how the Wi-Fi networks in Entity, Venue and device provisioning terms may optionally be defined. 
|
||||
|
||||
## Login to OpenWiFi SDK - Provisioning
|
||||
|
||||
|
||||
|
||||

|
||||
|
||||
Default username is: **`tip@ucentral.com`** and password is: **`openwifi`**
|
||||
|
||||
On first login, the default user account will prompt to change password. This behavior is also available for all admin defined accounts added to the system. 
|
||||
|
||||
## **Base Navigation**
|
||||
|
||||
A left side navigation menu provides direction to major feature or service settings.
|
||||
On initial login the Provisioning service places the user on the Inventory screen. 
|
||||
|
||||

|
||||

|
||||
|
||||
## Internationalization
|
||||
Inventory enables the admin to visually identify OpenWiFi devices not currently assigned to an Entity, Create a new device, execute commands per device, inspect device details and view the device active state as shown in the Gateway service. 
|
||||
|
||||
OpenWiFi 2.0 SDK supports multiple languages. Simply select the desired language from the right drop down for pages to re-populate accordingly.
|
||||
#### Device Actions
|
||||
|
||||

|
||||

|
||||
|
||||
## Devices
|
||||
|
||||
Upon login the first page presented is a Devices table. This table reflects all discovered and managed devices known by the OpenWiFi SDK.
|
||||
|
||||

|
||||
#### View Details
|
||||
|
||||
Devices table indicates device Connected or Disconnected state in the first column with green and red respectively.
|
||||

|
||||
|
||||
Certificate column indicates invalid, valid with mismatch serial, or valid device certificate identity state as red crossed seal, yellow seal and green seal respectively.
|
||||
Within Device Details, found via the magnifying glass per Inventory row, association to an Entity Parent is possible. Additionally setting the device Firmware policy to inherit the rule assigned based on its membership to a Parent and to require Release Candidates or permit any nightly build upgrade to apply. Additionally the device may be enrolled within RRM should its Entity and Venue membership be part of RRM processing. Device Class determines if the device should be restricted to an Entity, Venue, and an end Subscriber. 
|
||||
|
||||
Serial Number column links to the device record.
|
||||
Device-Specific Configuration will expose any overriding configuration data present for this specific device. Device specific configuration will override inherited configurations from lower priority templates. 
|
||||
|
||||
Compatible model, Tx, Rx, and connected IP Address present basic information of the device type and its connection.
|
||||
Computed Configuration will display the enumeration of all provisioned templates the device is associated with. These templates are inherited as a result of device membership within an Entity, Child Entity, Venue and or Child Venue from which configuration templates may have been defined based on the admin deployment. 
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
### Bulk Inventory API
|
||||
|
||||

|
||||
The service API could be used to bulk load record formats in a common .csv structure using JSON. For example
|
||||
|
||||
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.
|
||||
"SerialNumber",Name,Description,DeviceType,NoteText for example: d1300f7b0732,Manufacturer,Desc, edgecore\_spw2ac1200,OutdoorAP
|
||||
|
||||

|
||||
\`\`\`
|
||||
|
||||
Associations have RSSI, Rx Rate & Bytes, Tx Rate & Bytes, MCS negotiated, Number Spatial Streams and IP Address information.
|
||||
For each inventory record, the \`\`\`deviceType\`\`\` must match a valid OpenWiFi device type. For example:
|
||||
|
||||
## 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.
|
||||
"deviceTypes": \[ "cig\_wf160d", "cig\_wf188", "cig\_wf194c", "edgecore\_eap101", "edgecore\_eap102",
|
||||
|
||||

|
||||
"edgecore\_ecs4100-12ph", "edgecore\_ecw5211",
|
||||
|
||||
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.
|
||||
> ...]
|
||||
|
||||

|
||||
\`\`\`
|
||||
|
||||
When inventory is assigned to a Venue, it can be allocated into a top-level parent such as the operator. Then, based on role access, operation's teams may choose to assign the device to a child entity within an operating division, or setup the device as a tenant of a managed Wi-Fi service for example.
|
||||
|
||||
Choosing to assign the device to a specific MDU location as an example can be done in one step from above.
|
||||
|
||||
##
|
||||
|
||||
24
sdk/user-interface/device-provisioning/README.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Provisioning
|
||||
|
||||
The OpenWiFi solution can be applied to a diverse number of use cases from enterprise networks, service provider access, and hotspots. OpenWiFi offers a variety of managed services from small to very large venues of roaming, client shared-key management, client steering, mobile offload, QoS-based services, and Layer 2 and Layer 3 breakout and overlay options. 
|
||||
|
||||
The Provisioning service provides a view into the network as a whole, and venues with entity-based control.
|
||||
|
||||
The provisioning service for OpenWiFi supports weighted order inheritance of configuration templates. These services and networks provide the greatest level of flexibility.
|
||||
|
||||
The system functions from a starting point of managed inventory assigned into entities, venues and optionally end subscribers. From this association, inheritance of entity, venue and subscriber configuration becomes possible where one to many configurations are processed including one to one when an inventory device such as a P2P link or Subscriber Gateway have unique operating data.
|
||||
|
||||
These features are present from the service over the web interface as well as via API for controller integration and OSS/BSS integration purposes.
|
||||
|
||||
With template inheritance, the aggregate of all inherited templates in the device association to Entity, Child, Venue, Child, Device Specific is possible. Overlapping configuration is controlled by the inherited template weight.  
|
||||
|
||||
### Entities
|
||||
|
||||
Initial deployment of the Provisioning service will have an empty Entities tree. The Top Entity may be used for a number of actions or simply as a description for structure below this level. 
|
||||
|
||||

|
||||
|
||||
For example, an operator may choose to simply rename this Top Entity as "Operator Name" and set Firmware Upgrade and RRM policies to no actions accordingly. Creating child entities from this point defining perhaps an operational break down such as divisions within the operator, within which setting Firmware and or RRM rules may apply per division is possible. 
|
||||
|
||||

|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
# Creating Entities
|
||||
|
||||
Entities represent a collection of resources for which certain business logic rules apply. 
|
||||
|
||||
Entities may hold: 
|
||||
|
||||
| Members of Entity | Description |
|
||||
| ----------------- | -------------------------------------------------------------------------- |
|
||||
| Entity | A child entity |
|
||||
| Venue | A logical aggregation of devices, configurations, locations with Analytics |
|
||||
| Configuration | Provisioning templates |
|
||||
| Inventory | Device members |
|
||||
| Locations | Device locations |
|
||||
| Contacts | Administrative contact information |
|
||||
| Resources | Global common resources such as RADIUS services |
|
||||
|
||||
@@ -0,0 +1,103 @@
|
||||
# Configurations
|
||||
|
||||
Device provisioning occurs based on inventory association to configuration templates.
|
||||
|
||||
Creating a template begins with the Configurations tab and creating a new template. 
|
||||
|
||||

|
||||
|
||||
### Create
|
||||
|
||||
Create Configuration dialog requires a name and one or multiple device types to apply configuration with. If device inventory within an Entity or a Venue exist with no configuration templates matching Device Types of the associated inventory, no associated provisioning will apply to those devices. This is the basic logic that enables unique Wi-Fi device type configurations to be layered through the system. 
|
||||
|
||||
###  
|
||||
|
||||

|
||||
|
||||
Limiting the configuration to a subset of device types is done through selection of available Device Types via pull down menu. 
|
||||
|
||||

|
||||
|
||||
A possible scenario may be that at such a top level, the operator wishes to set transmit power, MIMO operation where the Wi-Fi 6 2x2 top level configuration is defined. 
|
||||
|
||||
To include configuration parameters, select Add Subsection and choose the appropriate values. 
|
||||
|
||||

|
||||
|
||||
In this example we will choose Radios and define the MIMO and Tx Power. 
|
||||
|
||||

|
||||
|
||||
Begin with describing the Radio operating mode, assign a weight that may be either low enough to be overridden by further entity or venues or high enough to not be overridden, then Add Radio. 
|
||||
|
||||
|
||||
|
||||

|
||||
|
||||
OpenWiFi supports all possible Wi-Fi radio bands. Select the desired radio(s) and continue. 
|
||||
|
||||
#### Radio General
|
||||
|
||||

|
||||
|
||||
General properties, the following may be configured:
|
||||
|
||||
| Option | Description |
|
||||
| --------------- | ------------------------------------ |
|
||||
| Band | Frequency Band |
|
||||
| Bandwidth | 5,10,20 MHz channel narrow operation |
|
||||
| Country | Operating Country aka Country Code |
|
||||
| Channel-Mode | Operating Mode HT, VHT, HE |
|
||||
| Channel-Width | Total channel bandwidth |
|
||||
| Channel | Operating channel frequency |
|
||||
| MIMO | Values of 1x1 - 8x8 |
|
||||
| TX-Power | Transmission power in dBm |
|
||||
| Legacy-Rates | Allow 802.11b rates |
|
||||
| Maximum-Clients | Total UEs Permitted |
|
||||
| Multiple-BSSID | Multiple BSSID IE advertisment |
|
||||
|
||||
#### Radio Advanced 
|
||||
|
||||

|
||||
|
||||
Advanced Settings, the following may be configured:
|
||||
|
||||
| | |
|
||||
| ----------------- | --------------------------------------------------------------------------------------------------------------------- |
|
||||
| Beacon-Rate | Value 1-54Mb/s Beacon Frame Rate |
|
||||
| Beacon-Interval | Interval of Beacon Frames in ms |
|
||||
| DTIM-Period | Value 1-255 Delivery Traffic Information Message |
|
||||
| Hostapd-iface-raw | Directly configure hostapd parameters not part of OpenWiFi data model |
|
||||
| Multicast | Multicast frame rate in Mb/s |
|
||||
| EMA | Multi-BSSID broadcast using EMA |
|
||||
| BSS-Color | BSS Coloring 0-disable, 1-63 manual, 64 random |
|
||||
| Require-Mode | Minimum 802.11 UE standard permitted to associate. None - disabled, HT - a,b,g,n, VHT - a,b,g,n,ac, HE- a,b,g,n,ac,ax |
|
||||
|
||||
|
||||
|
||||
When complete, Save the "Top Level Wi-Fi 6 2x2" configuration for the device types chosen that align to such a radio mode. 
|
||||
|
||||
### Inheriting Advanced Radio Configuration
|
||||
|
||||
For purpose of demonstration, if the admin were to create another Configuration template with the same weight as the previous template defining the Advanced parameters, these could then be broken down for example by device type. 
|
||||
|
||||
Create another template as described for only one of the Wi-Fi 6 2x2 APs we have shown thus far. 
|
||||
|
||||

|
||||
|
||||
Setting specific configuration for the EAP 101 advanced radio parameters. For example, if a device in this entity is an EAP 101, it will have advanced radio properties of 12Mb/s beacon rate, 24Mb/s multicast rate, random BSS color and require HE mode. 
|
||||
|
||||

|
||||
|
||||
With these settings saved, multiple configuration templates are now shown that will influence radio operating parameters equally yet separately based on device type. 
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
# Metrics Settings Example
|
||||
|
||||
A common example is to inherit the desired telemetry for all devices spanning all types, at a top level. 
|
||||
|
||||
It remains possible to override the values shown here, perhaps to a faster interval, for the required telemetry data defined at the top level. 
|
||||
|
||||
|
||||
|
||||
### Create Configuration
|
||||
|
||||
Create a general configuration, select Metrics as the Configuration Section. 
|
||||
|
||||

|
||||
|
||||
Within the Subsections select all metrics types to be included and a weight for this template.
|
||||
|
||||
Available metrics:
|
||||
|
||||
| Metric | Description |
|
||||
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| WiFi Frames | Select Management Frame reports to send. Values include: Probe, Auth, Assoc, DeAuth, Disassoc, Local-Deauth, Inactive-Deauth, Key-Mismatch, Beacon-Report, Radar-Detected |
|
||||
| Statistics | Set Interval of all Statistics and types including: SSID, LLDP, Clients |
|
||||
| DHCP Snooping | Select the DHCP & DHCPv6 frames to send in telemetry including: ACK, DISCOVER, OFFER, REQUEST, REPLY, RENEW, SOLICIT |
|
||||
| Health | Interval to send automated health check score |
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
 
|
||||
|
||||
|
||||
|
||||
 
|
||||
@@ -0,0 +1,34 @@
|
||||
# Creating Venues
|
||||
|
||||
Venues are an important concept in OpenWIFi Provisioning. Venues inherit access to Analytics where incoming telemetry and client events are aggregated from the message bus, transformed and correlated based on the members of the Venue resulting in Venues Dashboard, Live Client quality connection analysis, and client tracking through the venue.
|
||||
|
||||
{% hint style="info" %}
|
||||
Venues may not exist beneath the root entity. Create an entity prior to defining a venue
|
||||
{% endhint %}
|
||||
|
||||
###  Create a Venue
|
||||
|
||||
Within a non-root entity, Create a Venue. 
|
||||
|
||||

|
||||
|
||||
Once the Venue exists, navigate into the Venue.
|
||||
|
||||
### Venue Configurations
|
||||
|
||||
Within a Venue, the RRM and Firmware management rules may be defined. Note Analytics are now an available option within the Venue. To track device and client statistics, enable Analytics.
|
||||
|
||||

|
||||
|
||||
Choose Edit and Start Monitoring. This will enable the admin to determine the interval of analytic data aggregation, and the data retention window in days. 
|
||||
|
||||

|
||||
|
||||
When Analytics are enabled, the Dashboard is populated. As devices are associated to the Venue, their telemetry data is aggregated by Analytics service and correlated for display via Dashboard, Live View and Client Lifecycle.
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
# Configurations
|
||||
|
||||
Within the example Venue, creating configuration templates for SSIDs and or other configuration sections are possible. These configurations are inherited by device memberships at the Venue level. 
|
||||
|
||||
It is therefore possible to define many Venues, Child Venues, and Inventory associations that will then inherit global templates from entities in addition to aggregation of Venue templates. 
|
||||
|
||||
@@ -0,0 +1,41 @@
|
||||
# VAP - SSID
|
||||
|
||||
An SSID may be associated to any defined interface. This association ties the dataplane of the VAP together with the underlying interface services. 
|
||||
|
||||
Most common SSID configuration parameters have been exposed via the Provisioning UI. Consult the OpenWiFi data model for the full list of available configurations. 
|
||||
|
||||
From an interface select Add SSID.
|
||||
|
||||

|
||||
|
||||
Assigning the name of the SSID is also the name of the Wi-Fi network itself. Operating band of the SSID is configurable by radio. 
|
||||
|
||||
#### SSID Configuration Options
|
||||
|
||||
| Option | Description |
|
||||
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Name | SSID name |
|
||||
| BSS-Mode | <p>Operating mode of the wireless interface<br>Options: ap, sta, mesh, wds-ap, wds-sta</p> |
|
||||
| WiFi-Bands | Radio selection(s) of the SSID |
|
||||
| Authentication Protocol | <p>Wireless encryption of the BSS<br>Options: None, WPA-PSK, WPA2-PSK, PSK2-RADIUS, WPA-PSK/WPA2-PSK Personal Mixed, WPA-Enterprise, WPA2-Enterprise EAP-TLS, WPA-Enterprise-Mixed, SAE, WPA2/WPA3 Transitional, WPA3-Enterprise EAP-TLS, WPA3-192-Enterprise EAP-TLS</p> |
|
||||
| Authentication Key | Pre-Share dKey (when applicable) |
|
||||
| Authentication IEEE80211w | <p>Management Frame Protection <br>Options: disabled, optional, required</p> |
|
||||
| Advanced | |
|
||||
| Hidden-SSID | Disable Beacon Frame Broadcast |
|
||||
| Services | Services associated to the SSID logical interface |
|
||||
| Maximum-Clients | Total associations permitted to the SSID |
|
||||
| Purpose | <p>Role the SSID performs<br>Options: Default, Onboarding-AP, Onboarding-sta</p> |
|
||||
| Isolate-Clients | BSS client isolation |
|
||||
| Power-Save | Unscheduled Automatic Power Save Delivery |
|
||||
| Broadcast-Time | Beacon Time Broadcast |
|
||||
| Unicast-Conversion | Convert Multicast to Unicast over BSS |
|
||||
| Proxy-ARP | BSS respond to host ARP on behalf of another client |
|
||||
| Disassoc-Low-Ack | Disassociate stations based on excessive transmission failures or other indications of connection loss |
|
||||
| Vendor-Elements | This option allows embedding custom vendor specific IEs inside the beacons of a BSS in AP mode. |
|
||||
| Multi-PSK | Per device shared key to associate with unique VLAN |
|
||||
| Rate Limit | Ingress-rate and Egress-rate in Mb/s |
|
||||
| RRM | <p>Neighbor reporting<br>LCI measurement element content<br>Civic-Location element content<br>FTM-Responder Fine Timing Measurement<br>Stationary-AP</p> |
|
||||
| Roaming | <p>Message-Exchange <br>Generate PSK<br>Domain-Identifier<br>PMK-R0-Key-Holder<br>PMK-R1-Key-Holder</p> |
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
# WAN
|
||||
|
||||
Configure WAN interface as an upstream interface role type. 
|
||||
|
||||
OpenWiFi has the concept of a virtual dataplane where the definition of the interface role as upstream or downstream defines if the port involved will be mapped to WAN or LAN operation. 
|
||||
|
||||
It is possible to re-map any LAN port to function as a normal WAN port in this way. 
|
||||
|
||||

|
||||
|
||||
When the above Interfaces configuration section is created, respond to the dialog prompt to define an upstream WAN then select from the available configuration options to suit the local environment.
|
||||
|
||||

|
||||
|
||||
Within WAN(upstream) select the port(s) for use as WAN. 
|
||||
|
||||
A variety of Services features may be associated to logical interfaces. For this example, enable LLDP. 
|
||||
|
||||
IP Addressing set as IPv4 Dynamic will cause the WAN port to use DHCP for its provisioned internet access. IPv6 dual stack is also supported. 
|
||||
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Device Provisioning
|
||||
# Gateway
|
||||
|
||||

|
||||
|
||||