OpenWiFi supports Zero Touch Provisioning in a number of ways.

• Zero Touch Mesh

• Zero Touch WDS

• Zero Touch Provisioning ( Provisioning Services in upcoming 2.5/2.6 Release )

Onboarding

OpenWiFi makes use of TIP device certificates present on every access point as a secure identity from which to automate a number of Zero Touch operations.

Onboarding is a local EAP-TLS based authentication service available on any OpenWiFi device that works together with default OpenWiFi firstboot behavior to scan for "OpenWifi-onboarding" SSID, associate to that SSID, when challenged supply TIP root signed device certificate.

Onboarding Steps

1. Provision an Access Point for onboarding role as an SSID config { "purpose": "onboarding-ap", "bss-mode": "ap", "encryption": { "proto": "wpa2", "ieee80211w": "required" }, "certificates": { "use_local_certificates": true }, "radius": { "local": { "server-identity": "uCentral-EAP" } }, "name": "OpenWifi-onboarding", "wifi-bands": [ "2G" ] }

2. Ensure the SSID for onboarding use provides network connectivity for clients

   • Any topology such as NAT, Bridge, VLAN may be used

   • Any radio(s) may be used

3. Firstboot devices with no WAN wired port detected will

   • Enable all radios

   • Scan for SSID "OpenWifi-onboarding"

   • Associate and when challenged use TIP certificate as identity

   • Obtain IP connection using DHCP over wireless interface association to onboarding AP

   • Connect to SDK, obtain provisioning from OpenWiFi Gateway service

   • Reload configuration

Zero Touch Mesh

Deployment of Mesh may have multiple Mesh Client access points with no wired connectivity. These devices use IEEE802.11s Mesh participating interface(s) as transit for WAN / LAN connections.

In a Zero Touch Mesh deployment, the Gateway Access Point, sometimes termed the Root node, advertises mesh participating interfaces when "bss-mode": "mesh" is applied to an SSID. Please see Mesh for further details on initial setup.

Mesh Client Access Points needing to associate wirelessly for initial provisioning to join the mesh network, may be served using the onboarding feature of OpenWiFi.

Adding an SSID to the Mesh Gateway Access Point configuration to advertise "OpenWifi-onboarding" enables initial boot of any OpenWiFi Access Point to reach the OpenWiFi Gateway.

Upon connection to Onboarding, the Access Point obtains management network access from the upstream Access Point providing "onboarding-ap" service.

With management network access, reachability for the Mesh Client Access Point to the OpenWiFi Gateway should be possible, device provisioning stage will initiate with the production configuration being loaded to the client device.

Once processed, client Access Point will have receive provisioning to join the Mesh network as a Mesh Client Access Point.

Zero Touch WDS

Deployment of WDS links may have multiple WDS client devices with no wired WAN connectivity. WDS Access Points use the 4-tuple frame header with participating WDS Clients. Therefore WDS Clients must first receive provisioning from the OpenWiFi Gateway for their production state as a WDS link participant.

WDS Client Access Points needing to associate wirelessly for initial provisioning to join the WDS network, may be served using the onboarding feature of OpenWiFi from the WDS Root Access Point at the top of the topology with a "bss-mode": "ap" SSID for onboarding.

Adding an SSID to the WDS Root Access Point configuration to advertise "OpenWifi-onboarding" enables initial boot of any OpenWiFi Access Point to reach the OpenWiFi Gateway.

Upon connection to Onboarding, the WDS Client Access Point obtains management network access from the upstream WDS Root Access Point providing "onboarding-ap" service.

With management network access, reachability for the WDS Client Access Point to the OpenWiFi Gateway should be possible, device provisioning stage will initiate with the production configuration being loaded to the client device. For more information on WDS configuration please consult WDS.

Once processed, WDS Client Access Point will have receive provisioning to join the WDS link as a Client WDS node.

OpenWiFi devices have a number of features that may be configured.

The following pages guide the user to understanding each of these features individually including example configuration information.

When operators of enterprise or service provider networks seek to influence or control the allocation of dynamically assigned IP address, typically the network edge has been provisioned to encode information in DHCP Relay packets that help identify the access device through which a subscriber is attached, the logical sub-interface of that network edge or the subscriber directly.

TIP OpenWiFi supports DHCP Relay with encoding of client Circuit-Id information containing any of:

• Interface

• VLAN-Id

• SSID

• Encryption Mode

• Device Name

• Device Model

• Device Location

• Access Point MAC Address

• Access Point MAC in Hex

• Client MAC Address

• Client MAC Address in Hex

TIP OpenWiFi Relay-Agent remote-id may be configured to contain any of the following:

• VLAN-Id

• SSID

• AP-MAC

• AP-MAC-Hex

• Client MAC

• Client MAC Hex

The remote-id originates from a configured IPv4 interface address.

		{
			"name": "LAN",
			"role": "downstream",
			"services": [ "ssh", "lldp" ],
			"ethernet": [
				{
					"select-ports": [
						"LAN*"
					]
				}
			],
			"ipv4": {
				"addressing": "static",
				"subnet": "192.168.1.1/24",
				"dhcp": {
					"relay-server" : "192.168.100.20",
					"circuit-id-format": "{Interface}:{SSID}:{AP-MAC}:{Location}",
					"remote-id-format": "{AP-MAC}:{SSID}"
				}
			}
		}
	]

In the above example, when the IPv4 downstream interface 192.168.1.1 has DHCP enabled for relay-server a DHCP relay process associates to the IP interface of the subnet. When DHCP DISCOVER packets arrive as broadcasts, they will be copied to a unicast packet from the 192.168.1.1 interface as the relay-id source address and unicast forwarded to the defined relay-server address. Additional parameters are encoded for inspection at the DHCP server as present in circuit-id-format and remote-id-format options.

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

Secure shell may optionally be enabled on OpenWiFi devices, associated to specific interface(s), and optionally support operator defined keys or password authentication.

    "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

        {
            "name": "LAN",
            "role": "downstream",
            "services": [ "ssh" ],
            "ethernet": [
                {
                    "select-ports": [
                        "LAN*"
                    ]
                }
            ],

Operator Key Management

For production deployments, it is recommended to assign operator SSH key from the OpenWiFi Provisioning configuration of the Venue or Entity which the device associates.

In this way, an operator may ensure their standard SSH key is delivered to all devices on a network operating region basis. All keys remain base64 encoded when added to the device.

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.

    "services": {
        "ntp": {
            "servers": [
            "0.openwrt.pool.ntp.org",
            "1.openwrt.pool.ntp.org"
            ]
        }
    }

Associate to an Interface

        {
            "name": "WAN",
            "role": "downstream",
            "services": [ "ntp" ],
            "ethernet": [
                {
                    "select-ports": [
                        "WAN*"
                    ]
                }
            ],
            "ipv4": {
                "addressing": "dynamic"
            }
    },

LLDP

Link Layer Discovery Protocol describes interfaces and capabilities between directly attached neighbors over Layer 2.

        "lldp": {
            "describe": "OpenWiFi",
            "location": "Stadium Level 2"
        },

Associate "lldp" as a services attribute to any interface.

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).

        "mdns": {
            "enable": true
        },

Associate "mdns" as a services attribute to any interface.

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.

        "log": {
            "host": "Syslog Server IP",
            "port": 514,
            "proto": "udp"
        },

Associate "log" as a services attribute to appropriate interface.

IGMP

When enabled the OpenWiFi device will process IGMP Proxy.

        "igmp": {
            "enable": true
        },

Associate "igmp" as a services attribute to any interface participating in IGMP Proxy.

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.

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.

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

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.

    "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"
            }
        },

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".

The logical wireless interface(s) to participate in mesh topology are defined by their bss-mode set to "mesh".

    "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"
                    }
                },
                {
                    "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"
                        }                    

                    }
            ]
        },

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.

At home, in a cafe, or on the go, Express Wi-Fi gives you access to fast, affordable, and reliable internet so you can make connections that matter.

Express Wi-Fi partners with service providers to deliver great wi-fi to people when and where it's needed.

For information about becoming an expressWIFI partner please visit their site.

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.

    "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"
                }
            },
            "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 ",
            "mode": "specific mode pssl, ptcp, ssl, tcp"
            "ca-certificate": " the client cert as Base64 here ",
            "ssl-certificate": "the shared ca as Base64 here",
            "private-key": "client key as Base64 here" 
        }
    }

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.

Steering

OpenWiFi services feature "wifi-steering" determines the operating parameters of RRM on the Access Point.

    "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
        },

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.

Apply Wi-Fi Steering to enable 802.11r Fast Roaming SSIDs

            "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" ]
                }
            ]
        },

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.

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.

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

To enable 80211k parameters, associate these on a participating SSID basis.

            "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" ]
                }
            ]
        },

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

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.

    "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
        },

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

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".

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.

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.

For example, to send all content of a specific SSID over an GRE tunnel, the following configuration would apply.

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. Optionally the GRE tunnel itself may also carry a VLAN encapsulated payload. In the above example a WAN presentation of VLAN interface 20 has GRE tunnel. Within the GRE tunnel on WAN interface of VLAN 20 is a GRE payload with VLAN 30 in the payload header.

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.

    "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

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:

• Tunnel-Type = 13

• Tunnel-Medium-Type = 6

• Tunnel-Private-Group-Id = VLAN Id Number

Upon return of an access-accept from RADIUS, based on any method chosen for security, OpenWiFi will dynamically create a VLAN Id as described in Tunnel-Private-Group-Id, associated to the interface role, in this example upstream.

Metrics

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.

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.

    "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.

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.

        {
            "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"
                }
            }
        }
    ],

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.

For example, to send all content of a specific SSID over an L2TP tunnel, the following configuration would apply.

        {
            "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"
                }
            ]
        }
    ],

Passpoint® requires ANQP to supply three information elements from the Access Point.

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

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

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.

When authenticating clients with back office RADIUS systems, the configuration of OpenWiFi permits this on a per SSID basis.

    "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"
                        }
                    }
                }
            ]
        },

            "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"
                                }
                            ]
                        }
                    }
                }
            ]
        },

Many parameters are possible with RADIUS authentications given the many methods in use worldwide. Many of the EAP methods have configuration options described below.

When an external access controller, such as a captive portal appliance or a Universal Access Method (UAM) redirector is required to handle subscriber login, OpenWiFi optionally supports builds that include use of CoovaChili. This would be found in build profile chilli-redirect.yml.

To configure a CoovaChilli service, OpenWiFi supports the "third-party" schema definition.

Through the use of third-party, many configurations are possible, for external captive portal, third-party will process a services lookup of "chilli-redirect" applied to an interface.

Within "third-party" will be the necessary CoovaChilli configuration parameters.

NAT Mode

Associate to an interface:

Bridge Mode

In the above example, captive portal redirection occurs via a NAT interface on LAN side or "downstream" role.

When a direct to WAN presentation, or bridge mode operation is desired, associate the service to the "upstream" interface.

Associate to an interface:

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.

            "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"
                            "vlan-id": 200
                        }
                    ],
                    "roaming": {
                        "message-exchange": "ds",
                        "generate-psk": true
                    }
                }
            ]

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:

• Mobile data offload

• Wi-Fi networks for

  • Hospitality, venues and enterprise

  • Streamlined, enterprise-class device provisioning and credential management for enterprise and other private networks

• Wi-Fi–based services such as Wi-Fi calling, and collaboration tools

• Wi-Fi roaming agreements across carriers and service providers

• Opportunities to engage users and extract additional value from the network

Passpoint® is already supported by most enterprise-class APs on the market today, and natively supported by major mobile operating systems including Android, iOS, macOS, and Windows 10. With active support from a wide ecosystem of device manufacturers, mobile operators, and service providers, Passpoint® benefits both users and Wi-Fi network providers

Configuring port speed and operation is most commonly done with PoE access switches however the same configurations are possible for all OpenWiFi device types.

By default all ports attempt 1,000 Mb/s full duplex operation.

 "ethernet": [
            {
                    "select-ports": [
                            "WAN1"
                    ],
                    "speed": 100,
                    "duplex": "half"
            },
            {
                    "select-ports": [
                            "WAN2"
                    ],
                    "speed": 1000,
                    "duplex": "full"
            },
            {
                    "select-ports": [
                            "WAN3"
                    ],
                    "speed": 100,
                    "duplex": "half"
            }
    ],

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.

    "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
                    }
                }
            ],            
            "ipv4": {
                "addressing": "static",
                "subnet": "192.168.10.1/24",
                "dhcp": {
                    "lease-first": 10,
                    "lease-count": 100,
                    "lease-time": "6h"
                }
            }
        }
    ],

    "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
                    }
                }
            ],
    }

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.

Dynamic Air-Time Policy is a service to influence underlying co-ordination function of the Wi-Fi MAC domain per associated UE in terms of priority to use the air interface.

It is possible to govern certain application use cases such as streaming media or real time communications based on the resolution of those services through DNS.

This results in the UE, by its IP address having matched a specific fully qualified domain name or a wildcard therein, to having its air-time weighted priority to the value set in the weight parameter.

            "services": {     
                "airtime-policies": {
                    "dns-match": ["*.example.com", "host.example2.com" ],
                    "dns-weight": 256
                }
            }

Possible Uses

Any application a user may commonly use the OpenWiFi administrator seeks to prioritize air-time for may be triggered via the airtime-policies.

For example:

Any number of services may interest the administrator for airtime-policies. Simply determine the FQDN or wildcard FQDN applicable and update the OpenWiFi device configuration.

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.

TIP OpenWiFi enables operators to deploy the full range of Passpoint® and OpenRoaming solutions.

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:

• venue-name

• venue-group

• venue-type

• venue-url

• auth-type

• domain-name

• nai-realm

• osen

• anqp-domain

• anqp-3gpp-cell-net

• firendly-name

• icons

TIP OpenWiFi use of the OpenWrt operating system combined with new virtual data plane present in all images for 2.0 major release and the uCentral data model make it possible to include PoE access switching as a cloud managed component of the OpenWiFi stack.

Nightly builds include supported switch platforms.

Currently the list of features for switching include:

• IEEE 802.1Q VLAN

  • Port based Untagged

  • Tagged trunk

• IEEE 802.1ad Q-inQ

• VxLAN

• PoE Auto Power

• Port Mirroring / Monitor

• Link Aggregation

• Link Layer Discovery Protocol

• Port Speed Control

Configuring a Switch

All ports needs to be specified for link negotiation to occur. In the below example, the "ethernet" section defines the physical port. The "interfaces" configuration will cause the physical port to negotiate. Effectively removal of a "select-ports" for a physical port in any or all "interfaces" is the equivalent of an interface in shutdown state.

    "ethernet": [
        {
            "select-ports": [
                    "WAN1"
            ],
            "speed": 1000,
            "duplex": "full"
        },
        {
            "select-ports": [
                    "WAN2"
            ],
            "speed": 1000,
            "duplex": "full"
        },
        {
            "select-ports": [
                    "WAN3"
            ],
            "speed": 1000,
            "duplex": "full"
        },
        {
            "select-ports": [
                    "WAN4"
            ],
            "speed": 1000,
            "duplex": "full"
        },
        {
            "select-ports": [
                    "WAN5"
            ],
            "speed": 1000,
            "duplex": "full"
        },       
        {
            "select-ports": [
                    "WAN6"
            ],
            "speed": 1000,
            "duplex": "full"
        },
        {
            "select-ports": [
                    "WAN7"
            ],
            "speed": 1000,
            "duplex": "full",
            "vlan-tag": "auto"
        },       
        {
            "select-ports": [
                    "WAN8"
            ],
            "speed": 1000,
            "duplex": "full",
            "vlan-tag": "auto"
        },       
        {
            "select-ports": [
                    "WAN9"
            ],
            "speed": 1000,
            "duplex": "full"
        },       
        {
            "select-ports": [
                    "WAN10"
            ],
            "speed": 1000,
            "duplex": "full"
        },       
        {
            "select-ports": [
                    "WAN11"
            ],
            "speed": 1000,
            "duplex": "full"
        },       
        {
            "select-ports": [
                    "WAN12"
            ],
            "speed": 1000,
            "duplex": "full"
        }                       
    ],

Without any "interfaces" defined, the ifconfig on the switch will return eth0, lan1, lo as an output. When adding "interfaces" additional ports become active and also visible.

   "interfaces": [
		{
        {
			"name": "VLAN-30-Ports",
			"role": "downstream",
			"services": [ "lldp" ],
            "vlan": {
                "id": 30,
                "proto": "802.1q"
            },
			"ethernet": [
				{
					"select-ports": [
						"WAN7", "WAN8"
					]
				}
			]
     }

Vlan-Id 30 has been assigned to interfaces 7 and 8 on the switch. Traffic is isolated among participating ports.

Ifconfig output example

# ifconfig
down1v30  Link encap:Ethernet  HWaddr 90:3C:B3:39:C0:C1  
          inet6 addr: fe80::923c:b3ff:fe39:c0c1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:79 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:22135 (21.6 KiB)  TX bytes:1036 (1.0 KiB)

eth0      Link encap:Ethernet  HWaddr 90:3C:B3:39:C0:C0  
          inet6 addr: fe80::923c:b3ff:fe39:c0c0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1504  Metric:1
          RX packets:31617 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7479 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4293282 (4.0 MiB)  TX bytes:1228185 (1.1 MiB)
          Interrupt:24 Memory:c000000-bb00a3ff 

lan1      Link encap:Ethernet  HWaddr 90:3C:B3:39:C0:C1  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:27321 errors:0 dropped:69 overruns:0 frame:0
          TX packets:5445 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2893034 (2.7 MiB)  TX bytes:825702 (806.3 KiB)

lan7      Link encap:Ethernet  HWaddr 90:3C:B3:39:C0:C7  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2204 errors:0 dropped:0 overruns:0 frame:0
          TX packets:507 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:421385 (411.5 KiB)  TX bytes:100251 (97.9 KiB)

lan8      Link encap:Ethernet  HWaddr 90:3C:B3:39:C0:C8  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1241 errors:0 dropped:0 overruns:0 frame:0
          TX packets:496 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:220496 (215.3 KiB)  TX bytes:98164 (95.8 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:958 errors:0 dropped:0 overruns:0 frame:0
          TX packets:958 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:76410 (74.6 KiB)  TX bytes:76410 (74.6 KiB)

up        Link encap:Ethernet  HWaddr 90:3C:B3:39:C0:C1  
          inet6 addr: fe80::923c:b3ff:fe39:c0c1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:27027 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4368 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3008700 (2.8 MiB)  TX bytes:587431 (573.6 KiB)

up0v0     Link encap:Ethernet  HWaddr 90:3C:B3:39:C0:C1  
          inet addr:10.75.0.154  Bcast:10.75.0.255  Mask:255.255.255.0
          inet6 addr: fe80::923c:b3ff:fe39:c0c1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:22673 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3865 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2390361 (2.2 MiB)  TX bytes:525377 (513.0 KiB)

Bridge Vlan Table Output

# bridge vlan
port              vlan-id  
lan1              4090 PVID Egress Untagged
lan7              30 PVID Egress Untagged
lan8              30 PVID Egress Untagged
up                30
                  4090
#

Assigning VLANs to Ports

To define additional VLAN memberships to any port, create additional "interfaces" configuration.

     {
			"name": "VLAN-30-Ports",
			"role": "upstream",
			"services": [ "lldp" ],
            "vlan": {
                "id": 30,
                "proto": "802.1q"
            },
			"ethernet": [
				{
					"select-ports": [
						"WAN7", "WAN8"
					]
				}
			]
        },
        {
			"name": "VLAN-40-Ports",
			"role": "upstream",
			"services": [ "lldp" ],
            "vlan": {
                "id": 40,
                "proto": "802.1q"
            },
			"ethernet": [
				{
					"select-ports": [
						"WAN7", "WAN8"
					]
				}
			]
     }

Ifconfig and Bridge Results

up1v30    Link encap:Ethernet  HWaddr 90:3C:B3:39:C0:C1  
          inet6 addr: fe80::923c:b3ff:fe39:c0c1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1178 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:245923 (240.1 KiB)  TX bytes:816 (816.0 B)

up2v40    Link encap:Ethernet  HWaddr 90:3C:B3:39:C0:C1  
          inet6 addr: fe80::923c:b3ff:fe39:c0c1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:106 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:34638 (33.8 KiB)  TX bytes:816 (816.0 B)


# bridge vlan
port              vlan-id  
lan1              4090 PVID Egress Untagged
lan7              30
                  40
lan8              30
                  40
up                30
                  40
                  4090