Table of Contents

Creating Hotspot 2.0 / Passpoint 2.0 Hotspots on OpenWRT

In today’s connected world, providing seamless and secure Wi-Fi connectivity is essential for various industries and public spaces. One revolutionary technology that addresses this need is Hotspot 2.0, also known as Passpoint 2.0. In this guide, we will explore how to set up Hotspot 2.0 on OpenWRT, a popular open-source router and access point firmware.

Introduction

Hotspot 2.0 brings enhanced security and convenience to Wi-Fi connectivity by automating the connection process and ensuring a secure exchange of credentials. Before diving into the technical details, let’s address the key questions: What is Hotspot 2.0, and why is it crucial for modern Wi-Fi networks?

Hotspot 2.0, defined by the IEEE 802.11u standard, enables seamless and secure Wi-Fi roaming by allowing mobile devices to connect to Wi-Fi networks automatically. This technology eliminates the hassle of manually selecting and authenticating with each network, providing users with a more efficient and user-friendly experience.

The Significance of Hotspot 2.0 and Passpoint 2.0

Enhancing User Experience

One of the main goals of Hotspot 2.0 is to enhance the user experience when connecting to Wi-Fi networks. With Passpoint certification, smartphones can automatically identify and connect to Passpoint-certified access points. This eliminates the need for users to navigate through network lists and enter credentials manually.

Security and Authentication

Hotspot 2.0 addresses security concerns by implementing robust authentication protocols. The Passpoint profile on a smartphone contains essential information, including MCC-MNC (Mobile Country Code – Mobile Network Code), NAI realm, and OI (Organization Identifier). These elements, along with login credentials, establish a secure connection to the service provider.

Interoperability and Roaming

Passpoint profiles are not tied to specific SSIDs, allowing them to work across any WLAN with appropriate Passpoint configuration. This interoperability ensures a consistent and reliable connection experience, especially in environments with multiple access points.

Implementing Hotspot 2.0 on OpenWRT

Prerequisites for Hotspot 2.0 on OpenWRT

Before configuring Passpoint on OpenWrt, ensure you have the following prerequisites:

  • OpenWrt compatible device with a Passpoint-capable wireless device (PHY).
  • OpenWrt 21.02, or newer, including wpad (hostapd) built with the hs20 option.
  • Full version of the iw package in OpenWrt.
  • 802.1x infrastructure (RADIUS server).
  • Information about the assigned RADIUS servers:
    • Server IP address
    • Port numbers
    • Shared secrets

Note: This information can be obtained through an email or document through your provider. If you’re using Google Orion like we are in our examples below, you’ll be self hosting a freeradius based radsec proxy . We won’t be going into this in this article so please read your providers instructions carefully.

Overview of Hotspot 2.0 on OpenWRT

Passpoint configuration on OpenWrt requires specific preparations and package installations. Here is an overview of the necessary steps:

  1. Check wpad for Hotspot 2.0 Capability:

    Verify if wpad has Hotspot 2.0 capability by running the following command:

    strings /usr/sbin/wpad | grep hs20

    If nothing shows up, it indicates that wpad lacks Hotspot 2.0 support. In this case, the default package (wpad-basic) needs to be replaced with a full version, such as wpad-openssl. We have commands that will do this for you below.

  2. Hostapd Configuration with UCI:

    Unlike manual editing of hostapd.conf on a Linux box, OpenWrt uses UCI (Unified Configuration Interface) to auto-generate the configuration. The shell script “/lib/netifd/hostapd.sh” generates “/var/run/hostapd-phyX.conf” based on the wireless configuration file “/etc/config/wireless” in the UCI.

    Ensure the wireless configuration in “/etc/config/wireless” is correctly set up to align with Passpoint requirements.

By following these steps, you set up the necessary prerequisites and configurations for Passpoint on OpenWrt, enabling your device to support Hotspot 2.0 seamlessly.

Are you searching for the perfect OpenWRT device with robust Hotspot 2.0 and Passpoint 2.0 support? Look no further! We’ve curated a list of highly recommended devices that seamlessly integrate these advanced features into your network. From the GL-MT6000 (Flint 2) with WiFi 6 capabilities to the pocket-sized GL-AXT1800 (Slate AX) offering gigabit travel convenience, explore the best options for enhanced connectivity and security. Upgrade your router experience with these top-notch devices tailored for Hotspot 2.0 enthusiasts and professionals alike.

  • (Preferred) GL.iNet GL-MT6000 (Flint 2) WiFi 6 Router
    • Be sure after running the the config options we have below to run opkg --force-overwrite install kmod-mt7921-common kmod-mt7921-firmware kmod-mt7921e kmod-mt7921s kmod-mt7921u kmod-mt76x2u kmod-mt76-connac kmod-mt76-core kmod-mt76-usb kmod-mt7615-common kmod-mt7615-firmware kmod-mt7615e kmod-mt76x2-common kmod-mt76x2u kmod-mt7915e kmod-mt7916-firmware kmod-mt7986-firmware to reinstall any wifi drivers that were uninstalled.

  • GL.iNet GL-AX1800(Flint) WiFi 6 Router
    • For some reason GL.iNet left this device on OpenWRT base 21.xx.xx rather than 22.xx.xx or 23.xx.xx like their other supported devices.
      • It’s also using Linux/OpenWRT Kernel 4.4.60 which is very unusual.
    • The GL.iNet latest image (Currently 4.5.0) repo is missing critical packages needed for HS20 Support. Specifically it is missing the iw-full package.
      • The workaround is to manually install the appropriate dependencies and the package manually.
      • libnl-tiny1
      • iw-full
      • Fix this issue by running the following command wget https://downloads.openwrt.org/releases/21.02.7/packages/arm_cortex-a7/base/libnl-tiny1_2020-08-05-c291088f-2_arm_cortex-a7.ipk && wget https://downloads.openwrt.org/releases/21.02.7/packages/arm_cortex-a7/base/iw-full_5.9-8fab0c9e-3_arm_cortex-a7.ipk && opkg install --force-overwrite libnl-tiny1_2020-08-05-c291088f-2_arm_cortex-a7.ipk && opkg install --force-overwrite iw-full_5.9-8fab0c9e-3_arm_cortex-a7.ipk
    • We’ve made GL.iNet aware of the issue via Email on 2024/03/04. We’ve not received any updates yet.
    • Be sure after running the the config options we have below to run opkg --force-overwrite --force-removal-of-dependent-packages kmod-ath kmod-ath11k-ahb kmod-ath11k-pci kmod-ath11k-ahb to reinstall any wifi drivers that were uninstalled.

hgot07 and I have completed testing, in addition to the above, on other GL.iNet devices including the Mango (Has storage issues however), Slate and Beryl devices on both internal and external wireless interfaces.

If you’re fine with having to install OpenWRT by flashing the firmware on the device, we can recommend the following devices as well.

  • GL.iNet GL-MT3000 (Beryl AX)
    • If you want to use the internal radios on the Beryl AX, you’ll need to flash the Latest Full OpenWRT version for the GL-MT300
    • For some reason GL.iNet left this device on OpenWRT base 21.xx.xx rather than 22.xx.xx or 23.xx.xx like their other supported devices.
    • The GL.iNet latest image (Currently 4.5.0) is using a hacked driver for support for the mt7981 devices that prevent stable utilization of the features we need for HotSpot 2.0 support.
      • We’ve made GL.iNet aware of the issue on both Twitter and via Email on 2024/02/25. They acknowledged the issue and said their technical team would reply. We’ve not received any updates yet.
    • Be sure after flashing OpenWRT and running the config options we have below to run opkg --force-overwrite install kmod-mt7915e kmod-mt7981-firmware mt7981-wo-firmware to reinstall any wifi drivers that were uninstalled.
  • Cudy WR3000
    • OpenWRT Flashing instructions for the Cudy WR3000
    • We Love it for the amazing performance. It’s quite similar to GL.iNet’s Flint and Flint 2 for less than half the cost.
    • Be sure to use Google Chrome when uploading firmware via the web gui.
    • You’ll need to install a couple different packages run the following command after running the commands in the section below opkg --force-overwrite install kmod-mt76x2u kmod-mt76-connac kmod-mt76-core kmod-mt76-usb kmod-mt76x2-common kmod-mt76x2u kmod-mt7915e kmod-mt7916-firmware mt7981-wo-firmware bridger and echo 'options mt7915e wed_enable=Y' >> /etc/modules.conf
  • TP-Link EAP225-Outdoor
    • OpenWRT flashing instructions for the EAP225
      • This is going to be an advanced OpenWRT install, high likelihood of bricking your device, modern TP-Link Omada devices like this do not have a recovery mode easily accessible.
        • DO NOT ATTEMPT IF YOU’RE NOT SKILLED
        • No good way to guarantee hardware revision you’ll receive. We ordered multiple and received a v3, v3.6, and v3.8 in various quantities.
        • Do not update to TP-Link Firmware 5.1.0 or 5.1.1 if you can avoid it. If you’re on those versions or anything newer, you’ll need to browse the OpenWRT forums for a version that has a hotfix to bypass new image protections that were introduced on later TP-Link firmware versions.
    • Be sure after the flashing OpenWRT and running the config options we have below to run opkg --force-overwrite install kmod-ath10k-ct kmod-ath9k kmod-ath9k-common kmod-ath to reinstall any wifi drivers that were uninstalled.
    • We love it because it is the only OpenWRT compatible outdoor unit we could find with replaceable antennas.
    • We’ve tested it with Clear LoS up to 1200 Feet or 400 meters with omnidirectional antennas.
    • Only WiFi 5 however. If you find something better for this purpose, please let us know!

Updating OpenWRT Packages for Hotspot 2.0 Support on OpenWRT

Note: Perform this section while hardwired into the device via ethernet, it will temporarily disable wifi.

Note: These commands may uninstall other packages that have these as dependencies. If this happens, reinstall them after finishing this section.

Note: These packages are touchy on their install order. If you get an error on your device. Try uninstalling everything mentioned and installing the error package first. You can do this from the command line or the software page in the Luci admin page.

Before configuring Hotspot 2.0 on OpenWRT, ensure that your system has the required packages installed.

Use the following commands to install necessary components:

opkg update && \
opkg --force-removal-of-dependent-packages remove iw gl-sdk4-repeater hostapd* wpad*  && \
opkg --force-overwrite --force-downgrade --force-removal-of-dependent-packages install wpad-openssl nano && \
opkg --force-overwrite --force-downgrade --force-removal-of-dependent-packages install iw-full hostapd-common && \
opkg --force-overwrite --force-removal-of-dependent-packages install kmod-mac80211 kmod-cfg80211

If you’ve purchased one of the GL.iNet devices we recommended above you’ll also run the following command:

opkg --force-overwrite install kmod-ath10k-smallbuffers kmod-ath9k kmod-ath9k-common kmod-ath

Using USB External WiFi Cards on OpenWRT

When it comes to enhancing your OpenWRT setup with external WiFi adapters, especially for HotSpot 2.0 support, choosing the right hardware is crucial. Below, we recommend some top-performing external WiFi adapters known for their OpenWRT compatibility and 802.11 AX support.

We recommend these adapters for their overall OpenWRT compatibility and 802.11 AX Support. Top down, best to worst in terms of OpenWRT compatibility.

  • ALFA AWUS036AXM WiFi 6E USB 3.0 USB Adapter, AXE3000 Tri-Band 6Ghz/5.8GHz/2.4GHz
    • We love it because it has external and replaceable antennas and it supports either 2.4Ghz/5Ghz on WiFi 6. Once OpenWRT adds support, the device will also support the 6 Ghz band in the future.
    • Requires OpenWRT Kernel Level 5.15/5.2 at least. Verify with uname -r.
    • Use the following command to install the appropriate drivers. opkg --force-overwrite install kmod-mt7921-common kmod-mt7921-firmware kmod-mt7921e kmod-mt7921s kmod-mt7921u kmod-mt76x2u kmod-mt76-connac kmod-mt76-core kmod-mt76-usb kmod-mt76x2-common kmod-mt76x2u

  • NETGEAR WiFi AC1200 USB 3.0 Adapter (A6210)
    • We love it because it is cheap and it is the easiest to install out of any of the external adapters. Not to mention it is the easiest to get your hands on. It lacks external antennas however.
    • Requires OpenWRT Kernel Level 5.15/5.2 at least. Verify with uname -r.
    • Use the following command to install the appropriate drivers. opkg --force-overwrite install kmod-mt7921-common kmod-mt7921-firmware kmod-mt7921e kmod-mt7921s kmod-mt7921u kmod-mt76x2u kmod-mt76-connac kmod-mt76-core kmod-mt76-usb kmod-mt76x2-common kmod-mt76x2u

  • ALFA AWUS036AXML 802.11axe WiFi 6E USB 3.0 Adapter AXE3000, Tri Band 6 GHz
    • We love it because it has external and replaceable antennas and it has WiFi 7 and 6GHz support as soon as OpenWRT supports it. Till then it is 2.4Ghz/5Ghz WiFi 6.
    • Requires Kernel Level 6.6 at least. Ideally, 6.7. Verify with uname -r.
      • So far we can get it working on openwrt latest reguardless of the documented kernel requirements, it will not work on any GL.iNet device other than the Flint 1 and Flint 2 or if you can flash your device with OpenWRT 23.05.2.
    • Use the following command to install the appropriate drivers. opkg --force-overwrite install kmod-mt76x2u kmod-mt76-connac kmod-mt76-core kmod-mt76-usb kmod-mt76x2-common kmod-mt76x2u kmod-mt7915e kmod-mt7916-firmware mt7981-wo-firmware

The AWUS036AXML is definately the best USB based WiFi radio we could find. However it lacks support on many devices. As of the moment of this articles writing, it is possible, but it’ll be technicially challenging to most. This is why we prefer to recommend the AWUS036AXM for most people.

For a list of other documented adapters that have support on Linux and OpenWRT See the USB-WiFi Documentation Repo

Installing External USB WiFi Drivers on OpenWRT 

#Add any more drivers you may need. 
#The most popular WiFi 5 and WiFi 6 adapters, including our recommended should be covered below.
#Command order and seperation matters.
opkg --force-removal-of-dependent-packages remove kmod-mt7921-common kmod-mt7921-firmware kmod-mt7921e kmod-mt7921s kmod-mt7921u kmod-mt76x2u && \
opkg --force-overwrite install kmod-mt7921-common kmod-mt7921-firmware kmod-mt7921e kmod-mt7921s kmod-mt7921u kmod-mt76x2u kmod-ath10k-smallbuffers kmod-ath9k kmod-ath9k-common kmod-ath kmod-mac80211 kmod-cfg80211 && \
opkg --force-overwrite install kmod-thermal kmod-cfg80211 kmod-mac80211 kmod-mt76-connac kmod-mt76-core kmod-mt76-usb kmod-mt7615-common kmod-mt7615-firmware kmod-mt7615e kmod-mt76x0-common kmod-mt76x02-common kmod-mt76x02-usb kmod-mt76x0u kmod-mt76x2-common kmod-mt76x2u kmod-mt7915e kmod-mt7916-firmware

Configuring Wireless Interfaces for Hotspot 2.0 on OpenWRT

In the /etc/config/wireless file, customize the settings for your Hotspot 2.0-enabled interface. Ensure the correct device, encryption type, and other parameters are set. Pay attention to the WAN Metrics, NAI Realm, and Domain Names sections to tailor them to your service provider.

We have many of these options already configured in the details below. Read the code comments carefully, this section is not copy and paste. It requires a lot of customization for your environment.

Copy and modify the following carefully. Once working, mirror it for the 2.4ghz, 5ghz, and 6ghz radios while adjusting the wifi-iface config name, ifname, and device (radio) options for each radio.

nano /etc/config/wireless

config wifi-iface 'radio1_orion5g'
    #Modify to your radsec proxy server / radius server
    option acct_secret 'radsec'
    option acct_server 'xxx.xxx.xxx.xxx'
    option auth_secret 'radsec'
    option auth_server 'xxx.xxx.xxx.xxx'
    # Likely radio0 or radio1 if using built in radios, if using a usb device it'll likely be radio 2
    option device 'radio1'
    # Change between either wpa2-mixed or wpa3-mixed
    option encryption 'wpa3-mixed'
    # first number matches the radio, second is the ssid number. Both start at 0
    # Ex wlan1-2 would be radio 1, ssid 2.
    option ifname 'wlan1-2'
    
    #Table E-4 of IEEE Std 802.11-2012 Annex E define the values that can be used in this. (Likely just use 5173)
    # https://ieeexplore.ieee.org/iel5/6361246/6361247/06361248.pdf
    # https://mentor.ieee.org/802.11/dcn/10/11-10-0564-00-0s1g-operating-classes.ppt
    #format: hexdump of operating class octets
    option hs20_operating_class '5173'
    # See Instructions Below (Optional, omit if you want.)
    option hs20_wan_metrics '01:3e80:3e80:33:99:3000'
    # Venue Info 
    # The available values are defined in IEEE Std 802.11u-2011, 7.3.1.34
    option iw_venue_group '1'
    option iw_venue_type '7'
    # Specify the same nasid for both 2.4ghz and 5ghz. Use any time the network is different. Normally it'll be the same across the board for all AP's in the same location.
    option nasid 'OrionWRT'
    # Likely leave as guest, but customize if needed
    option network 'guest'
    # Likely Leave as Orion or OrionWiFi if using orion. But SSID can be anything you want.
    option ssid 'OrionWiFi'
    # Specify the IP address type availability as '11'.
    # IP Address Type Availability (ANQP) setting that indicates the availability of IP address types on the Passpoint network.
    # The value '11' informs Passpoint clients that both IPv4 and IPv6 addresses are available on the network.
    # It helps clients understand the network's IP address capabilities.
    # Refer to IEEE Std 802.11-2016, Section 9.4.2.72 for more details on IP Address Type Availability.
    option iw_ipaddr_type_availability '11'
    # Local time zone as specified in 8.3 of IEEE Std 1003.1-2004
    # Set as CST, Feel free to customize or omit.
    # stdoffset[dst[offset][,start[/time],end[/time]]]
    # We've defaulted it to Central Standard Time (most of our US based readers are in CST/CDT.)
    #This config is optional. You can safely omit it.
    option time_zone 'CST6CDT,M3.2.0,M11.1.0'
    # Specify the access network type as '2' (Chargeable public network).
    # Access Network Type (ANQP) is set to '2' indicating a Chargeable public network.
    # This value informs clients that the network requires payment for access.
    # Refer to IEEE Std 802.11-2016, Section 9.4.2.72 for more details.
    option iw_access_network_type '2'
    # Specify the network authentication type as '00'.
    # Network Authentication Type (ANQP) setting that specifies the network's authentication type for Passpoint.
    # The value '00' indicates that the network authentication is open or unspecified.
    # It informs Passpoint clients about the type of authentication used by the network.
    # Refer to IEEE Std 802.11-2016, Section 9.4.2.72 for more details on Network Authentication Type.
    option iw_network_auth_type '00'
    # Operator-friendly name for Hotspot 2.0. (Can be anything you'd like as long as it is prefixed with your lang code.)
    option hs20_oper_friendly_name 'eng:Orion'
    # List of venue names associated with the Passpoint network, specifying language code and venue information. (Can be anything you'd like as long as it is prefixed with your lang code.)
    list iw_venue_name 'eng:Orion'
    # List of venue URLs associated with the Passpoint network, specifying language code and URL. (Can be any https url. Will Popup as notification on devices that connect.)
    list iw_venue_url '1:https://orionwifi.com'
    # List of operator icons, specifying width, height, language code, image format, and icon filename. (This doesn't need to be a valid path but must be specified on OpenWRT)
    list operator_icon '64:64:eng:image/png:operator_icon:operator_icon.png'
    # Connection Capability
    # This can be used to advertise what type of IP traffic can be sent through the
    # hotspot (e.g., due to firewall allowing/blocking protocols/ports).
    # format: <IP Protocol>:<Port Number>:<Status>
    # IP Protocol: 1 = ICMP, 6 = TCP, 17 = UDP
    # Port Number: 0..65535
    # Status: 0 = Closed, 1 = Open, 2 = Unknown
    # Each hs20_conn_capab line is added to the list of advertised tuples.
    #list hs20_conn_capab=1:0:2
    #list hs20_conn_capab=6:22:1
    #list hs20_conn_capab=17:5060:0
    # Set the airtime policy operating mode:
    # 0 = disabled (default)
    # 1 = static config
    # 2 = per-BSS dynamic config
    # 3 = per-BSS limit mode
    #option airtime_mode=0
    # Interval (in milliseconds) to poll the kernel for updated station activity in
    # Static configuration of station weights (when airtime_mode=1). Kernel default
    # weight is 256; set higher for larger airtime share, lower for smaller share.
    # Each entry is a MAC address followed by a weight.
    # Currently doesn't work leave commented out
    #list airtime_sta_weight '02:01:02:03:04:05 256'
    #list airtime_sta_weight '02:01:02:03:04:06 512'
    # Per-BSS airtime weight. In multi-BSS mode, set for each BSS and hostapd will
    # configure station weights to enforce the correct ratio between BSS weights
    # depending on the number of active stations. The *ratios* between different
    # BSSes is what's important, not the absolute numbers.
    # Must be set for all BSSes if airtime_mode=2 or 3, has no effect otherwise.
    #option airtime_bss_weight=1
    # GAS Address 3 behavior
    # 0 = P2P specification (Address3 = AP BSSID) workaround enabled by default
    #     based on GAS request Address3
    # 1 = IEEE 802.11 standard compliant regardless of GAS request Address3
    # 2 = Force non-compliant behavior (Address3 = AP BSSID for all cases)
    #option iw_gas_address3 '0'
    # Whether the current BSS should be limited (when airtime_mode=3).
    #
    # If set, the BSS weight ratio will be applied in the case where the current BSS
    # would exceed the share defined by the BSS weight ratio. E.g., if two BSSes are
    # set to the same weights, and one is set to limited, the limited BSS will get
    # no more than half the available airtime, but if the non-limited BSS has more
    # stations active, that *will* be allowed to exceed its half of the available
    # airtime.
    #option airtime_bss_limit '1'
    # Country code (ISO/IEC 3166-1). Used to set regulatory domain.
    # Set as needed to indicate country in which device is operating.
    # This can limit available channels and transmit power.
    # These two octets are used as the first two octets of the Country String
    # (dot11CountryString)w
    option country 'US'
    # The third octet of the Country String (dot11CountryString)
    # This parameter is used to set the third octet of the country string.
    # All environments of the current frequency band and country (default)
    #option country3 '0x20'
    # Outdoor environment only
    #option country3 '0x4f'
    # Indoor environment only
    #option country3 '0x49'
    # Noncountry entity (country_code=XX)
    #option country3 '0x58'
    # IEEE 802.11 standard Annex E table indication: 0x01 .. 0x1f
    # Annex E, Table E-4 (Global operating classes)
    #https://mentor.ieee.org/802.11/dcn/16/11-16-0822-00-000m-extension-of-mmwave-operating-class.docx
    #option country3 '0x04'

    #ProxyARP and 80211k are not supported on all devices, remove if you have issues.
    option proxy_arp '1'
    option ieee80211k '1'

    # Comment out what you don't need and uncomment/modify what you do.
    #AT&T / Orion 3gpp
    list iw_anqp_3gpp_cell_net '311,180' #AT&T Wireless
    list iw_anqp_3gpp_cell_net '313,100' #AT&T FirstNet
    list iw_anqp_3gpp_cell_net '310,280' #AT&T Mobility
    list iw_anqp_3gpp_cell_net '310,410' #AT&T Mobility
    list iw_anqp_3gpp_cell_net '310,150' #Cricket Wireless
    #T-Mobile 3gpp 
    # list iw_anqp_3gpp_cell_net '310,240'
    # list iw_anqp_3gpp_cell_net '310,260'
    # list iw_anqp_3gpp_cell_net '310,310'
    #Orion domain Names
    list iw_domain_name 'orion.area120.com'
    list iw_domain_name 'orionwifi.com'
    list iw_domain_name 'dogwood120.net'
    list iw_domain_name 'wifi.fi.google.com'
    #breaks orion if specified here but is included as a domain to search for in the orion test profile
    #list iw_domain_name 'openroaming.goog'
    #AT&T Domain Names
    #list iw_domain_name 'att.com'
    #list iw_domain_name 'attwifi.com'
    #list iw_domain_name 'attwireless.com'
    #T-Mobile Domain Names
    #list iw_domain_name 't-mobile.com'
    #OpenRoaming / IronWiFi Domain Names
    #list iw_domain_name 'ironwifi.net'
    #list iw_domain_name 'openroaming.org'
    #list iw_domain_name 'apple.openroaming.net'
    #list iw_domain_name 'google.openroaming.net'
    #list iw_domain_name 'ciscooneid.openroaming.net'
    # Anything more than 3 OUIs and the information won't be available until the client performs a GAS Request.
    # Orion Custom Default Consortium
    list iw_roaming_consortium 'f4f5e8f5f4'
    #OpenRoaming Consortium
    #Baseline Participation: OpenRoaming for All Identities, settlement-free, no personal data requested, baseline QoS - includes, but is not limited to users in education and research
    #list iw_roaming_consortium '5a03ba0000'
    #Education-Only Participation: OpenRoaming Visited Network Providers who want to signal that they specifically welcome educational and research (i.e. eduroam) visitors settlement-free, 
    #list iw_roaming_consortium '5a03ba0800'
    #IronWiFi Consortium
    #list iw_roaming_consortium 'AA146B0000'
    #list iw_roaming_consortium 'BAA2D00000'
    #list iw_roaming_consortium '5A03BA0000'
    #Cisco OpenRoaming and Samsung OneUI Onboarding
    #list iw_roaming_consortium '004096'
    #EDURoam Consortium
    #list iw_roaming_consortium '001BC50460'
    #Orion NAI Realm
    list iw_nai_realm '0,*.orion.area120.com,13[5:6],21[2:4][5:7],23[5:1][5:2],50[5:1][5:2],18[5:1][5:2]'
    #AT&T NAI Realm
    #list iw_nai_realm '0,*wlan.mnc410.mcc310.3gppnetwork.org,13[5:6],21[2:4][5:7],23[5:1][5:2],50[5:1][5:2],18[5:1][5:2]'
    #T-Mobile NAI Realm
    #list iw_nai_realm '0,*wlan.mnc260.mcc310.3gppnetwork.org,13[5:6],21[2:4][5:7],23[5:1][5:2],50[5:1][5:2],18[5:1][5:2]'
    #IronWiFi Realm
    #list iw_nai_realm '0,ironwifi,13[5:6],21[2:4][5:7]'

    # Don't Touch
    # Some options are repeated for legacy support
    # ANQP (Access Network Query Protocol) Domain ID, used to uniquely identify the Passpoint domain.
    option anqp_domain_id '0'
    # Enable BSS (Basic Service Set) transition support for efficient handovers between APs.
    option bss_transition '1'
    # Disable Directed Group Address Forwarding (DGAF) support.
    option disable_dgaf '1'
    # Set disabled to '0' to enable the interface.
    option disabled '0'
    # Identify the ap as a guest access point.
    option guest '1'
    # Enable Hotspot 2.0 support in Passpoint.
    option hotspot20 '1'
    # Enable Hotspot 2.0 (HS2) support in Passpoint.
    option hs20 '1'
    # Set the deauthentication request timeout for Hotspot 2.0.
    option hs20_deauth_req_timeout '60'
    # Enable internet access for the Passpoint network.
    option internet '1'
    # Isolate clients on the Passpoint network for enhanced security.
    option isolate '1'
    # Enable or disable ASRA (ANQP Service Required for Access).
    option iw_asra '0'
    # Disable Directed Group Address Forwarding (DGAF) for Passpoint.
    option iw_disable_dgaf '1'
    # Enable Passpoint functionality.
    option iw_enabled '1'
    # Enable or disable Emergency Services Reachability (ESR) for Passpoint.
    option iw_esr '0'
    # Enable internet access for Passpoint.
    option iw_internet '1'
    # Enable interworking with external networks for Passpoint.
    option iw_interworking '1'
    # Disable UESA (Unauthenticated Emergency Service Availability)
    option iw_uesa '0'
    # Set the mode to 'ap', indicating that the wireless interface is operating in Access Point mode.
    option mode 'ap'
    # Enable the Requested Connectivity to User Information (CUI) feature.
    # CUI is used to request user-specific information during the network selection process and is mandatory for Google Orion.
    option request_cui '1'
    # Enable the WNM (Wireless Network Management) Sleep Mode Transition with No Keys option.
    # This option allows the device to perform sleep mode transitions without exchanging keys, improving efficiency.
    option wnm_sleep_mode_no_keys '1'

Afterwards we need to run two commands:

Fixing 3GPP Bug for Hotspot 2.0 Support on OpenWRT

OpenWRT doesn’t configure hostapd directly. It uses a script at /lib/netifd/hostapd.sh to convert your config at /etc/config/wireless to the appropriate hostapd config. On some distros of OpenWRT there is a bug that prevents 3GPP configurations.

Run the following command on your device to resolve it:

sed -i '/append_iw_anqp_3gpp_cell_net() {/,/}/c\
append_iw_anqp_3gpp_cell_net() {\
    if [ -z "$iw_anqp_3gpp_cell_net_conf" ]; then\
        iw_anqp_3gpp_cell_net_conf="$1";\
    else\
        iw_anqp_3gpp_cell_net_conf="$iw_anqp_3gpp_cell_net_conf;$1";\
    fi\
}' /lib/netifd/hostapd.sh

Just one character is the issue. The script above is fine to run on all devices. It won’t make any changes if the bug isn’t there.

Setting Up Automatic Reboot

We recommend setting up a nightly reboot to clear any issues that may pop up.

The command below should work on most devices:

echo "30 4 * * * sleep 70 && touch /etc/banner && reboot" >> /etc/crontabs/root && /etc/init.d/cron restart

Otherwise, go to System > Scheduled Tasks and enter the following line in the Scheduled Tasks textbox.

30 4 * * * sleep 70 && touch /etc/banner && reboot

Testing Hotspot 2.0 Functionality on OpenWRT

After configuring your interface and performing the 3gpp fix, you’ll run the following command to reload your wireless config:

wifi

Then verify that the interface becomes available:

iwinfo

Example:

phy0-ap0  ESSID: "OrionWiFi"
          Access Point: XX:XX:XX:XX:XX:XX
          Mode: Master  Channel: 6 (2.437 GHz)  HT Mode: HE20
          Center Channel 1: 6 2: unknown
          Tx-Power: 30 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -91 dBm
          Bit Rate: unknown
          Encryption: WPA2 802.1X (CCMP)
          Type: nl80211  HW Mode(s): 802.11ax/b/g/n
          Hardware: embedded [MediaTek MT7986]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy1-ap0  ESSID: "OrionWiFi"
          Access Point: XX:XX:XX:XX:XX:XX
          Mode: Master  Channel: 153 (5.765 GHz)  HT Mode: HE80
          Center Channel 1: 155 2: unknown
          Tx-Power: 30 dBm  Link Quality: 54/70
          Signal: -56 dBm  Noise: -92 dBm
          Bit Rate: 689.1 MBit/s
          Encryption: WPA2 802.1X (CCMP)
          Type: nl80211  HW Mode(s): 802.11ac/ax/n
          Hardware: embedded [MediaTek MT7986]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1
Testing using an Android or IOS Device

If you’re using Goole Orion and you have one of the supported Carriers, such as AT&T or Google Fi, you just need to forget any wifi access points you have saved that are in range. Your phone should automatically see and connect to the appropriate SSID. Otherwise, you’ll need to install the Google Orion Test Profile

If you are not a subscriber to the supported carriers, you’ll need to install the test profile on your device using Safari on IOS or Google Chrome on android. This will enable your device for testing and enable your device to be able to automatically see and connect to the OpenRoaming enabled network for testing.

OpenRoaming and PassPoint Testing Profile Links:

OpenRoaming Profile APPs:

For a full list of OpenRoaming Profiles please check out the WBA Website.

If you’re interested in creating your own provisioning portal, check out the WBA’s Provisioning Portal Demo .

Verifying Hotspot 2.0 Client Capability on Windows

To see whether Passpoint is supported by your Wi-Fi device on Windows 10/11, verify if “ANQP Service Information Discovery” is “Supported”, using the following command:

netsh wlan show wirelesscapabilities

OpenWRT Wireless Config Options Explained

Access Network Type

Configure the Access Network Type using the following format:

Access Network TypeDescription
0Private network
1Private network with guest access
2Chargeable public network
3Free public network
4Personal device network
5Emergency services only network
14Test or experimental
15Wildcard

Explanation:

  • The ‘Access Network Type’ specifies the nature of the network, helping devices categorize and interact appropriately.
  • Choose the appropriate number to define the desired network type.
Example Usage:

To set the Access Network Type to ‘Chargeable public network’:

option iw_access_network_type '2'

This example illustrates how to configure the Access Network Type. Adjust the value based on the characteristics of your network.

Configuring the Access Network Type provides crucial information about the nature of the network, aiding devices in understanding the available services and connectivity options.

Venue Info (Optional)

Configure Venue Information using the following format:

Group, Type

IEEE Std 802.11u-2011 Venue Group and Type Values:

Here are the individual tables for each the venue groups and venue types:

Venue Groups

Venue Group NameValue
UNSPECIFIED0
ASSEMBLY1
BUSINESS2
EDUCATIONAL3
FACTORY-INDUSTRIAL4
INSTITUTIONAL5
MERCANTILE6
RESIDENTIAL7
STORAGE8
UTILITY-MISC9
VEHICULAR10
OUTDOOR11

Venue Types for UNSPECIFIED ASSEMBLY (Group Value: 1)

Venue Type ValueVenue Type Description
0UNSPECIFIED ASSEMBLY
1ARENA
2STADIUM
3PASSENGER TERMINAL (E.G., AIRPORT, BUS, FERRY, TRAIN STATION)
4AMPHITHEATER
5AMUSEMENT PARK
6PLACE OF WORSHIP
7CONVENTION CENTER
8LIBRARY
9MUSEUM
10RESTAURANT
11THEATER
12BAR
13COFFEE SHOP
14ZOO OR AQUARIUM
15EMERGENCY COORDINATION CENTER

Venue Types for UNSPECIFIED BUSINESS (Group Value: 2)

Venue Type ValueVenue Type Description
0UNSPECIFIED BUSINESS
1DOCTOR OR DENTIST OFFICE
2BANK
3FIRE STATION
4POLICE STATION
6POST OFFICE
7PROFESSIONAL OFFICE
8RESEARCH AND DEVELOPMENT FACILITY
9ATTORNEY OFFICE

Venue Types for UNSPECIFIED EDUCATIONAL (Group Value: 3)

Venue Type ValueVenue Type Description
0UNSPECIFIED EDUCATIONAL
1SCHOOL, PRIMARY
2SCHOOL, SECONDARY
3UNIVERSITY OR COLLEGE

Venue Types for UNSPECIFIED FACTORY AND INDUSTRIAL (Group Value: 4)

Venue Type ValueVenue Type Description
0UNSPECIFIED FACTORY AND INDUSTRIAL
1FACTORY

Venue Types for UNSPECIFIED INSTITUTIONAL (Group Value: 5)

Venue Type ValueVenue Type Description
0UNSPECIFIED INSTITUTIONAL
1HOSPITAL
2LONG-TERM CARE FACILITY (E.G., NURSING HOME, HOSPICE, ETC.)
3ALCOHOL AND DRUG RE-HABILITATION CENTER
4GROUP HOME
5PRISON OR JAIL

Venue Types for UNSPECIFIED MERCANTILE (Group Value: 6)

Venue Type ValueVenue Type Description
0UNSPECIFIED MERCANTILE
1RETAIL STORE
2GROCERY MARKET
3AUTOMOTIVE SERVICE STATION
4SHOPPING MALL
5GAS STATION

Venue Types for UNSPECIFIED RESIDENTIAL (Group Value: 7)

Venue Type ValueVenue Type Description
0UNSPECIFIED RESIDENTIAL
1PRIVATE RESIDENCE
2HOTEL OR MOTEL
3DORMITORY
4BOARDING HOUSE

Venue Types for UNSPECIFIED STORAGE (Group Value: 8)

Venue Type ValueVenue Type Description
0UNSPECIFIED STORAGE

Venue Types for UNSPECIFIED UTILITY AND MISCELLANEOUS (Group Value: 9)

Venue Type ValueVenue Type Description
0UNSPECIFIED UTILITY AND MISCELLANEOUS

Venue Types for UNSPECIFIED VEHICULAR (Group Value: 10)

Venue Type ValueVenue Type Description
0UNSPECIFIED VEHICULAR
1AUTOMOBILE OR TRUCK
2AIRPLANE
3BUS
4FERRY
5SHIP OR BOAT
6TRAIN
7MOTOR BIKE

Venue Types for UNSPECIFIED OUTDOOR (Group Value: 11)

Venue Type ValueVenue Type Description
0UNSPECIFIED OUTDOOR
1MUNI-MESH NETWORK
2CITY PARK
3REST AREA
4TRAFFIC CONTROL
5BUS STOP
6KIOSK

Explanation:

  • Venue Information allows you to specify the group and type based on IEEE Std 802.11u-2011, 7.3.1.34 .
  • The ‘Group’ parameter represents a broader category, while ‘Type’ specifies the specific venue type within that group.
Example Usage:
  • To set the Venue Group to ‘Convention Center’:
option iw_venue_group '1'
  • To set the Venue Type to ‘Coffee Shop’:
option iw_venue_type '13'

These examples demonstrate how to configure Venue Information. Adjust the values according to your specific venue details.

This configuration provides additional information about the network, helping devices identify and connect based on the specified venue characteristics.

NAI Realm Information

One or more realms can be advertised, with each nai_realm line adding a new realm to the set. These parameters provide information for stations using Interworking network selection to facilitate automatic connection to a network based on credentials.

Format: <Encoding>,<NAI Realm(s)>[,<EAP Method 1>][,<EAP Method 2>][,...]

Encoding

Choose the encoding format for the realm. The following options are available:

Realm FormatDescription
0Realm formatted in accordance with IETF RFC 4282
1UTF-8 formatted character string not following RFC 4282

NAI Realm(s): Semi-colon delimited NAI Realm(s)

EAP Method: <EAP Method>[:<[AuthParam1:Val1]>][<[AuthParam2:Val2]>][...]

For EAP Method types, refer to AuthParam (Table 8-188 in IEEE Std 802.11-2012) .

ID 2 = Non-EAP Inner Authentication Type

IDAuthentication Type
1PAP
2CHAP
3MSCHAP
4MSCHAPV2

ID 3 = Inner Authentication EAP Method Type

No specific values.

ID 5 = Credential Type

IDCredential Type
1SIM
2USIM
3NFC Secure Element
4Hardware Token
5Softoken
6Certificate
7Username/Password
9Anonymous
10Vendor Specific

Examples:

  • list iw_nai_realm '0,example.com;example.net'
  • list iw_nai_realm '0,example.org,13[5:6],21[2:4][5:7]'

These examples demonstrate configuring EAP methods such as EAP-TLS with a certificate and EAP-TTLS/MSCHAPv2 with a username/password. Adjust the parameters based on your specific requirements.

WAN Metrics (Optional)

Configure WAN Metrics using the following format:

<WAN Info>:<DL Speed>:<UL Speed>:<DL Load>:<UL Load>:<LMD>

WAN Info: B0-B1: Link Status, B2: Symmetric Link, B3: Capability (encoded as two hex digits)

  • Link Status: 1 = Link up, 2 = Link down, 3 = Link in test state

  • Downlink Speed: Estimate of WAN backhaul link current downlink speed in kbps (1..4294967295; 0 = unknown)

  • Uplink Speed: Estimate of WAN backhaul link current uplink speed in kbps (1..4294967295; 0 = unknown)

  • Downlink Load: Current load of downlink WAN connection (scaled to 255 = 100%)

  • Uplink Load: Current load of uplink WAN connection (scaled to 255 = 100%)

  • Load Measurement Duration: Duration for measuring downlink/uplink load in tenths of a second (1..65535); 0 if load cannot be determined

Example:

option hs20_wan_metrics '01:8000:1000:80:240:3000'

This example sets WAN Metrics with link status up, downlink speed of 8000 kbps, uplink speed of 1000 kbps, 80% downlink load, 24% uplink load, and a load measurement duration of 3000 tenths of a second. Adjust the values based on your specific WAN characteristics.

IP Address Type Availability

Configure IP Address Type Availability using the following format:

<1-octet encoded value as hex str> ((ipv4_type & 0x3f) << 2) | (ipv6_type & 0x3)

ipv4 type:
IPv4 TypeDescription
0Address type not available
1Public IPv4 address available
2Port-restricted IPv4 address available
3Single NATed private IPv4 address available
4Double NATed private IPv4 address available
5Port-restricted IPv4 address and single NATed IPv4 address available
6Port-restricted IPv4 address and double NATed IPv4 address available
7Availability of the address type is not known
ipv6 type:
IPv6 TypeDescription
0Address type not available
1Address type available
2Availability of the address type not known

Explanation:

  • The configuration format involves a 1-octet encoded value as a hexadecimal string.
  • For IPv4 type, it combines bits using bitwise operations to represent the type of IPv4 address availability.
  • For IPv6 type, it represents the availability of the address type.

Example Usage:

option iw_ipaddr_type_availability '11'

This example sets IP Address Type Availability with IPv4 type available and IPv6 type available. Adjust the values based on your specific requirements.

This configuration informs the system that both public IPv4 and available IPv6 addresses can be used. The ‘11’ is a combination of the binary representation for IPv4 availability (01) and IPv6 availability (01).

Troubleshooting OpenWRT and Best Practices for Hotspot 2.0

Hostapd Configuration Checks

Before delving into troubleshooting, it’s crucial to perform thorough checks on the Hostapd configuration. Start by examining the configuration file located at /var/run/hostapd-phyX.conf for any errors or inconsistencies. Use the following command to review the specific configuration file for a particular interface:

cat /var/run/hostapd-phyX.conf | grep bssid

Ensure that the MAC address specified in the configuration matches the actual MAC address of the wireless interface. Verify this by checking the MAC address in both /sys/class/ieee80211/phyX/macaddress and /var/run/hostapd-phyX.conf.

Debugging Hostapd Execution

When encountering issues, it’s beneficial to run Hostapd in debug mode to gather detailed information about the initialization process. Execute the following commands for the respective interfaces, replacing X with the appropriate interface number:

hostapd -dddd -B -P /var/run/hostapd-phyX.pid /var/run/hostapd-phyX.conf

Examine the debug output for any error messages or warnings that might provide insights into the cause of the problem.

Luci Configuration Page

If the wireless interface fails to start, the Luci configuration page offers a convenient way to troubleshoot and resolve issues. Follow these steps:

  1. Access the Luci web interface.
  2. Navigate to the configuration page for the problematic wireless interface.
  3. Disable the proxyarp option, save the configuration changes.
  4. Click “Save & Apply”

Check the system logs using logread for any error messages during this reconfiguration phase.

Note: We understand that per spec that proxyarp should be left on if at all possible. However, we did have a number of OpenWRT devices have issues with this.

Channel and Power Level Settings

Some devices and radios may require specific channel and power level configurations for optimal performance. Verify that the channel and power settings align with the hardware specifications of your wireless device. Incorrect settings can lead to interface startup failures.

Always consult the device documentation or specifications to determine the recommended channel and power level configurations. Adjust the settings accordingly in the wireless configuration file or luci interface.

By meticulously examining these aspects and following the outlined steps, you can troubleshoot common issues associated with Hostapd and enhance the stability of your Hotspot 2.0 implementation.

Q&A Section

Q1: What is Hotspot 2.0 / Passpoint 2.0?

Hotspot 2.0, also known as Passpoint 2.0, is a Wi-Fi Alliance certification program that enhances the connectivity experience by providing seamless and secure Wi-Fi access. It simplifies the process of connecting to Wi-Fi networks, especially in public spaces, by automating the authentication and connection procedures.

Q2: Why is Hotspot 2.0 relevant for OpenWRT users?

OpenWRT users can benefit from Hotspot 2.0 by creating advanced wireless networks that offer improved security, automatic connection, and a seamless user experience. It is particularly useful for environments where multiple access points are deployed, such as public spaces, businesses, and large-scale deployments.

Q3: What are the prerequisites for setting up Hotspot 2.0 on OpenWRT?

Before configuring Hotspot 2.0 on OpenWRT, ensure the following prerequisites are met:

  • OpenWRT-compatible device with a Passpoint-capable wireless device (PHY).
  • OpenWRT version 21.02 or newer, including wpad built with the hs20 option.
  • Full version of the iw package in OpenWRT.
  • An 802.1x infrastructure with a RADIUS server.
  • Information about the assigned RADIUS servers, including IP address, port numbers, and shared secrets.
  • Advanced command line experience (prefered but optional)
  • Linux and troubleshooting experience (prefered but optional)

Q4: How can I check if my device supports Hotspot 2.0?

You can check if your device supports Hotspot 2.0 by examining the installed wpad package. Run the following command:

strings /usr/sbin/wpad | grep hs20

If nothing shows up, your wpad version doesn’t support Hotspot 2.0, and you may need to install a compatible version.

Q5: Can I use USB external WiFi cards for Hotspot 2.0 support on OpenWRT?

Yes, USB external WiFi cards can be used on OpenWRT for Hotspot 2.0 support. We recommend specific adapters with OpenWRT compatibility and 802.11 AX support for an optimal experience.

Q6: How do I troubleshoot issues with Hotspot 2.0 on OpenWRT?

If you encounter issues, you can troubleshoot by checking the configuration files, verifying MAC addresses, and ensuring proper settings in the Luci configuration page. Additionally, for interface startup issues, disable and re-enable proxyarp in the Luci configuration.

Certainly! Here are the additional questions and answers in markdown format:

Q7: Is Passpoint Secure?

Securing Wi-Fi connections is a crucial aspect of networking, and Passpoint ensures security by mandating the use of Protected Management Frames for all connections. It leverages the EEE 802.11u specification, a version of 802.1x, and is restricted to access points and devices capable of WPA2 and WPA3 authentication, specifically using the EAP authentication protocol – the current industry standard for network security.

Q8: Does Passpoint support voice mobile data offload over Wi-Fi?

Passpoint technologies play a key role in supporting mobile data offload, benefiting both mobile operators and internet service providers. Passpoint enables seamless connectivity and improved performance for voice and mobile data over Wi-Fi.

Q9: What does Passpoint bring to hospitality?

For hospitality chains with multiple brands and a consolidated rewards program, Passpoint simplifies connectivity. Instead of adding the rewards program SSID at every hotel, Passpoint functions with a single profile identifying the rewards program. When users visit associated properties, their devices automatically identify the access points and connect.

Q10: How does Passpoint support service provider branding and customer relationships?

Passpoint-enabled devices can choose networks based on preferred providers, specific services, or performance characteristics. For service providers offering a managed experience, seamless authentication is valuable, and Passpoint networks also support deployments where a click-through screen is essential for terms and conditions or branding acceptance.

Q11: How does Passpoint equipment support Wi-Fi roaming?

Passpoint devices use industry-agreed mechanisms for discovering and creating secured connections to hotspots, ensuring seamless Wi-Fi connectivity globally for subscribers with roaming agreements. Passpoint is specified as a requirement for the Wireless Broadband Alliance’s industry work on Wi-Fi roaming.

Q12: What standards does Passpoint draw on?

Passpoint utilizes elements of IEEE 802.1X, 802.11u, 802.11i, and WPA3™-Enterprise security, along with Wi-Fi Alliance-defined mechanisms, to enhance Wi-Fi connectivity.

Q13: Who created the Passpoint program?

Members of the Wi-Fi Alliance, including service providers, mobile operators, fixed-line operators, and makers of mobile devices and infrastructure equipment, created the Passpoint program.

Q14: What does Passpoint mean for end users?

Passpoint provides a superior Wi-Fi user experience for mobile users. Certified Passpoint devices offer streamlined network selection, secure connectivity at Passpoint-enabled hotspots, and operation based on user preferences.

Q15: Can existing equipment be upgraded for Passpoint?

Most existing silicon is Passpoint capable, and the upgrade possibility depends on the hardware and software platform of a given device. Equipment that has undergone certification testing can be updated and resubmitted for Passpoint certification.

Q16: Can legacy clients join a network with Passpoint access points?

Legacy mobile devices can connect to Passpoint access points configured for open system authentication but won’t enjoy Passpoint features. Supporting both a Passpoint-certified network and a separate open network on the same access points allows Passpoint mobile devices to benefit while supporting legacy clients.

Q17: Does Passpoint support voice over Wi-Fi?

Passpoint is application-agnostic and serves as a key enabler for various applications, including voice over Wi-Fi. The scope of Passpoint testing ensures correct implementation of mechanisms for seamless discovery and creation of a secured link.

Conclusion

Implementing Hotspot 2.0 on OpenWRT provides a robust solution for enhancing Wi-Fi connectivity. From improving user experience to addressing security concerns, this technology plays a pivotal role in modern wireless networks. By following the outlined steps and best practices, you can create a seamless and secure Hotspot 2.0-enabled environment.

References