Device and Cloud Certificates

TIP OpenWiFi program ensures unique identity of all devices, encryption of traffic to and from the management cloud, discovery of management cloud, and ability to change device to cloud service discovery. TIP model ensures worldwide Zero Touch Provisioning, unique identity of all device and cloud conversation with no vendor lock in.

TIP device and cloud partners in OpenWiFi are uniquely managed members within a division of the Telecom Infra Project CA within DigiCert.

Device Onboarding

TIP ODM partners have the ability to generate signed certificates from the TIP Root Certificate Authority. This is done during manufacture for any TIP SKU product using signed certificates.

Each ODM partner will use the Manufacturer name, device MAC address, and optionally a value for Redirector and Model of device when requesting a new certificate.

The Redirector value is what determines cloud discovery and may be empty for example if the devices being manufactured do not yet have a cloud service provider assigned, for example a retail distribution model. Alternatively the value of the Redirector may be set at the same time as the certificate generation occurs.

TIP provides an automated script to perform the device certificate request.

Cloud Onboarding

TIP Cloud partners have the ability to generate signed certificates for the cloud SDK.

Similar to device onboarding, TIP provides a script to automate this process. For the cloud components the Operator name and a Fully Qualified Domain Name of the cloud are sent with each cloud key request. In addition, local configuration files are set in the request script to generate certificates matched to the operating name of certain services such as the opensync-controller and the mqtt-broker.

Cloud Discovery

Each device on initial startup or when factory reset will connect to the Certificate Authority using its unique device credentials requesting its current 'cloud' value. This functions both as cloud discovery as well as redirector in the event the device owner wishes to change the cloud or cloud service provider relationship with their device.

Configuration without Internet Connection

In certain situations, a connection to the cloud or the root authority may not be possible. When this occurs, each TIP OpenWiFi Access Point device on factory boot presents an initial configuration Wi-Fi Management SSID called 'Maverick'. Connecting to Maverick presents a web page where updating WAN interface settings and the fully qualified domain name of the cloud may be entered.

When the device is a PoE Ethernet switch, a local management interface exists where the same configuration of cloud and WAN are possible.

Cloud Providers

Current Release 1.x OpenWiFi cloud partners can accelerate your deployment of TIP OpenWiFi.

Open Wi-Fi Access Point Partners

TIP members may contact the ODM manufacturers in the TIP OpenWiFi eco-system using the information posted within Community Confluence page.

Consuming the stack is exciting, and up to you how to integrate into a complete solution. Accessing the source code is free: Github

Understanding how to consume the project needs membership with the Telecom Infra Project Open Converged Wireless group: Join OCW Group

There is no fee to join, once you are approved, access to Confluence, JIRA, Slack will all be included in addition to the ability to check in and contribute code to the project.

Initial Lab Setup

Deploying the TIP OpenWiFi solution into a lab or into production is simple to do. Some basic pre-requisites should be satisfied before beginning.

Ensure the following are known before beginning installation:

• Fully Qualified Domain Name (FQDN) is available and configurable

• Internet Protocol (IP) subnet with Dynamic Host Configuration Protocol (DHCP) for access points is available

• Internet Protocol (IP) subnet with static addressing is available for Cloud SDK

• If using VLAN features of the access points, an IEEE 802.1q compliant Ethernet switch and VLAN topology are supported in your network

• Network traffic is permitted for the following ports from Access Points to Cloud SDK:

  • 80

  • 443

  • 1883

  • 6640

  • 6643

Cloud Discovery

All TIP Open Wi-Fi devices implement discovery of the cloud SDK through a Zero Touch Provisioning design based on the unique signed certificate present on each device.

Each device contacts the Certificate Authority (CA) using its certificate credentials to lookup the current value of the cloud SDK.

Once the configured cloud is returned from CA to the device, a connection is created to the cloud SDK where provisioning of the device will occur.

For more information on cloud discovery, devices and obtaining keys please proceed to the next section.

For questions on how to obtain keys or support related to certificates please contact: licensekeys@telecominfraproject.com

There are two ways to get started with TIP OpenWiFi. For those interested in 'rolling their own' feel free to continue through the Cloud SDK Installation and related information to configure and consume the open source stack. Note you will need to join the TIP Open Converged Wireless PG for this.

Interested in getting started with a partner? Obtaining a TIP AP directly or via a partner is simple and these partners will help setup cloud trial environment with you.

OpenWiFi Cloud SDK may be deployed to both public and private cloud environments.

Helm charts support automated deployment of the Cloud SDK PODs and containers into AWS and MicroK8s Kubernetes platforms.

The following pages provide step-by-step instructions to deploy in public cloud (AWS) or private on-premises (MicroK8s) cloud.

Prerequisites

The following must be available to start this installation:

• AWS Account

• AWS Route 53 Hosted Zone

The steps outlined in this guide will create a local installation of the Terraform automation environment that will also depend on the AWS command line interface, Helm and Kubectl local command line packages.

Each of these applications provide detailed instructions for installation on multiple client operating systems.

• Install Kubectl https://kubernetes.io/docs/tasks/tools/install-kubectl/

• Install Helm https://helm.sh/docs/intro/install/

• Install AWS CLI https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html

• Install Terraform https://learn.hashicorp.com/tutorials/terraform/install-cli#install-terraform

Example Local Prerequisites Installation on MAC OS

If the instructions for Terraform were followed, a Docker container was locally created, nginx was run with a default localhost:80 nginx returned web page displayed. After which 'terraform destroy' was run to remove the local test of Terraform.

If the instructions for AWS CLI were followed, AWS CLI version 2 has been installed. This may be verified using the command which aws and aws --version. If these succeed installation of AWS CLI has completed.

If the instructions for Helm were followed, Helm has now been locally installed. This may be verified using the command which helm and helm version. If these succeed installation of Helm has completed.

If the instructions for Kubectl were followed, Kubectl has not been locally installed. This may be verified using the command which kubectl and kubectl version --client. If these succeed installation of Kubectl has completed.

Access to AWS should have been satisfied with an AWS account as noted in Prerequisites. This account is entitled with Administrator level permissions. For information on this process please refer to: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html

Controller Installation

Create a workspace on your local system and clone in the TIP Controller project.

git clone https://github.com/Telecominfraproject/wlan-cloud-helm/
### A merge of final AWS deployments is pending. 
### At this time, switch to the following branch
git checkout cloudsdk-aws-deployment
cd /terraform/aws-cloudsdk

Create a Terraform file in the aws-cloudsdk directory named aws.tfadding the following to that new file:

provider "aws" {
        region = "Replace with your preferred AWS region here"
}

If a specific authentication method previously exists depending on your local machine environment when connecting to AWS, adjustments may be required. Please consult Terraform instructions accordingly: https://registry.terraform.io/providers/hashicorp/aws/latest/docs#authentication

Initialize Terraform

Terraform will use the initial configuration of your environment variables from the previous step when communicating with AWS. Prior to initializing Terraform, ensure authentication is successful.

terraform init

### Several emitted lines will occur.
### When succesful the following will display:

Terraform has been successfully initialized!

Adjusting to AWS Environment

Within the /wlan-cloud-helm/terraform/aws-cloudsdk directory, copy the terraform.tfvars.sample file to terraform.tfvars and edit the content of the new terraform.tfvars replacing parameter values for cidr and route53_zone_name accordingly:

name = "cloudsdk"
cidr = "Enter a valid CIDR Range of your AWS VPC"
route53_zone_name = "Enter a valid Route53 Hosted-Zone"
subdomain = "cloudsdk"

Once these steps have been completed, it is now possible to deploy the TIP Controller to AWS.

terraform apply

If Terraform is able to connect and authenticate to AWS, a prompt to accept the creation of the deployment is presented. Answer yes to proceed. Terraform will execute for 10-15 minutes during which time the following are being configured:

• EKS cluster with three nodes where CloudSDK will run on

• VPC for the EKS cluster

• ACM that will sign the certificate for the public HTTPS services exposed by CloudSDK

• Route53 record to let ACM know that you own the domain

• external-dns that will take care of creating DNS entries for all CloudSDK components

• aws-load-balancer-controller which will take care of exposing CloudSDK components to the public

• Required IAM roles for all components

Terraform Results

When Terraform completes the following should have emitted:

Apply complete! Resources: 57 added, 0 changed, 0 destroyed.

Outputs:

acm_arn = "arn:aws:acm:ca-central-1:1xxxxxxx68:certificate/7e3xxxx7-74xx-4xxx-8bef-d6xxxxxx5a3"

Deploy TIP Controller

TIP Controller services use SSL certificates to ensure inter-service security. These certificates must be generated. To generate TIP Controller certificates, navigate out of the tip-wlan-cloud directory to a directory where cloning the TIP PKI repository may occur:

git clone https://github.com/Telecominfraproject/wlan-pki-cert-scripts.git

Enter the PKI directory and the configs sub-directory cd /wlan-pki-cert-scripts/configs

Modify all certificate configuration files for the value of your organizationalUnitName_default value set to your organizational name or other string value used in each of the PKI certificate files. Optionally this may be left unchanged.

Within the following files, ensure the FQDN (Fully Qualified Domain Name) based on the Terraform setup for Route53 hosted-zone aligns accordingly. If the defaults were not changed Terraform will have created a sub-domain cloudsdk within the supplied Route53 hosted-zone. The following files are updated per:

• mqtt-server.cnf

  commonName_default = opensync-mqtt-broker.cloudsdk.route53hosted-zone_name

• openssl-server.cnf

  DNS.1 = opensync-redirector.cloudsdk.route53hosted-zone_name

  DNS.2 = opensync-controller.cloudsdk.route53hosted-zone_name

To generate keys, ensure necessary Java resources are installed for your operating system:

• openjdk-11-jre-headless

• default-jdk

From within the wlan-pki-cert-scripts folder execute ./generate_all.sh script.

Copy the generated keys assuming the wlan-cloud-helm folder is at the same level as the wlan-pki-certs folder per: ./copy-certs-to-helm.sh ~/wlan-cloud-helm/

Satisfy Cloud Deployment Charts

Certain TIP Charts have upstream dependencies, form the wlan-cloud-helm folder execute:

helm dependency update tip-wlan

Various Bitnami charts will be brought into the deployment such as Kafka, PostGres, Cassandra.

Localizing the Helm charts for AWS is a critical step. Editing the following file

             `tip-wlan/example-values/aws-basic/values.yml`

Key variables to replace in this file are:

• alb.ingress.kubernetes.io/certificate-arn: "Enter the ARN supplied during terraform output"

• All locations with a URL or FQDN align to your AWS environment such as:

  • external-dns.alpha.kubernetes.io/hostname: wlan-filestore.cloudsdk.route53hosted-zone

  • ovsdb: opensync-controller.cloudsdk.route53hostedzone

  • mqtt: opensync-mqtt-broker.cloudsdk.route53hostedzone

  • All occurrences of a URL or FQDN within this file replacing route53hostedzone with your deployed Route53 hosted zone name

Deploy Controller to AWS

Local Kubeconfig is associated to the AWS service to enable Helm control of EKS resources by entering the following:

aws eks update-kubeconfig --region $your_aws_region --name cloudsdk

With all dependencies met, certificates created and in place, using Helm and the authenticated session to AWS, execute the following:

helm upgrade --install cloudsdk tip-wlan -f tip-wlan/example-values/aws-basic/values.yml --namespace tip --create-namespace

If a connection error occurs, AWS CLI may need to re-authenticate. This can be done with aws configure.

If Helm has a successful connection to AWS the following returns:

Release "cloudsdk" does not exist. Installing it now.

NAME: cloudsdk

LAST DEPLOYED: Sun Feb 7 14:00:28 2021

NAMESPACE: tip

STATUS: deployed

REVISION: 1

TEST SUITE: None

To check on status of PODs now launching in AWS enter kubectl get pods -n tip to return results from the operational EKS Kubernetes CloudSDK cluster:

NAME                                                             READY   STATUS            RESTARTS   AGE
cloudsdk-cassandra-0                                             0/1     Running           0          99s
cloudsdk-kafka-0                                                 0/1     Running           0          99s
cloudsdk-kafka-config-1-qnf7j                                    0/1     Init:0/1          0          100s
cloudsdk-opensync-gw-cloud-685b5c9d4-t485c                       0/1     Init:0/1          0          100s
cloudsdk-opensync-mqtt-broker-0                                  1/1     Running           0          99s
cloudsdk-postgresql-primary-0                                    1/1     Running           1          99s
cloudsdk-postgresql-read-0                                       1/1     Running           0          99s
cloudsdk-wlan-cloud-graphql-gw-76c69db46d-cc2zv                  1/1     Running           0          100s
cloudsdk-wlan-cloud-static-portal-8595fd964d-fkd6g               1/1     Running           0          100s
cloudsdk-wlan-port-forwarding-gateway-service-68d745b84b-2xmvq   0/1     Init:0/1          0          100s
cloudsdk-wlan-portal-service-0                                   0/1     Running           0          99s
cloudsdk-wlan-prov-service-944f44d67-4p5z5                       0/1     PodInitializing   0          100s
cloudsdk-wlan-spc-service-596ff5c546-bmgw5                       0/1     Init:0/1          0          100s
cloudsdk-wlan-ssc-service-6db4c8c8b8-jrmrc                       0/1     Init:0/2          0          100s
cloudsdk-zookeeper-0                                             1/1     Running           0          99s

After 5 to 8 minutes elapse, all POD services should be operational for example:

NAME                                                             READY   STATUS      RESTARTS   AGE
cloudsdk-cassandra-0                                             1/1     Running     0          11m
cloudsdk-kafka-0                                                 1/1     Running     0          11m
cloudsdk-kafka-config-1-qnf7j                                    0/1     Completed   0          11m
cloudsdk-opensync-gw-cloud-685b5c9d4-t485c                       1/1     Running     0          11m
cloudsdk-opensync-mqtt-broker-0                                  1/1     Running     0          11m
cloudsdk-postgresql-primary-0                                    1/1     Running     1          11m
cloudsdk-postgresql-read-0                                       1/1     Running     0          11m
cloudsdk-wlan-cloud-graphql-gw-76c69db46d-cc2zv                  1/1     Running     0          11m
cloudsdk-wlan-cloud-static-portal-8595fd964d-fkd6g               1/1     Running     0          11m
cloudsdk-wlan-port-forwarding-gateway-service-68d745b84b-2xmvq   1/1     Running     0          11m
cloudsdk-wlan-portal-service-0                                   1/1     Running     0          11m
cloudsdk-wlan-prov-service-944f44d67-4p5z5                       1/1     Running     0          11m
cloudsdk-wlan-spc-service-596ff5c546-bmgw5                       1/1     Running     0          11m
cloudsdk-wlan-ssc-service-6db4c8c8b8-jrmrc                       1/1     Running     0          11m
cloudsdk-zookeeper-0                                             1/1     Running     0          11m

Check in on the UI

Navigate to https://wlan-ui.cloudsdk.yourdomainname

Default username support@example.com and password support

Base System

MicroK8s deployment is available as part of Release 1.0 candidate. API services, database, message bus and ability to adjust Kubernetes POD performance parameters are all possible with this system which may be useful to the Community for local on premises installations.

A snap capable operating system is required for MicroK8s installation. TIP Controller has been installed on an Ubuntu 20 system with 32Gb memory, 500Gb disk and Gigabit Ethernet network interface with a user account tip created.

The system should have a fully qualified domain name and the deployment of TIP controller will require additional DNS records to be created.

Local /etc/hosts should contain the following DNS entires for your controller assigned to the IP address your machine is using to connect to the network. This same IP will be used when configuring metallb address in a subsequent step.

When accessing the UI from a workstation or when AP is connecting to the local controller the local DNS server will need to provide authoritative response for these A records in the wlan.local domain. In a future release of TIP Controller instructions will be provided to modify the FQDN of all Controller services.

DNS default entries for /etc/hosts

## 
# Replace with your IP address to be used with Load Balancer 
# Incoming Connections (It may be same as your system IP or may
# be another address on your network determiend for use between 
# TIP AP Clients and the TIP SDK) 
##
<IP Address> wlan-ui.wlan.local wlan-ui-graphql.wlan.local opensync-redirector.wlan.local opensync-controller.wlan.local opensync-mqtt-broker.wlan.local wlan-filestore.wlan.local

Install microk8s

sudo snap install microk8s --classic --channel=latest/stable

Set user permissions

sudo usermod -a -G microk8s $USER
sudo chown -f -R $USER ~/.kube

Setup MicroK8s

microk8s enable helm3 dns storage metallb

Begin Controller Setup

TIP Controller may be deployed with self-signed certificates for a local lab environment. The following steps will guide the reader through that process.

Install Keytool and Zip Packages

sudo apt install -y openjdk-11-jre-headless 
sudo apt install -y default-jdk
sudo apt install -y zip

Enable Firewall to permit Controller traffic from Container Network Interface

sudo ufw allow in on cni0 && sudo ufw allow out on cni0
sudo ufw default allow routed

Downloading TIP Controller Software

Obtain Controller PKI Certs Locally

git clone https://github.com/Telecominfraproject/wlan-pki-cert-scripts.git

Obtain Controller Locally

git clone https://github.com/Telecominfraproject/wlan-cloud-helm.git

From the current directory, two sub-directories now exist for wlan-pki-certs and wlan-cloud-helm. Enter the PKI directory and the configs sub-directory cd /wlan-pki-cert-scripts/configs

Modify all certificate configuration files for the value of your organizationalUnitName_default value set to your organizational name or other string value used in each of the PKI certificate files. Optionally this may be left unchanged.

Within the following files, ensure the FQDN (Fully Qualified Domain Name) based on local setup for DNS aligns accordingly. The following files are updated per:

• mqtt-server.cnf

  commonName_default = opensync-mqtt-broker.FQDN

• openssl-server.cnf

  DNS.1 = opensync-redirector.FQDN

  DNS.2 = opensync-controller.FQDN

Once complete generate the service certificates and copy these to the controller.

cd wlan-pki-cert-scripts 
./generate_all.sh 
./copy-certs-to-helm.sh ~/wlan-cloud-helm/

Deploy Controller

TIP controller defaults to a domain of wlan.local. It is possible to operate a lab DNS service permitting local resolution of this domain for the TIP controller services. Certificate instructions for a self-signed private domain will follow in a subsequent release of service and documentation.

cd ~/wlan-cloud-helm
git checkout release/v1.0.0
microk8s helm3 dependency update tip-wlan
microk8s kubectl create namespace tip
microk8s helm3 upgrade --install tip-wlan tip-wlan/ --namespace tip -f tip-wlan/example-values/microk8s-basic/values.yaml

Helm will deploy the Controller containers within a TIP namespace to microk8s on the machine.

Release "tip-wlan" does not exist. Installing it now.
NAME: tip-wlan
LAST DEPLOYED: Wed Feb  3 20:45:13 2021
NAMESPACE: tip
STATUS: deployed
REVISION: 1
TEST SUITE: NoneCheck Controller Status

To check status of the PODs, Services, and Persistent Volume Claims (storage) use the following commands. Please note, depending on your server, all PODs may take several minutes to fully initialize.

microk8s kubectl get services -n tip
microk8s kubectl get pvc -n tip
microk8s kubectl get pods -n tip

Examples of all three commands:

tip@microk8slocal:~$ microk8s kubectl get svc -n tip
NAME                                TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                                                       AGE
tip-wlan-postgresql-headless        ClusterIP      None             <none>        5432/TCP                                                      47h
tip-wlan-kafka-headless             ClusterIP      None             <none>        9093/TCP                                                      47h
tip-wlan-cassandra-headless         ClusterIP      None             <none>        7000/TCP,7001/TCP,7199/TCP,9042/TCP,9160/TCP                  47h
tip-wlan-zookeeper-headless         ClusterIP      None             <none>        2181/TCP,3888/TCP,2888/TCP                                    47h
tip-wlan-postgresql-read            ClusterIP      10.152.183.145   <none>        5432/TCP                                                      47h
tip-wlan-cassandra                  ClusterIP      10.152.183.31    <none>        9042/TCP,9160/TCP                                             47h
tip-wlan-zookeeper                  ClusterIP      10.152.183.75    <none>        2181/TCP                                                      47h
tip-wlan-wlan-cloud-static-portal   NodePort       10.152.183.7     <none>        80:32186/TCP                                                  47h
tip-wlan-wlan-cloud-graphql-gw      NodePort       10.152.183.117   <none>        4000:30223/TCP                                                47h
tip-wlan-kafka                      ClusterIP      10.152.183.42    <none>        9093/TCP                                                      47h
tip-wlan-wlan-spc-service           ClusterIP      10.152.183.165   <none>        9041/TCP,9042/TCP                                             47h
tip-wlan-postgresql                 ClusterIP      10.152.183.216   <none>        5432/TCP                                                      47h
tip-wlan-nginx-ingress-controller   LoadBalancer   10.152.183.232   10.75.0.9     80:32101/TCP,443:31122/TCP                                    47h
tip-wlan-wlan-ssc-service           ClusterIP      10.152.183.189   <none>        9031/TCP,9032/TCP                                             47h
tip-wlan-wlan-prov-service          ClusterIP      10.152.183.160   <none>        9091/TCP,9092/TCP                                             47h
tip-wlan-opensync-mqtt-broker       LoadBalancer   10.152.183.32    10.75.0.9     1883:31511/TCP,9001:32046/TCP                                 47h
tip-wlan-wlan-portal-service        LoadBalancer   10.152.183.246   10.75.0.9     9051:30504/TCP,9052:31817/TCP                                 47h
tip-wlan-opensync-gw-cloud          LoadBalancer   10.152.183.97    10.75.0.9     6640:31000/TCP,6643:31932/TCP,9096:30749/TCP,9097:31793/TCP   47h
tip@microk8slocal:~$

tip@microk8slocal:~$ microk8s kubectl get pvc -n tip
NAME                                             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
datadir-tip-wlan-kafka-0                         Bound    pvc-df6a471f-6a79-4a60-8e83-6c89326b6152   1Gi        RWO            microk8s-hostpath   4d2h
data-tip-wlan-zookeeper-0                        Bound    pvc-d139d789-123c-41e4-a299-2c1dc001a044   1Gi        RWO            microk8s-hostpath   4d2h
data-tip-wlan-opensync-mqtt-broker-0             Bound    pvc-d31682b7-db86-4022-8079-2acb3689ef68   1Gi        RWO            microk8s-hostpath   4d2h
data-tip-wlan-postgresql-master-0                Bound    pvc-127bc86a-acc1-420c-8cca-d3d619615cba   1Gi        RWO            microk8s-hostpath   4d2h
data-tip-wlan-postgresql-slave-0                 Bound    pvc-f000dbd6-dcd7-4fd1-8dfb-056475e4b9dc   1Gi        RWO            microk8s-hostpath   4d2h
db-tip-wlan-opensync-mqtt-broker-0               Bound    pvc-9d6c25ce-0712-4660-ad3e-cdc4ce41bdf7   1Gi        RWO            microk8s-hostpath   4d2h
data-tip-wlan-cassandra-0                        Bound    pvc-645ae94f-36e7-4fe3-a093-c66c56e82092   1Gi        RWO            microk8s-hostpath   4d2h
file-store-data-tip-wlan-wlan-portal-service-0   Bound    pvc-530ed2bf-b120-4eee-b6d5-0d7cdd468d2b   4Gi        RWX            microk8s-hostpath   4d2h
tip@microk8slocal:~$ tip@microk8slocal:~

$ microk8s kubectl get pods -n tip
NAME                                                 READY   STATUS    RESTARTS   AGE
tip-wlan-kafka-0                                     0/1     Pending   0          4d1h
tip-wlan-wlan-cloud-static-portal-bdfcb4559-9wt9r    0/1     Pending   0          4d1h
tip-wlan-wlan-spc-service-68cffddd96-prppd           0/1     Pending   0          4d1h
tip-wlan-wlan-ssc-service-66dbdd89f4-rhfxv           0/1     Pending   0          4d1h
tip-wlan-nginx-ingress-controller-7458d6f654-cwnw6   0/1     Pending   0          4d1h
tip-wlan-postgresql-slave-0                          0/1     Pending   0          4d1h
tip-wlan-opensync-gw-cloud-7b69865fcc-8fzbw          0/1     Pending   0          4d1h
tip-wlan-wlan-cloud-graphql-gw-bc897994b-gpf8b       1/1     Running   0          4d1h
tip-wlan-cassandra-0                                 0/1     Pending   0          4d1h
tip-wlan-opensync-mqtt-broker-0                      1/1     Running   0          4d1h
tip-wlan-zookeeper-0                                 1/1     Running   0          4d1h
tip-wlan-postgresql-master-0                         1/1     Running   0          4d1h
tip-wlan-wlan-portal-service-0                       1/1     Running   0          4d1h
tip-wlan-wlan-prov-service-84fc7bfc5f-xqjgx          1/1     Running   0          4d1h
tip@microk8slocal:~$

Access Point Self-Signed Keys

In the earlier stage when self-signed keys were created for the controller, keys were also created to support Access Point connections over SSL to the newly deployed controller. To obtain these keys, return to the /wlan-pki-cert-scripts/generated folder and copy AP.zip containing the Access Point keys. Extract this archive and using sing secure copy (SCP) transfer keys to the /usr/opensync/certs folder on the AP.

Directing Access Point To Controller

In the current release of a TIP Controller using self-signed certificates, Access Points communicate to the TIP Controller using OpenSync. Access Points are directed to the controller at this time using local configuration.

The default TIP Open AP username and login are 'root' and 'openwifi'

/bin/wlan_ap_redirector.sh ssl:<IP or FQDN of controller>:6643

TIP OpenWiFi devices are available from many hardware partners. All TIP OpenWiFi devices have the same standard image of open source software.

TIP OpenWiFi 1.0 devices run OpenWrt operating system with OpenSync as a management stack. The use of OpenWrt is largely upstream based on OpenWrt 19.07 in Open WiFi 1.0.

When a TIP firmware image is created, the system will merge TIP specific patches, kernel specific patches, and build this with the target OpenWrt 19.07 operating system as one complete firmware image. From this process a TIP OpenWiFi standard firmware results with the following settings.

Device Defaults

Unable to Connect to WAN or Controller

If the OpenWiFi device has been unable to reach the internet or the assigned controller, the 'Maverick' SSID will appear. Joining this Wi-Fi network will join the local management interface to help onboard the device to the internet and controller.

After joining Maverick SSID, opening a web browser to the address 192.168.1.1 where the following login displays. Enter root login and password.

Common setup to enable internet access is available. WAN interface defaults to DHCP, if the WAN requires static configuration select the drop down to continue:

Changing the Local Area Network is also possible from Maverick mode. There may be cases where an IP overlap has occurred in certain double NAT internal networks. For this reason it may be necessary to change this value, else no change is required here:

It is possible to apply a firmware update from the Maverick interface. This operation is normally performed by the controller however in the event it is desired, have the sysupgrade image downloaded locally before continuing:

Manually setting the cloud location may be done using its Fully Qualified Domain Name (FQDN) in the Redirector field. Device certificates are unique per TIP Open WiFi access point or switch. It should not be required to change these values at any time. Please exercise caution if replacing certificates manually.

With the Cloud SDK now installed into either a public cloud or on premises, logging in with default username support@example.com and password support are now possible.

Once successfully logged in, please refer to User Interface documentation for further details of specific configuration.