Common network & Wi-Fi issues in pubs, hotels & restaurants

Three usual suspects, and they need different fixes. DHCP pool exhaustion — a small subnet (a typical /24 gives 254 usable addresses) fills up fast when each guest carries a phone, watch and laptop, and old leases don't expire quickly enough to recycle; devices then get bumped as new ones connect. Per-radio client limits — every access point has a real ceiling on how many clients it can serve well, and once you're past it, it tends to start dropping or refusing connections outright rather than just slowing down. Where that ceiling actually sits varies a lot by hardware generation and how those clients are being used, so it's worth checking against the specific AP model's own rated limit rather than assuming a number. Bad roaming behaviour — without a sensible minimum signal threshold configured, a device stays "stuck" to a distant AP instead of handing off to a closer one, then drops out instead of roaming.

Check DHCP lease time and pool size first (a shorter lease, e.g. 4–8 hours, recycles addresses faster in a high-turnover venue), then AP client counts against the manufacturer's rated limit, then roaming thresholds.

This is usually airtime contention, not a lack of raw bandwidth. A Wi-Fi radio can only talk to one device at a time — every device sharing that AP is queuing for a turn on the same airtime, so the more concurrent devices, the smaller everyone's slice, regardless of how fast your internet connection actually is.

It gets worse with overlapping channels: on 2.4GHz especially, neighbouring venues on the same or adjacent channel (common on a busy high street) cause real co-channel interference. The practical fix is almost never "one stronger router" — it's enough access points, properly placed and channel-planned, so no single radio ends up carrying far more concurrent devices than it's actually built for.

A different Wi-Fi password is not separation. If guest and till traffic are still on the same flat network, a guest device can, in principle, see and reach your EPOS system and any card terminal on it.

Proper separation is VLAN segmentation: guest, staff, payment/EPOS and CCTV each get their own VLAN, with firewall rules between them that default to deny — the guest VLAN has no route to anything else. Add client isolation on top so guest devices can't even see each other (stops one guest's phone appearing in another's AirDrop or file-sharing list). This is also what keeps guest Wi-Fi out of PCI DSS scope entirely, rather than just out of sight — see the compliance article below.

Most captive portal complaints are a phone's own connectivity check failing, not the portal itself being down. iOS and Android both fire a background request the moment they join a network to decide whether to show the login page — if DNS or the redirect isn't configured to answer that correctly, the phone just shows "no internet" and never prompts.

The other common cause: browsers now expect HTTPS everywhere, so an older portal relying on a plain HTTP redirect can get silently blocked or thrown a certificate warning instead of loading. The portal domain itself, plus whatever it depends on (analytics, fonts), also needs to be explicitly allowed through before authentication — the "walled garden" — or the page half-loads and appears broken.

A card terminal that hangs on "processing" or times out is far more often a connectivity problem than a card machine fault — the terminal is waiting on a response from the payment network and can't get one.

Common causes: the terminal is sharing an already-congested Wi-Fi network with 40 guest devices, it's on a network path with no priority/QoS so guest streaming is starving it of bandwidth, or the main internet connection itself is degraded.

Payment terminals should sit on their own protected network segment with guaranteed bandwidth, separate from guest Wi-Fi entirely — not just a different password on the same setup.

Tablet-based EPOS on Wi-Fi inherits every Wi-Fi problem above — an overloaded AP, a roaming issue, interference. Wired terminals aren't immune either: a failing PoE port or cable, a static IP that's since been claimed by another device, or the terminal's software timing out because a firewall rule is blocking a port or domain its cloud backend needs.

Where it's physically possible, wire EPOS terminals rather than relying on Wi-Fi — it removes RF variability entirely. Whichever connection type, check your EPOS vendor's own published list of required outbound ports/domains against your firewall rules; a rule tightened for security elsewhere can silently break EPOS connectivity.

Card payments need a live authorisation from your acquirer — no connection, no authorisation. Most terminals will simply show "no connection" and refuse the transaction. Some acquirers offer offline/store-and-forward processing for low-value transactions, but that's a specific arrangement with your payment provider, capped in value, and it puts the chargeback risk on you if a stored transaction later declines — it isn't a default safety net.

The real mitigation is a failover WAN: a 4G/5G backup router (or a second, independent ISP) that takes over automatically if the primary line drops. The terminal doesn't know or care which physical connection it's routed through, so service continues while the primary fault gets fixed rather than stopping the moment it does.

Locally, this is usually a PoE budget or switch capacity problem: a switch pushing power to more cameras than its total PoE budget comfortably allows will cause cameras to brown out or randomly reboot, especially as more are added over time without checking the total draw. Wireless CCTV makes everything worse and should be avoided — cameras should be wired.

If it's specifically the NVR's local storage or the recorder itself, check the hard drive isn't struggling with the combined write load of all channels at their set resolution/bitrate — high-resolution, high-frame-rate settings are often left at defaults far higher than actually needed for the coverage.

If remote access relies on port-forwarding to the venue's router, check whether your ISP is actually giving you a real public IP address at all. Many standard broadband packages now sit behind CGNAT (carrier-grade NAT) — your router doesn't have its own public IP to forward a port to, so port-forwarding was never actually going to work, no matter how it's configured on-site.

The usual fix is the NVR/camera system's own cloud relay (P2P) service instead of port-forwarding, which works around CGNAT. If a direct, reliable local connection is genuinely required, that needs a business line with a static public IP.

Rarely a problem on the internal LAN itself — gigabit switching handles multiple camera streams comfortably unless the switch or its PoE budget is undersized. It's a much more real problem for your internet connection if cameras are set to record or stream continuously to the cloud: that's constant upload traffic, and most UK business broadband has far less upload capacity than download, even on some fibre packages.

Two fixes: record locally to an NVR (which only needs to upload on-demand or motion-triggered clips, not a 24/7 stream) rather than continuous cloud recording, and apply QoS so camera traffic is deprioritised below card payments and other business-critical traffic when the connection is under load.

When every site was set up by a different installer, at a different time, you end up with different equipment, different configurations, and no single view of what's actually happening across the group — so a problem at one venue often stays invisible until a manager or guest reports it.

The fix is a common platform: the same equipment standard and the same configuration template rolled out site to site, managed centrally rather than venue-by-venue. New sites then come online in a known-good state instead of starting from scratch each time.

Without central monitoring, the first sign of a problem is usually a guest complaint or a manager phoning in — an access point can sit offline for days in a corridor nobody walks past, and nobody knows until someone tries to connect and can't.

Proper monitoring alerts on the event itself — an AP going offline, a WAN connection dropping, a PoE port faulting — rather than waiting for a symptom to be reported. It also surfaces patterns (a connection that's flapping intermittently, for instance) well before they become a full outage. This is the ongoing "monitor" part of managing a network, not a one-off install step.

Different ISPs mean different underlying technology (FTTC vs FTTP vs cable), different contention ratios, and different typical latency and outage history — so "the internet is always fine" at one site and "it constantly drops" at another can both be genuinely true even with identical on-site equipment. The ISP's own router also varies in what it lets you configure downstream (bridge mode, VLAN passthrough), which limits what a consistent setup can actually achieve behind it.

Where possible, standardise the connection type across sites (business-grade FTTP with a proper SLA, for example), and always run your own router/firewall behind the ISP's box in bridge mode — that way your configuration stays identical site to site regardless of which ISP is providing the actual circuit.

Separately from equipment overheating (see below), this is worth splitting into two patterns. Exactly periodic drops (roughly the same time each day, or every few hours) usually point to a DHCP lease renewal or PPPoE reconnection issue with your ISP. Random drops point more towards an actual line fault — most router admin panels expose line sync rate and error counts even before you call your ISP, which is worth checking first since it tells the ISP's support line exactly what to investigate rather than "it's not working."

Whatever the root cause, a failover WAN connection (see "Do I need a backup internet connection?") keeps the venue online while it's diagnosed, rather than everything stopping the moment the line does.

Networking equipment is typically rated to operate up to around 40–45°C ambient — easily exceeded in a sealed understairs cupboard, comms riser, or a room shared with a boiler or hot water cylinder, especially in summer. PoE switches make it worse by generating real heat of their own while powering multiple cameras and access points. Once kit runs hot, expect thermal throttling or random reboots rather than a clean failure — which often gets mistaken for a Wi-Fi or ISP fault instead of an environmental one.

Basic fixes: active ventilation or extraction rather than a sealed space, kit off the floor and away from any water ingress risk, kept apart from heat sources, and if rack-mounted, proper front-to-back airflow rather than units stacked in a way that blocks each other's vents.

Worth weighing the cost of an outage against the cost of avoiding one. If card payments are the majority of your trade — which is now true for most UK hospitality venues — even 30–60 minutes of "the card machines are down" during a Friday or Saturday service is a real, quantifiable loss, on top of booking systems and CCTV also going dark.

A 4G/5G backup router with a data-only SIM, configured to fail over automatically the moment the primary line drops, is usually proportionate — this doesn't need to be enterprise-grade redundancy, just enough that the venue can keep taking payments and bookings while the primary connection is fixed.

Common in older or listed venues where the data cabling was never properly first-fixed, or was added as an afterthought during a previous refit. Cabling and switch hardware left over from a previous fit-out is the usual culprit — plain Cat5 (not Cat5e, which does support Gigabit fine) or switches with only old 100Mbps Fast Ethernet ports, cable runs pushed beyond the 100m spec without a repeater, or cabling run alongside electrical conduits and lighting circuits (which introduces interference and errors on the link). All of these quietly cap what the rest of the network can do — no ISP upgrade fixes any of them, since the bottleneck is on your side of the router.

Older access points are the wireless equivalent: hardware still on Wi-Fi 4 or 5 (802.11n/ac) has a lower practical ceiling than current guest device volumes need, regardless of how the rest of the network is configured.

Nearly all booking/reservation platforms are cloud-hosted now, so the reception till or tablet running them needs a genuinely reliable outbound connection — every WAN and Wi-Fi cause covered elsewhere in this list applies here too.

One specific and surprisingly common cause worth checking directly: the reception device connected to the guest Wi-Fi by mistake rather than a proper staff VLAN — easy to happen if the same password was handed out for both, and it means reception traffic is competing with guest devices for the same airtime and is exposed to whatever's happening on the guest network. The other is a firewall or content filter rule blocking a domain the booking software needs, often introduced when tightening security elsewhere without checking against the vendor's requirements first.

Kitchen printers are often the most neglected device on the network — connected over Wi-Fi to avoid running a cable, in an environment (extraction hoods, metal equipment, heat) that's genuinely poor for Wi-Fi reliability and hardware longevity alike.

The other frequent cause is an IP conflict: the printer was given a fixed IP address once, years ago, and DHCP has since handed that same address out to something else — or a router reset changed the DHCP scope and the EPOS is now sending print jobs to an address the printer no longer has. Wire the printer where at all possible, and reserve its IP by MAC address in the router's own DHCP settings rather than setting a static IP directly on the printer. Because the reservation lives inside the DHCP server itself, that address can never be silently handed to another device — which is exactly the conflict causing the problem in the first place. (A static IP on the printer would dodge that same conflict too, but only for as long as nobody else's settings ever change — a DHCP reservation keeps that guarantee centrally rather than relying on nothing else on the network drifting.)

PCI DSS (the standard behind the self-assessment questionnaire most small merchants sign to take card payments) doesn't technically mandate network segmentation — but without it, anything sharing a network with your EPOS or card terminals falls inside the cardholder data environment, and the whole flat network becomes subject to the full set of PCI DSS requirements rather than a smaller, manageable slice of it. Segmentation is how merchants keep that scope small in practice, and it's what the simpler self-assessment questionnaire types assume you've already done.

The fix is the same VLAN segmentation covered above: guest traffic on its own VLAN with no route to the payment VLAN — genuinely out of scope, not just out of sight. On top of that, guest Wi-Fi should run WPA2/WPA3-Personal at minimum with a password that isn't years-old and shared unchanged across every site — open, unencrypted guest Wi-Fi isn't itself a PCI violation since guests never touch cardholder data, but it's still poor practice worth fixing.

The most common findings on hospitality networks are basic, not exotic: default admin credentials never changed on the router, switch or access points; WPS left enabled on consumer-grade Wi-Fi kit (a known, brute-forceable weakness); firmware that's never been updated, leaving known vulnerabilities unpatched; and management interfaces for the network gear reachable from the guest network because there's no rule stopping it.

Physical security matters just as much — kit sitting in an unlocked cupboard behind the bar can simply be unplugged or tampered with by anyone. Baseline fixes: change every default credential, disable WPS, keep firmware current, put device management on its own VLAN that guest and even staff traffic can't reach, and physically secure the equipment.