Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
TIP OpenWiFi 2.0
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.
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.
TIP OpenWiFi 2.0
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.
Secure shell may optionally be enabled on OpenWiFi devices, associated to specific interface(s), and optionally support operator defined keys or password authentication.
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.
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.
Link Layer Discovery Protocol describes interfaces and capabilities between directly attached neighbors over Layer 2.
Associate "lldp" as a services attribute to any interface.
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).
Associate "mdns" as a services attribute to any interface.
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.
Associate "log" as a services attribute to appropriate interface.
When enabled the OpenWiFi device will process IGMP Proxy.
Associate "igmp" as a services attribute to any interface participating in IGMP Proxy.
OpenWiFi 2.0
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 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.
OpenWiFi 2.0
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".
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.
TIP OpenWiFi 2.0
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.
Associate to an interface:
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:
TIP OpenWiFi 2.0
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.
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.
TIP OpenWiFi 2.0
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.
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.
TIP OpenWiFi 2.0
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.
TIP OpenWiFi 2.0
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
OpenWiFi 2.1
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
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.
Contact expressWiFi for appropriate CA, Client Cert, and Key for TLS Security mode in addition to the specific expressWiFi Controller FQDN. Ensure these values are Base64 encoded when passed into the configuration
TIP OpenWiFi 2.0
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.
TIP OpenWiFi 2.0
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.
TIP 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.
OpenWiFi services feature "wifi-steering" determines the operating parameters of RRM on 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.
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.
To enable 80211k parameters, associate these on a participating SSID basis.
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.
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.
TIP OpenWiFi 2.0
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.
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.
Parameter | Value |
mode: local | autonomous operation |
network: upstream | performs roaming among SSIDs on upstream interfaces |
assoc-steering | reject client association requests when the UE is subject to a steering event |
required-snr | minimum signal in dBm a client will be permitted to remain connected |
required-probe-snr | minimum signal level in dBm for management probes to be replied to |
required-roam-snr | minimum signal level in dBm client roaming threshold |
load-kick-threshold | minimum channel load as % available before clients are kicked |
TIP OpenWiFi 2.0
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 2.0
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.
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.
TIP OpenWiFi 2.0
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.
Note: M-PSK passwords must be unique per vlan-id as the device will attempt to match security key to assigned virtual lan. In the above example, a password of OpenWifi will match the untagged interface of the SSID and unique password of "akey" will match client(s) to virtual lan 100.
TIP OpenWiFi 2.0
Switching Features Remain Under Test
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
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.
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.
Vlan-Id 30 has been assigned to interfaces 7 and 8 on the switch. Traffic is isolated among participating ports.
To define additional VLAN memberships to any port, create additional "interfaces" configuration.
TIP OpenWiFi 2.0
Content coming soon...
OpenWiFi 2.1
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.
TIP OpenWiFi 2.0
Passpoint® requires ANQP to supply three information elements from the Access Point.
Public Land Mobile Network Id is defined by 3GPP and comprised of two, three digit numbers to uniquely identify the Mobile Network Operator (MNO).
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.
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.
TIP OpenWiFi 2.0
When authenticating clients with back office RADIUS systems, the configuration of OpenWiFi permits this on a per SSID basis.
Many parameters are possible with RADIUS authentications given the many methods in use worldwide. Many of the EAP methods have configuration options described below.
TIP OpenWiFi 2.0
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.
TIP OpenWiFi 2.0
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.
Note: In release 2.1, airtime-policies must be applied to SSIDs in a NAT configuration. Bridge / VLAN mode SSIDs with airtime-policies will be updated in a future release
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.
RADIUS Attribute
Description
nas-identifier
Unique NAS Id used with RADIUS server
chargeable-user-id
Chargeable User Entity per RFC4372
local
Local RADIUS within AP device
server-identity
users - Local EAP users based on username, PreShared Key and VLAN id
authentication
RADIUS server
host IP address
port ( example 1812)
secret ( Shared secret with RADIUS server )
Additional methods within Access-Request
request-attribute ( id of RADIUS server )
id ( numeric value of RADIUS server )
value
Any sub-value defined as integer RADIUS attribute value
accounting
RADIUS server
host IP address
port ( example 1813)
secret ( Shared secret with RADIUS server )
Additional methods within Access-Request sent in Accounting
request-attribute ( id of RADIUS server )
id ( numeric value of RADIUS server )
value
Any sub-value defined as integer RADIUS attribute value
accounting
interval ( Interim accounting interval defined in seconds )
Term
Description
Operator
Wi-Fi Infrastructure Operator
Access Network Provider (ANP) as defined by OpenRoaming
Venue
Deployed location of Wi-Fi service
Identity Provider
Subscriber authenticating service provider
Home Service Provider (HSP) as defined by OpenRoaming
Roaming Exchange
Operator and Identity Provider Authentication, Authorization, Accounting
ANQP
Access Network Query Protocol contains:
Domain
Venue Name
Venue Info
Operator Friendly Name
IP Type
WAN Metric
Connection Capability
Operating Class
Authentication Type
Service Providers List
GAS
Generic Advertisement Layer 2 Service for client query
Client query returns:
Organization Identifier / Service Provider Identity
Domain
Authentication
Roaming Consortium List
Network Access Identifier Realm (NAI)
3GPP Network Data
OSU
Online Signup - Advertised over ANQP contains:
OSU SSID
OSU URI
OSU Method
OSU Available Icons
OSU ESS (OSEN) SSID
OSU Description
OSEN
OSU Server Authenticated Layer 2 Encryption Network
Service | FQDN / URL |
MS Teams | *.lync.com, *.teams.microsoft.com, teams.microsoft.com |
Zoom | *.zoom.us |