OpenWiFi Getting Started Technical Details
December 06, 2024
OpenWiFi access points default credentials
root
openwifi
When you are logged into the CLI, you may find the logread command useful.
logread -l100 -f
The /etc/hosts file on the AP should have an entry for the controller. Yes this sounds redundant, but in our experience, this is a great way to ensure things along.
OpenWiFi controller default credentials
[email protected]
openwifi
You must connect to the OpenWiFi controller using the FQDN. You will not be able to login if you connected via IP address.
When you connect to the OpenWiFi controller, if you get a popup for client side SSL certificates, hit cancel.
OpenWiFi access point initialization details
If you need to "transfer" an AP -
https://portal.keys.tip.build/#/certificates
If you need to factory reset an AP -
firstboot -yr
Put customer / guest / production traffic from WLAN onto tagged VLAN. Do not use VLAN 1 for Wi-Fi traffic.
Upgrade by AP’s command line prompt - ssh to AP and login as root / openwifi
Transfer firmware file to the /tmp directory of the AP by SCP
Run sysupgrade command to upgrade the AP
# sysupgrade -o /tmp/firmware_file.bin
If you want to build your own firmware - https://github.com/Telecominfraproject/wlan-ap
You may need to update the /etc/resolv.conf on your controller.
ssh [email protected]
sudo vi /etc/resolv.conf
change the nameserver to be your rXg
This will allow your controller to grab firmware
To figure out what kind of AP:
cat /etc/ucentral/capabilities.json
If you are using a RADIUS "OR" for OpenWiFi and you don't have a user policy selected, there is the possibility you can get an Access Accept with an empty Tunnel-Password. You would see this in the logs: (Tunnel-Password => %account.pre_shared_key% (*account unavailable*))
In that case, your AP will continue to send RADIUS request spam for multiple minutes (tens of thousands of requests). The fix is to make sure you either have an AND or OR policy with a proper user policy selected
root
openwifi
When you are logged into the CLI, you may find the logread command useful.
logread -l100 -f
The /etc/hosts file on the AP should have an entry for the controller. Yes this sounds redundant, but in our experience, this is a great way to ensure things along.
OpenWiFi controller default credentials
[email protected]
openwifi
You must connect to the OpenWiFi controller using the FQDN. You will not be able to login if you connected via IP address.
When you connect to the OpenWiFi controller, if you get a popup for client side SSL certificates, hit cancel.
OpenWiFi access point initialization details
If you need to "transfer" an AP -
https://portal.keys.tip.build/#/certificates
If you need to factory reset an AP -
firstboot -yr
Put customer / guest / production traffic from WLAN onto tagged VLAN. Do not use VLAN 1 for Wi-Fi traffic.
Upgrade by AP’s command line prompt - ssh to AP and login as root / openwifi
Transfer firmware file to the /tmp directory of the AP by SCP
Run sysupgrade command to upgrade the AP
# sysupgrade -o /tmp/firmware_file.bin
If you want to build your own firmware - https://github.com/Telecominfraproject/wlan-ap
You may need to update the /etc/resolv.conf on your controller.
ssh [email protected]
sudo vi /etc/resolv.conf
change the nameserver to be your rXg
This will allow your controller to grab firmware
To figure out what kind of AP:
cat /etc/ucentral/capabilities.json
If you are using a RADIUS "OR" for OpenWiFi and you don't have a user policy selected, there is the possibility you can get an Access Accept with an empty Tunnel-Password. You would see this in the logs: (Tunnel-Password => %account.pre_shared_key% (*account unavailable*))
In that case, your AP will continue to send RADIUS request spam for multiple minutes (tens of thousands of requests). The fix is to make sure you either have an AND or OR policy with a proper user policy selected