Most Hotel WiFi Tickets Are Not WiFi

Four Nomadix courses later, the most useful thing I learned is that most hotel wifi tickets are not wifi problems.

Most of the tickets that come in saying "the wifi is down" are not about wifi.

That is the most useful thing I took from working through the Nomadix University track this summer. Four courses between July and August: Gateway Core, LAN Core, Captive Portal, and Cloud Telephony Core. Not one of them was about access points.

What HSIA actually is

If you have stayed in a hotel and connected to the guest network, you have been through an HSIA system. High Speed Internet Access is the layer sitting between the property network and the ISP uplink, and it does considerably more than route packets.

A gateway in that position is typically handling:

  • DHCP and addressing for every guest device on the property
  • subscriber management, so each device or room is a tracked session with its own state
  • bandwidth policy, often tiered, so a conference room is treated differently from a guest room
  • the captive portal redirect, and whatever authentication sits behind it
  • integration with the property management system, so a guest can authenticate by room number and last name, or bill access to the room
  • NAT, plus a walled garden of destinations reachable before login

Every one of those is a place where a guest ends up with a connection that technically works and still cannot load a page.

Why that changed how I troubleshoot

My old instinct, when a site reported broken guest wifi, was to look at the wireless side first. Signal, channel utilisation, client count, AP health.

That instinct is often wrong. The AP can be healthy, the client can have strong signal and a valid lease, and the guest still gets nothing, because the portal never fired or the PMS lookup failed.

So my order of elimination changed. Now I want to know:

  1. Did the device get an address, and from where
  2. Does a session exist on the gateway at all
  3. Did the portal redirect actually fire
  4. Did authentication complete, or fail against the PMS
  5. Only then, is this an RF problem

That sequence is better because it follows the path the traffic really takes. Most of the time the answer turns up in the first four steps.

The captive portal was the part that surprised me

Captive portals look trivial from the outside. You connect, a page appears, you accept terms or enter a room number, you are online.

Underneath it is a pile of interception. The gateway has to catch traffic on its way out and redirect it somewhere it controls, and modern client behaviour keeps making that harder. Devices run their own connectivity checks against known URLs to decide whether to surface a portal at all. HTTPS everywhere means you cannot cleanly intercept and rewrite a page. Encrypted DNS on the client can bypass the interception outright.

Which means "the portal did not come up" is frequently client behaviour rather than a gateway fault. Knowing that saves real time on a call.

The honest framing

These are certificates of completion from a vendor university, not proctored exams. I am not going to dress them up as more than that.

What they gave me is depth on the platform layer I support every day, and the vocabulary to describe it. When an escalation lands now, I can reason about where in the chain the failure sits instead of guessing and working outward.

What is next

CWNA. Gateway and HSIA is the layer above the radio, and I want the layer below it understood properly too. With both, hospitality networking stops being a pile of separate problems and starts being one system.