Kiwire docs

Appearance

Other controllers ​

Every device type that does not have its own setup guide: where it stands today, and what to set for the ones you can deploy.

For the vendors with their own page (MikroTik, Meraki, Cisco WLC, Huawei, TP-Link Omada, Aruba, Ubiquiti, Ruckus, Fortinet, Ruijie / WiFiDog, H3C, Allied Telesis) see Connecting a controller.

Status ​

Device typeStatusNotes
Cambium cnMaestroAvailableListed in Kiwire as Cambium. Setup below.
EnGeniusAvailableSetup below.
Juniper MistNot available yetListed as Mist. A guest login does not complete on this controller type today; contact Synchroweb.
Motorola / Zebra WiNGAvailableListed as Zebra Wifi. Setup below.
XirrusAvailableSetup below.
Zyxel APAvailableListed in the Vendor list. Setup below.
PeplinkAvailableListed in the Vendor list. Setup below.
SonicWallNot available yetListed as SonicWall. SonicOS external guest authentication uses its own message exchange with the portal server, which Kiwire does not perform today; contact Synchroweb.
SundrayNot available yetA guest login does not complete on this controller type today; contact Synchroweb.
CMCCNot available yetA guest login does not complete on this controller type today; contact Synchroweb.
Nomadix gatewayAvailableListed as Nomadix. Setup below.
Nomadix (XML API)Available through SynchrowebListed as Nomadix - XML. Setup below.
ChilliSpot / CoovaChilliAvailableListed as Chillispot. Setup below.
pfSenseAvailableListed as Pfsense. Setup below.
Other / generic RADIUSAvailableListed as Other. For a gateway that can redirect with parameter names you choose; see Other / generic.
Virtual NAS—Not a controller type of its own: it is an extra record for the name a cloud controller sends in RADIUS. See Identity and Virtual NAS.

Status: not available yet means the controller type is listed in Kiwire but a guest login does not complete on it today. Contact Synchroweb before deploying one.

Controller-side steps on this page are shorter than on the vendors with their own guide. Where a step could not be checked against the vendor's own documentation it says so; the values Kiwire needs are what matter, and Controller Test shows whether they arrive.

Before you start (all types) ​

From Kiwire:

  • the RADIUS server address shown in the Setup Guide checklist ("Before you add your controller" › "RADIUS Authentication & Accounting"), written <radius-server-ip> below;
  • a shared secret of at most 64 characters, written <shared-secret>;
  • <kiwire-host>, the host name of your portal.

On the device: admin access, the guest SSID or interface, and the identifier the device sends (listed per type below).

Cambium ​

Device type in KiwireCambium
Redirect URLhttps://<kiwire-host>/login/cambium
RADIUSauth 1812 / acct 1813 (UDP)
Identity must equalthe NAS ID the AP sends as ga_nas_id in the redirect, and the NAS-Identifier it sends in RADIUS (make them the same)
Disconnect / live changes (CoA)standard RADIUS CoA / Disconnect to the AP's IP Address, port 3799 by default
Data capsKiwire sends Cambium's own traffic-quota attribute, plus time limits
How a guest logs in through Cambium and Kiwire The guest joins the Wi-Fi and opens a page. The Cambium device redirects the browser to Kiwire at /login/cambium. Kiwire shows the portal and the guest signs in. Kiwire hands the login back to the device: POST AP:880 hotspot_login.cgi. The device then asks Kiwire over RADIUS, identifying itself with ga_nas_id = NAS-ID. Kiwire accepts and returns the profile's limits, the device lets the guest out and starts sending accounting. Later, Kiwire can disconnect the guest or change their limits with CoA on port 3799.Guest devicephone, laptopCambiumcnPilot AP / cnMaestroKiwireportal + RADIUSInternetafter acceptance1 JOINS THE SSID, OPENS A PAGE2 REDIRECT TO/login/cambium3 PORTAL PAGE — THE GUEST SIGNS IN4 HAND-BACK:POST AP:880 hotspot_login.cgi5 RADIUS REQUEST — IDENTITY =ga_nas_id = NAS-ID6 ACCEPT + PROFILE LIMITS7 GUEST IS LET OUT; ACCOUNTING STARTS8 LATER: DISCONNECT / CHANGE LIMITS (CoA, PORT 3799)
Steps 2 and 4 are the controller's side of the portal, step 5 is its RADIUS side. When the page loads but the login never completes, the break is almost always at step 4 (the login address) or step 5 (the Identity or the shared secret).

How the login finishes. The AP's redirect carries ga_srvr (the AP's address), ga_cmac (guest MAC), ga_nas_id, ga_ssid, ga_orig_url and a token ga_Qv. After the portal, the guest's browser posts ga_user and ga_pass to http://<ga_srvr>:880/cgi-bin/hotspot_login.cgi, with ga_Qv and the original page on the address, as Cambium's guest-access integration guide describes. The AP then checks the credentials against Kiwire over RADIUS.

On the AP or in cnMaestro (menu names vary between firmware versions; the values are what matter):

  1. WLAN › Guest Access: enable, portal mode External Hotspot, redirect / splash URL https://<kiwire-host>/login/cambium.
  2. RADIUS authentication server <radius-server-ip> port 1812 and accounting server port 1813, <shared-secret>; set the NAS ID to a fixed name, for example site1-cambium.
  3. Walled garden: <kiwire-host> and the hosts in Walled garden.

In Kiwire. Vendor Cambium, Identity = the NAS ID (site1-cambium), the AP's IP Address and COA Port 3799.

Test it. Controller Test should show ga_srvr, ga_cmac, ga_nas_id and ga_Qv. Then log in as a guest.

Limits. Data caps depend on the AP applying Cambium's traffic-quota attribute; check a test guest's usage under Reporting before relying on them.

EnGenius ​

Device type in KiwireEnGenius
Redirect URLhttps://<kiwire-host>/login/engenius
RADIUSauth 1812 / acct 1813 (UDP)
Identity must equalthe nas_id inside the AP's actionurl, and the NAS-Identifier the AP sends in RADIUS
Disconnect / live changes (CoA)standard RADIUS CoA / Disconnect to the AP's IP Address, port 3799 by default — only if the AP accepts them
Data capstime limits only (Session-Timeout)
How a guest logs in through EnGenius and Kiwire The guest joins the Wi-Fi and opens a page. The EnGenius device redirects the browser to Kiwire at /login/engenius. Kiwire shows the portal and the guest signs in. Kiwire hands the login back to the device: POST to actionurl. The device then asks Kiwire over RADIUS, identifying itself with nas_id / NAS-ID. Kiwire accepts and returns the profile's limits, the device lets the guest out and starts sending accounting. Later, Kiwire can disconnect the guest or change their limits with CoA on port 3799.Guest devicephone, laptopEnGeniusAP / EnGenius CloudKiwireportal + RADIUSInternetafter acceptance1 JOINS THE SSID, OPENS A PAGE2 REDIRECT TO/login/engenius3 PORTAL PAGE — THE GUEST SIGNS IN4 HAND-BACK:POST to actionurl5 RADIUS REQUEST — IDENTITY =nas_id / NAS-ID6 ACCEPT + PROFILE LIMITS7 GUEST IS LET OUT; ACCOUNTING STARTS8 LATER: DISCONNECT / CHANGE LIMITS (CoA, PORT 3799)
Steps 2 and 4 are the controller's side of the portal, step 5 is its RADIUS side. When the page loads but the login never completes, the break is almost always at step 4 (the login address) or step 5 (the Identity or the shared secret).

What Kiwire expects in the redirect. EnGenius packs everything into one parameter, actionurl: its query holds client_mac, client_ip, userurl, ap_ip, nas_id, vlan and ssidProfileId. Kiwire unpacks it, and after the portal posts username, password and userurl (the original page) to that same actionurl. The AP then checks the credentials against Kiwire over RADIUS.

On the AP or in EnGenius Cloud (menu names vary by firmware version):

  1. Captive portal / guest SSID with an external splash page https://<kiwire-host>/login/engenius and RADIUS authentication.
  2. RADIUS server <radius-server-ip>, auth 1812, accounting 1813, <shared-secret>.
  3. Walled garden: <kiwire-host> and the hosts in Walled garden.

In Kiwire. Vendor EnGenius, Identity = the nas_id value (Controller Test shows it), the AP's IP Address and COA Port 3799.

Test it. In Controller Test, check that the guest MAC, nas_id and the login address are all found. If the guest MAC is missing, contact Synchroweb: some firmware places it where it cannot be read.

Limits. No data caps.

Motorola / Zebra WiNG ​

Device type in KiwireZebra Wifi
Redirect URLhttps://<kiwire-host>/login/motorola
RADIUSauth 1812 / acct 1813 (UDP)
Identity must equalthe AP MAC inside the controller's Qv value, and the NAS-Identifier it sends in RADIUS
Disconnect / live changes (CoA)standard RADIUS CoA / Disconnect to the controller's IP Address, port 3799 by default — only if it accepts them
Data capstime limits only (Session-Timeout)
How a guest logs in through Zebra WiNG and Kiwire The guest joins the Wi-Fi and opens a page. The Zebra WiNG device redirects the browser to Kiwire at /login/motorola. Kiwire shows the portal and the guest signs in. Kiwire hands the login back to the device: POST hs_server:880 hslogin.cgi. The device then asks Kiwire over RADIUS, identifying itself with AP MAC (from Qv) / NAS-ID. Kiwire accepts and returns the profile's limits, the device lets the guest out and starts sending accounting. Later, Kiwire can disconnect the guest or change their limits with CoA on port 3799.Guest devicephone, laptopZebra WiNGWiNG controller / APKiwireportal + RADIUSInternetafter acceptance1 JOINS THE SSID, OPENS A PAGE2 REDIRECT TO/login/motorola3 PORTAL PAGE — THE GUEST SIGNS IN4 HAND-BACK:POST hs_server:880 hslogin.cgi5 RADIUS REQUEST — IDENTITY =AP MAC (from Qv) / NAS-ID6 ACCEPT + PROFILE LIMITS7 GUEST IS LET OUT; ACCOUNTING STARTS8 LATER: DISCONNECT / CHANGE LIMITS (CoA, PORT 3799)
Steps 2 and 4 are the controller's side of the portal, step 5 is its RADIUS side. When the page loads but the login never completes, the break is almost always at step 4 (the login address) or step 5 (the Identity or the shared secret).

What Kiwire expects in the redirect. WiNG sends an encoded Qv value and the hotspot server address hs_server. Kiwire decodes Qv to find the guest MAC, the AP MAC and the SSID. After the portal, the guest's browser posts f_user, f_pass, f_hs_server and f_Qv to http://<hs_server>:880/cgi-bin/hslogin.cgi, and WiNG checks the credentials against Kiwire over RADIUS.

On the controller (menu names vary by firmware version):

  1. Captive portal policy with externally hosted pages at https://<kiwire-host>/login/motorola and RADIUS authentication.
  2. RADIUS server <radius-server-ip>, auth 1812, accounting 1813, <shared-secret>.
  3. Walled garden / allowed hosts: <kiwire-host> and the hosts in Walled garden.

In Kiwire. Vendor Zebra Wifi, Identity = the AP MAC as decoded (Controller Test shows it). If the NAS-Identifier WiNG sends in RADIUS is different, add a record for it too — see Identity and Virtual NAS.

Limits. No data caps.

Xirrus ​

Device type in KiwireXirrus
Redirect URLhttps://<kiwire-host>/login/xirrus
RADIUSauth 1812 / acct 1813 (UDP)
Identity must equalthe nasid in the redirect (or apmac when the AP sends no nasid), and the NAS-Identifier it sends in RADIUS
Disconnect / live changes (CoA)standard RADIUS CoA / Disconnect to the AP's IP Address, port 3799 by default — only if the AP accepts them
Data capstime limits only (Session-Timeout)
How a guest logs in through Xirrus and Kiwire The guest joins the Wi-Fi and opens a page. The Xirrus device redirects the browser to Kiwire at /login/xirrus. Kiwire shows the portal and the guest signs in. Kiwire hands the login back to the device: GET uamip:uamport/logon. The device then asks Kiwire over RADIUS, identifying itself with nasid (or apmac) / NAS-ID. Kiwire accepts and returns the profile's limits, the device lets the guest out and starts sending accounting. Later, Kiwire can disconnect the guest or change their limits with CoA on port 3799.Guest devicephone, laptopXirrusXirrus AP / arrayKiwireportal + RADIUSInternetafter acceptance1 JOINS THE SSID, OPENS A PAGE2 REDIRECT TO/login/xirrus3 PORTAL PAGE — THE GUEST SIGNS IN4 HAND-BACK:GET uamip:uamport/logon5 RADIUS REQUEST — IDENTITY =nasid (or apmac) / NAS-ID6 ACCEPT + PROFILE LIMITS7 GUEST IS LET OUT; ACCOUNTING STARTS8 LATER: DISCONNECT / CHANGE LIMITS (CoA, PORT 3799)
Steps 2 and 4 are the controller's side of the portal, step 5 is its RADIUS side. When the page loads but the login never completes, the break is almost always at step 4 (the login address) or step 5 (the Identity or the shared secret).

How the login finishes. Xirrus uses a ChilliSpot-style exchange. The redirect carries mac, uamip, uamport, a challenge chal, nasid, userurl, ssid and vlan. After the portal, the guest's browser opens http://<uamip>:<uamport>/logon with the username, a hashed response and the original page. The AP checks the login against Kiwire over RADIUS and sends the browser back to Kiwire with res=success, and Kiwire sends the guest on to the page they first asked for.

The shared UAM secret is the Identity. Kiwire signs the hashed response with the controller's Identity as the UAM secret. Set the AP's portal / UAM secret to exactly the same text as the Identity. (The name of this setting varies by firmware version.)

On the AP (menu names vary by firmware version): web page redirect / external portal to https://<kiwire-host>/login/xirrus, RADIUS <radius-server-ip> 1812 / 1813 with <shared-secret>, and <kiwire-host> plus the hosts in Walled garden allowed before login.

Limits. No data caps.

ChilliSpot / CoovaChilli ​

Device type in KiwireChillispot
Redirect URLhttps://<kiwire-host>/login/chillispot (CoovaChilli's uamserver)
RADIUSauth 1812 / acct 1813 (UDP)
Identity must equalthe nasid in the redirect (radiusnasid; apmac is used when no nasid is sent), and the NAS-Identifier in RADIUS — the same value
Disconnect / live changes (CoA)yes, port 3799 (CoovaChilli's coaport)
Data capsyes — Kiwire sends ChilliSpot's data-cap attribute, plus time limits
How a guest logs in through CoovaChilli and Kiwire The guest joins the Wi-Fi and opens a page. The CoovaChilli device redirects the browser to Kiwire at /login/chillispot. Kiwire shows the portal and the guest signs in. Kiwire hands the login back to the device: GET uamip:uamport/logon. The device then asks Kiwire over RADIUS, identifying itself with radiusnasid (nasid). Kiwire accepts and returns the profile's limits, the device lets the guest out and starts sending accounting. Later, Kiwire can disconnect the guest or change their limits with CoA on port 3799.Guest devicephone, laptopCoovaChilliChilliSpot gatewayKiwireportal + RADIUSInternetafter acceptance1 JOINS THE SSID, OPENS A PAGE2 REDIRECT TO/login/chillispot3 PORTAL PAGE — THE GUEST SIGNS IN4 HAND-BACK:GET uamip:uamport/logon5 RADIUS REQUEST — IDENTITY =radiusnasid (nasid)6 ACCEPT + PROFILE LIMITS7 GUEST IS LET OUT; ACCOUNTING STARTS8 LATER: DISCONNECT / CHANGE LIMITS (CoA, PORT 3799)
Steps 2 and 4 are the controller's side of the portal, step 5 is its RADIUS side. When the page loads but the login never completes, the break is almost always at step 4 (the login address) or step 5 (the Identity or the shared secret).

How the login finishes. CoovaChilli redirects with uamip, uamport, challenge, nasid, mac, userurl, ssid and vlan. After the portal, the guest's browser opens http://<uamip>:<uamport>/logon with the username and the password encoded with the challenge and the UAM secret. CoovaChilli checks them against Kiwire over RADIUS, then sends the browser back to Kiwire with res=success, and Kiwire sends the guest on to their original page.

One secret for everything. Kiwire encodes the password with the record's Shared Secret Key, so the gateway's uamsecret and its RADIUS secret must both be <shared-secret> (64 characters at most).

On the gateway (chilli.conf option names from the CoovaChilli manual; packaged builds such as OpenWrt use their own names for the same settings):

radiusserver1   <radius-server-ip>
radiusauthport  1812
radiusacctport  1813
radiussecret    <shared-secret>
radiusnasid     site1-chilli
uamserver       https://<kiwire-host>/login/chillispot
uamsecret       <shared-secret>
uamallowed      <kiwire-host>,fonts.googleapis.com,fonts.gstatic.com
coaport         3799
coanoipcheck

coanoipcheck is needed because Kiwire's disconnects come from Kiwire's application server, not from the RADIUS server address. Add the other hosts in Walled garden to uamallowed.

In Kiwire. Vendor Chillispot, Identity = site1-chilli (the radiusnasid), Shared Secret Key = <shared-secret>, the gateway's IP Address and COA Port 3799.

Test it. Controller Test should show uamip, uamport, challenge and nasid. A wrong uamsecret shows as a rejected password for every guest.

Limits. Data caps above 4 GB are sent as the 4 GB maximum when a profile is changed on a live session.

pfSense ​

Device type in KiwirePfsense
Redirect URLhttps://<kiwire-host>/login/pfsense — from a custom portal page on pfSense (below)
RADIUSauth 1812 / acct 1813 (UDP)
Identity must equalCaptivePortal-<zone name> — pfSense's default RADIUS NAS Identifier for the zone
Disconnect / live changes (CoA)no
Data capstime limits only (Session-Timeout)
How a guest logs in through pfSense and Kiwire The guest joins the Wi-Fi and opens a page. The pfSense device redirects the browser to Kiwire at /login/pfsense. Kiwire shows the portal and the guest signs in. Kiwire hands the login back to the device: POST to PORTAL_ACTION. The device then asks Kiwire over RADIUS, identifying itself with CaptivePortal-(zone name). Kiwire accepts and returns the profile's limits, the device lets the guest out and starts sending accounting. Guest devicephone, laptoppfSensecaptive portal zoneKiwireportal + RADIUSInternetafter acceptance1 JOINS THE SSID, OPENS A PAGE2 REDIRECT TO/login/pfsense3 PORTAL PAGE — THE GUEST SIGNS IN4 HAND-BACK:POST to PORTAL_ACTION5 RADIUS REQUEST — IDENTITY =CaptivePortal-(zone name)6 ACCEPT + PROFILE LIMITS7 GUEST IS LET OUT; ACCOUNTING STARTS
Steps 2 and 4 are the controller's side of the portal, step 5 is its RADIUS side. When the page loads but the login never completes, the break is almost always at step 4 (the login address) or step 5 (the Identity or the shared secret).

How the login finishes. pfSense does not send guests to an external portal by itself: its custom portal page sends them to Kiwire with the login address, guest MAC, guest IP and zone. After the portal, the guest's browser posts auth_user, auth_pass, redirurl, zone and accept to pfSense's login address — the form pfSense's documentation describes — and pfSense checks the credentials against Kiwire over RADIUS.

On pfSense (Services › Captive Portal › the zone):

  1. Authentication: RADIUS, primary server <radius-server-ip> port 1812, <shared-secret>; RADIUS accounting on, port 1813. Leave NAS Identifier empty so pfSense sends its default, CaptivePortal-<zone name>.
  2. Use custom captive portal page and upload a portal page that forwards the guest to https://<kiwire-host>/login/pfsense?loginurl=$PORTAL_ACTION$&zone=$PORTAL_ZONE$&CLIENT_MAC=$CLIENT_MAC$&CLIENT_IP=$CLIENT_IP$. Check with Controller Test that CLIENT_MAC and CLIENT_IP arrive filled in; the MAC and IP variables depend on the pfSense version.
  3. Allowed Hostnames: <kiwire-host> and the hosts in Walled garden.
  4. After authentication Redirection URL: where guests land after login.

In Kiwire. Vendor Pfsense, Identity = CaptivePortal- followed by the zone name exactly as pfSense shows it (for example CaptivePortal-guests), Shared Secret Key = <shared-secret>. If you set your own NAS Identifier on pfSense, add a record for that value too.

Limits. No disconnects or live profile changes. Kiwire sends data caps with pfSense's own attribute (up to 4 GiB), plus time limits.

Nomadix gateway ​

Device type in KiwireNomadix
Redirect URLhttps://<kiwire-host>/login/nomadix
RADIUSauth 1812 / acct 1813 (UDP)
Identity must equalthe gateway's node ID it sends as NI in the redirect, and the NAS-Identifier it sends in RADIUS
Disconnect / live changes (CoA)standard RADIUS CoA / Disconnect to the gateway's IP Address, port 3799 by default — only if the gateway accepts them
Data capstime limits only (Session-Timeout)
How a guest logs in through Nomadix and Kiwire The guest joins the Wi-Fi and opens a page. The Nomadix device redirects the browser to Kiwire at /login/nomadix. Kiwire shows the portal and the guest signs in. Kiwire hands the login back to the device: GET login.nomadix.com:1111. The device then asks Kiwire over RADIUS, identifying itself with node ID (NI) / NAS-ID. Kiwire accepts and returns the profile's limits, the device lets the guest out and starts sending accounting. Later, Kiwire can disconnect the guest or change their limits with CoA on port 3799.Guest devicephone, laptopNomadixaccess gatewayKiwireportal + RADIUSInternetafter acceptance1 JOINS THE SSID, OPENS A PAGE2 REDIRECT TO/login/nomadix3 PORTAL PAGE — THE GUEST SIGNS IN4 HAND-BACK:GET login.nomadix.com:11115 RADIUS REQUEST — IDENTITY =node ID (NI) / NAS-ID6 ACCEPT + PROFILE LIMITS7 GUEST IS LET OUT; ACCOUNTING STARTS8 LATER: DISCONNECT / CHANGE LIMITS (CoA, PORT 3799)
Steps 2 and 4 are the controller's side of the portal, step 5 is its RADIUS side. When the page loads but the login never completes, the break is almost always at step 4 (the login address) or step 5 (the Identity or the shared secret).

What Kiwire expects in the redirect. The gateway's portal-page redirect must carry the guest MAC as MA, the guest IP as SIP, the original URL as OS, the node ID as NI, and optionally the port/VLAN as PORT. These are the parameters a Nomadix portal page redirect normally appends.

How the login finishes. After the guest signs in, Kiwire sends the browser to Nomadix's standard login address http://login.nomadix.com:1111/usg/process with the username, password and original URL. The gateway intercepts that address itself, then checks the credentials against Kiwire over RADIUS.

On the gateway (menu names and commands vary between firmware versions; the values are what matter):

  1. AAA / RADIUS: authentication server <radius-server-ip> port 1812, accounting 1813, shared secret <shared-secret>. Turn accounting on.
  2. Set the gateway's RADIUS NAS-Identifier to the same value as its node ID (NI), so one Kiwire record covers both. If they must differ, register both strings as Identities.
  3. Portal page / home-page redirect: point it at https://<kiwire-host>/login/nomadix with the MAC, IP, original URL and node ID appended.
  4. Pass-through (walled garden): add <kiwire-host> and the other hosts in Walled garden.

Limits. No data caps. Whether the gateway acts on Kiwire's disconnect or profile-change requests depends on its firmware and RADIUS settings; test it before relying on it.

Nomadix (XML API) ​

With Nomadix - XML, Kiwire's server logs the guest in on the gateway through its XML interface, instead of sending the browser to the gateway's login address. Synchroweb sets up the first site with you, because Kiwire's server has to reach the gateway.

Device type in KiwireNomadix - XML
Redirect URLhttps://<kiwire-host>/login/nomadix_xml
RADIUSauth 1812 / acct 1813 (UDP)
Identity must equalthe node ID the gateway sends as NI, and its RADIUS NAS-Identifier
Speed changespushed to the gateway through its XML interface
How a guest logs in through Nomadix and Kiwire The guest joins the Wi-Fi and opens a page. The Nomadix device redirects the browser to Kiwire at /login/nomadix_xml. Kiwire shows the portal and the guest signs in. Kiwire hands the login back to the device: server-side XML RADIUS_LOGIN. The device then asks Kiwire over RADIUS, identifying itself with node ID (NI) / NAS-ID. Kiwire accepts and returns the profile's limits, the device lets the guest out and starts sending accounting. Guest devicephone, laptopNomadixXML interfaceKiwireportal + RADIUSInternetafter acceptance1 JOINS THE SSID, OPENS A PAGE2 REDIRECT TO/login/nomadix_xml3 PORTAL PAGE — THE GUEST SIGNS IN4 HAND-BACK:server-side XML RADIUS_LOGIN5 RADIUS REQUEST — IDENTITY =node ID (NI) / NAS-ID6 ACCEPT + PROFILE LIMITS7 GUEST IS LET OUT; ACCOUNTING STARTS
Steps 2 and 4 are the controller's side of the portal, step 5 is its RADIUS side. When the page loads but the login never completes, the break is almost always at step 4 (the login address) or step 5 (the Identity or the shared secret).
  1. Set up RADIUS, the portal-page redirect (to https://<kiwire-host>/login/nomadix_xml) and the walled garden as for the Nomadix gateway above.
  2. Enable the gateway's XML interface and allow Kiwire's server to reach it. The address Kiwire connects from is shown at the top of System › Device Controller.
  3. On the Device Controller record: IP Address = the gateway's address as Kiwire reaches it. Kiwire uses the XML port 1111; if yours differs, add it to the IP Address (203.0.113.10:8080) or set it as the COA Port.
  4. Test with Controller Test and a real guest login, then check Reporting › Login › Active Session.
Device type in KiwirePeplink
Redirect URLhttps://<kiwire-host>/login/peplink
RADIUSauth 1812 / acct 1813 (UDP)
Identity must equalthe device name the router sends as device_name in the redirect, and the NAS-Identifier it sends in RADIUS
Disconnect / live changes (CoA)standard RADIUS CoA / Disconnect to the router's IP Address, port 3799 by default — only if the router accepts them
Data capstime limits only (Session-Timeout)
How a guest logs in through Peplink and Kiwire The guest joins the Wi-Fi and opens a page. The Peplink device redirects the browser to Kiwire at /login/peplink. Kiwire shows the portal and the guest signs in. Kiwire hands the login back to the device: GET to form_action, command=login. The device then asks Kiwire over RADIUS, identifying itself with device_name / NAS-ID. Kiwire accepts and returns the profile's limits, the device lets the guest out and starts sending accounting. Later, Kiwire can disconnect the guest or change their limits with CoA on port 3799.Guest devicephone, laptopPeplinkBalance / MAX routerKiwireportal + RADIUSInternetafter acceptance1 JOINS THE SSID, OPENS A PAGE2 REDIRECT TO/login/peplink3 PORTAL PAGE — THE GUEST SIGNS IN4 HAND-BACK:GET to form_action, command=login5 RADIUS REQUEST — IDENTITY =device_name / NAS-ID6 ACCEPT + PROFILE LIMITS7 GUEST IS LET OUT; ACCOUNTING STARTS8 LATER: DISCONNECT / CHANGE LIMITS (CoA, PORT 3799)
Steps 2 and 4 are the controller's side of the portal, step 5 is its RADIUS side. When the page loads but the login never completes, the break is almost always at step 4 (the login address) or step 5 (the Identity or the shared secret).

What Kiwire expects in the redirect. client_mac (guest MAC), ip (guest IP), host_ip (router IP), form_action (the router's login address), device_name (the Identity) and ssid. After the portal, the guest's browser opens the form_action address with the username, password and command=login; the router then checks them against Kiwire over RADIUS. Kiwire does not pass an original URL back, so set the post-login landing page on the router.

On the router (menu names and commands vary between firmware versions; the values are what matter):

  1. Network › Captive Portal (or the captive-portal profile in InControl): authentication by RADIUS server, with <radius-server-ip>, auth port 1812, accounting 1813 and <shared-secret>. Turn accounting on.
  2. Splash page: external / hosted by an external server, URL https://<kiwire-host>/login/peplink.
  3. Allowed domains (walled garden): <kiwire-host> and the hosts in Walled garden.

Before you roll out, open Portals › Troubleshoot › Controller Test, trigger the splash page from a test device, and check that device_name and form_action arrive. If your firmware names them differently, contact Synchroweb — the parameter names are part of the Controller Redirection Config, which Synchroweb maintains.

Zyxel AP ​

Device type in KiwireZyXEL AP
Redirect URLhttps://<kiwire-host>/login/zyxelap
RADIUSauth 1812 / acct 1813 (UDP)
Identity must equalthe AP MAC, exactly as the AP sends it in apmac (one record per AP)
Disconnect / live changes (CoA)standard RADIUS CoA / Disconnect to the AP's IP Address, port 3799 by default — only if the AP is reachable from Kiwire
Data capstime limits only (Session-Timeout)
How a guest logs in through Zyxel AP and Kiwire The guest joins the Wi-Fi and opens a page. The Zyxel AP device redirects the browser to Kiwire at /login/zyxelap. Kiwire shows the portal and the guest signs in. Kiwire hands the login back to the device: GET to apurl. The device then asks Kiwire over RADIUS, identifying itself with AP MAC (apmac). Kiwire accepts and returns the profile's limits, the device lets the guest out and starts sending accounting. Later, Kiwire can disconnect the guest or change their limits with CoA on port 3799.Guest devicephone, laptopZyxel APAP / NebulaKiwireportal + RADIUSInternetafter acceptance1 JOINS THE SSID, OPENS A PAGE2 REDIRECT TO/login/zyxelap3 PORTAL PAGE — THE GUEST SIGNS IN4 HAND-BACK:GET to apurl5 RADIUS REQUEST — IDENTITY =AP MAC (apmac)6 ACCEPT + PROFILE LIMITS7 GUEST IS LET OUT; ACCOUNTING STARTS8 LATER: DISCONNECT / CHANGE LIMITS (CoA, PORT 3799)
Steps 2 and 4 are the controller's side of the portal, step 5 is its RADIUS side. When the page loads but the login never completes, the break is almost always at step 4 (the login address) or step 5 (the Identity or the shared secret).

What Kiwire expects in the redirect. The external captive portal redirect Zyxel APs use: usermac, userip, apip, apmac, ssid_name and apurl (the AP's own login address). After the portal, the guest's browser opens apurl with the username, password and a success_url. Kiwire has no original page from Zyxel to pass back, so success_url is Google's home page unless you set a post-login landing page on the AP or in Nebula.

Identity. Register each AP with Identity = its MAC in the same colon form the AP sends (matching ignores upper/lower case, but : and - are different). If the AP sends no NAS-Identifier in RADIUS, Kiwire uses the AP MAC from Called-Station-Id, so the same record covers RADIUS too. If the AP does send a NAS-Identifier, that string must also be a registered Identity — see Identity and Virtual NAS.

On the AP or in Nebula (menu names and commands vary between firmware versions; the values are what matter):

  1. SSID sign-on / authentication: RADIUS server <radius-server-ip>, auth 1812, accounting 1813, <shared-secret>. Turn accounting on.
  2. Captive portal: external captive portal URL https://<kiwire-host>/login/zyxelap (in Nebula: Configure › Access points › Captive portal customization).
  3. Walled garden: <kiwire-host> and the hosts in Walled garden. Keep SSID names free of special characters — Zyxel carries the SSID in the redirect URL.

Other / generic ​

For a gateway whose vendor isn't listed but that lets you choose the names of its redirect parameters and posts a username and password to its own login page.

Device type in KiwireOther
Redirect URLhttps://<kiwire-host>/login/other
RADIUSauth 1812 / acct 1813 (UDP)
Identity must equalthe nasid value in the redirect, and the NAS-Identifier it sends in RADIUS
Disconnect / live changes (CoA)standard RADIUS CoA / Disconnect to the device's IP Address, port 3799 by default — only if the device accepts them
Data capstime limits only (Session-Timeout)
How a guest logs in through Other / generic and Kiwire The guest joins the Wi-Fi and opens a page. The Other / generic device redirects the browser to Kiwire at /login/other. Kiwire shows the portal and the guest signs in. Kiwire hands the login back to the device: POST username, password to login_url. The device then asks Kiwire over RADIUS, identifying itself with nasid / NAS-ID. Kiwire accepts and returns the profile's limits, the device lets the guest out and starts sending accounting. Later, Kiwire can disconnect the guest or change their limits with CoA on port 3799.Guest devicephone, laptopOther / genericany HTTP-redirect gatewayKiwireportal + RADIUSInternetafter acceptance1 JOINS THE SSID, OPENS A PAGE2 REDIRECT TO/login/other3 PORTAL PAGE — THE GUEST SIGNS IN4 HAND-BACK:POST username, password to login_url5 RADIUS REQUEST — IDENTITY =nasid / NAS-ID6 ACCEPT + PROFILE LIMITS7 GUEST IS LET OUT; ACCOUNTING STARTS8 LATER: DISCONNECT / CHANGE LIMITS (CoA, PORT 3799)
Steps 2 and 4 are the controller's side of the portal, step 5 is its RADIUS side. When the page loads but the login never completes, the break is almost always at step 4 (the login address) or step 5 (the Identity or the shared secret).

What Kiwire expects in the redirect. Configure the gateway to append exactly these names:

ParameterValue
nasidthe gateway's identifier (register it as the Identity)
macthe guest's MAC address
ipthe guest's IP address
urlthe page the guest first asked for
login_urlthe gateway's own login address

After the portal, the guest's browser POSTs username and password to login_url; the gateway then checks them against Kiwire over RADIUS. Kiwire does not pass the original page back in this post, so set the post-login landing page on the gateway.

Before you roll out, open Portals › Troubleshoot › Controller Test, trigger the redirect from a test device, and check that all five parameters arrive. Then complete a real guest login and check the session appears under Reporting › Login › Active Session. If your gateway can't use these names, contact Synchroweb about adding the vendor.

In Kiwire (all types on this page) ​

  1. System › Device Controller → add: Vendor, Identity (see each table above), Shared Secret Key (same as on the device), and under Advanced Configuration the IP Address and COA Port Kiwire should send disconnects to. For Peplink and Zyxel, ask Synchroweb to add the record.
  2. Check the redirect parameters — The redirect and the login config.
  3. Add a zone rule and journey — Controllers and zones and Portal designer.
  4. Test with Portals › Troubleshoot › Controller Test, a real guest login, then Reporting › Login › Active Session — see Before you leave site.

Vendor reference ​

Last updated:

Kiwire platform documentation

Synchroweb