Kiwire docs

Appearance

Cisco Meraki ​

How to connect Cisco Meraki MR access points, managed from the Meraki cloud dashboard, to Kiwire.

Device type in KiwireMeraki
Redirect URLhttps://<kiwire-host>/login/meraki (Meraki calls it the custom splash URL)
RADIUSauth 1812 / acct 1813 (UDP)
Identity must equalEach access point's MAC address, one record per AP, written with colons (for example e0:55:3d:12:34:56)
Disconnect / live changes (CoA)No
Data capsTime limits only (Session-Timeout)

Read Controller identity and Virtual NAS once before your first installation.

How a login works ​

  1. A guest joins the SSID. The Meraki AP sends their browser to the custom splash URL, which is Kiwire. Meraki adds its own parameters, including the AP's MAC (ap_mac), the guest's MAC and IP, the page they asked for (continue_url) and a one-time login_url on Meraki's side.
  2. The guest logs in on the Kiwire portal.
  3. Kiwire sends the guest's browser to Meraki's login_url with the username, password and a success_url (the page the guest first asked for).
  4. Meraki checks those credentials with Kiwire over RADIUS, then lets the guest on.

So Meraki does not host the login page and does not send the password to the portal. The portal is Kiwire's, and the password reaches Meraki from the guest's browser. Kiwire never uses the Meraki Dashboard API.

How a guest logs in through Cisco Meraki and Kiwire The guest joins the Wi-Fi and opens a page. The Cisco Meraki device redirects the browser to Kiwire at /login/meraki. Kiwire shows the portal and the guest signs in. Kiwire hands the login back to the device: POST username, password, success_url to login_url. The device then asks Kiwire over RADIUS, identifying itself with AP MAC (ap_mac). Kiwire accepts and returns the profile's limits, the device lets the guest out and starts sending accounting. Guest devicephone, laptopCisco MerakiMR access pointKiwireportal + RADIUSInternetafter acceptance1 JOINS THE SSID, OPENS A PAGE2 REDIRECT TO/login/meraki3 PORTAL PAGE — THE GUEST SIGNS IN4 HAND-BACK:POST username, password, success_url to login_url5 RADIUS REQUEST — IDENTITY =AP MAC (ap_mac)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).

Meraki's login_url carries a one-time token after a ?, which Kiwire passes back to Meraki untouched.

Before you start ​

From Kiwire:

  • The RADIUS server address shown in the Setup Guide checklist (Before you add your controller › RADIUS Authentication & Accounting). Below it is written <radius-server-ip>.
  • The Meraki RADIUS secret from Synchroweb support. Meraki networks use a fixed RADIUS secret on Kiwire, the same for every Meraki network. Synchroweb support gives it to you. It is not the value in the record's Shared Secret Key field.
  • Your <kiwire-host>: the host name of your portal. Portals › Troubleshoot › Controller Test shows it in the Test URL field.

From Meraki:

  • Dashboard access to the network, with rights to change SSIDs.
  • The MAC address of every AP that broadcasts the guest SSID (Wireless › Monitor › Access points, or export the list).
  • Enough Kiwire licence: every AP is one controller record.

On the controller ​

Menu names and commands vary between firmware versions; the values are what matter. The paths below are from the Meraki dashboard.

  1. Wireless › Configure › Access control, choose the guest SSID:
    • Security (network access): Open (no encryption), or the option your policy needs. Guests log in on the splash page, not with 802.1X.
    • Splash page: Sign-on with → my RADIUS server.
    • RADIUS servers → Add a server:
      • Host: <radius-server-ip>
      • Port: 1812
      • Secret: the Meraki secret from Synchroweb support
    • RADIUS accounting: enabled. RADIUS accounting servers → Add a server: host <radius-server-ip>, port 1813, the same secret.
    • Leave the NAS identifier Meraki sends as it is. Kiwire recognises a Meraki network by it.
    • Advanced splash settings › Walled garden: enabled. Add <kiwire-host>, fonts.googleapis.com and fonts.gstatic.com, plus anything else your portal loads (see Walled garden and redirect). If your dashboard only accepts IP ranges here, enter the addresses those names resolve to.
    • Save.
  2. Wireless › Configure › Splash page, same SSID:
    • Choose Custom splash URL ("Or provide a URL where users will be redirected") and enter https://<kiwire-host>/login/meraki.
    • Don't add any query string: Meraki appends its own parameters, and Kiwire's Meraki login config already reads them.
    • Save.

In Kiwire ​

  1. Admin › System › Device Controller: add one record per AP:

    • Vendor: Meraki
    • Identity: the AP's MAC with colons, for example e0:55:3d:12:34:56. Upper or lower case both match, but dashes (E0-55-3D-…) or no separators do not.
    • Shared Secret Key: required by the form, but not used for Meraki's RADIUS. Use Generate.
    • Leave IP Address empty. Kiwire cannot send disconnects to Meraki APs.

    For many APs, use the CSV import on the same page (columns unique_id, vendor, shared_secret; vendor meraki).

    Why one per AP: Meraki's splash redirect carries the AP's MAC (ap_mac), and its RADIUS requests carry the same AP's MAC in Called-Station-Id. Kiwire uses that MAC to find the record for both. An AP without a record gives the guest a "not configured" error.

  2. Check the redirect parameters. The Meraki login config is maintained by Synchroweb. It reads client_mac, client_ip, continue_url, login_url and ap_mac. See The redirect and the login config.

  3. Zones and journeys. Under Portals › Captive Portal › Zones Mapping, add zone rules and give each zone a journey. Meraki's redirect doesn't carry the SSID or VLAN for Kiwire, so group APs with NAS ID rules (one AP MAC per rule), or use one zone for the whole network. See Controllers and zones and Designers and journeys.

Test it ​

  1. Portals › Troubleshoot › Controller Test → Start Capture, then connect a phone to the guest SSID. Check that the hit shows mac, login_url and the AP's MAC as the controller ID, and that it is registered to your organisation. If the AP is shown as not registered, compare its MAC in the capture with the Identity you entered.
  2. Log in as a guest. If the portal accepts the login but Meraki then shows an error, the RADIUS secret or RADIUS server address on the SSID is wrong, or the AP's record is missing.
  3. Reporting › Login › Active Session: the session should appear once Meraki sends accounting.
  4. In the Meraki dashboard, Network-wide › Monitor › Event log shows splash and RADIUS events for the client.

Limits to know ​

  • Fixed RADIUS secret. All Meraki networks on Kiwire use the secret Synchroweb support gives you. The Shared Secret Key on the record doesn't change it.
  • One record per AP, and every record counts toward your licence's controller limit. Add the record before a new AP goes live.
  • Add records before the device goes live. Kiwire accepts a new record straight away. If the device already sent RADIUS requests before its record existed, they can keep failing for up to an hour. See Controller identity and Virtual NAS.
  • No disconnects or live changes. Changing a guest's profile in Kiwire does not reach a session that is already running. It applies from the guest's next login.
  • No data caps. Kiwire has no Meraki data attribute. The session length comes from Session-Timeout. For speed limits, set per-client limits on the SSID in the Meraki dashboard if the profile's speeds aren't applied.

Vendor reference ​

Last updated:

Kiwire platform documentation

Synchroweb