Meeting room display network requirements: Wi-Fi, VLAN, f...

The purchase is agreed. Someone in facilities has picked the rooms, someone in finance has signed off, and then the request lands with the person who runs the network: "we need to put eight screens on the wall outside the meeting rooms, can you sort the Wi-Fi?" What follows is usually a week of back and forth, because the answer depends on a dozen things nobody wrote down, and the vendor's documentation says "connects to Wi-Fi" and stops there.

This post is the missing document. It covers band support and why so many low-power display devices are 2.4 GHz only, WPA2 versus WPA3 and the Protected Management Frames problem, why captive portals and 802.1X are a hard blocker for battery-powered panels, which VLAN these things belong on, what to allowlist outbound, why NTP matters more than you expect, proxies and TLS inspection, what actually happens on the screen when Wi-Fi drops, and how MAC randomisation interacts with MAC allowlists. It ends with a checklist you can paste into a ticket.

2.4 GHz, 5 GHz and why the cheap panels are 2.4 only

Battery-powered e-ink displays are typically built on an ESP32-class microcontroller. The Seeed reTerminal E1001 uses an ESP32-S3 with 8 MB of PSRAM; the TRMNL 7.5" panel uses an ESP32-C3. Different silicon, same constraint: both are 2.4 GHz only, and TRMNL's own help centre states plainly that the devices can only connect to 2.4 GHz networks. This is not a defect. A 5 GHz radio costs meaningfully more power, and 2.4 GHz propagates better through the plasterboard and glass you find in a corridor. If you want a panel that runs for months on a charge rather than days, you take 2.4 GHz.

The practical consequence is band steering. Most modern deployments run a single dual-band SSID and let the controller push clients to 5 GHz. A 2.4-only client either fails to associate or associates and then gets steered off. TRMNL's documentation is explicit that a dedicated 2.4 GHz SSID is preferable to a dual-band one for exactly this reason, and the same applies to any ESP32-class panel.

Two failure modes worth knowing before you start

Protected Management Frames. TRMNL's troubleshooting notes describe a firmware update where PMF was automatically enabled and broke connectivity, resolved by disabling PMF on the 2.4 GHz band. That is a sourced example from one vendor, but it is the single most common "the device sees the SSID but will not join" cause on ESP32 hardware generally.
Channel selection. TRMNL's notes also record a case where auto channel selection had landed on channel 9 and produced intermittent disconnects, fixed by pinning to channel 1. On 2.4 GHz, use 1, 6 or 11 and nothing else.

WPA2 versus WPA3

WPA3-Personal mandates PMF. That collides directly with the point above. WPA3 transition mode (which advertises both) usually works, but "usually" is doing real work in that sentence, and firmware behaviour varies by device and version.

The pragmatic answer for a room display deployment is a dedicated SSID running WPA2-PSK with PMF disabled or set to optional. If your security posture will not allow a WPA2 SSID anywhere on the estate, you need to establish that before you order hardware, not after. This is a genuine constraint and pretending otherwise wastes everyone's week.

Captive portals and 802.1X break battery-powered devices

A captive portal requires a browser and a human. A panel that wakes for a few seconds, fetches an image, and goes back to deep sleep has neither. There is no protocol for a headless device to accept terms and conditions. TRMNL's guidance for captive-portal environments, to take one vendor's documented answer, is to put a travel router in front of the device as middleware, which tells you everything about how solvable this is at the device level.

802.1X (WPA2-Enterprise, the username-and-password networks) is the same story. Per TRMNL's docs, TRMNL devices cannot natively join WPA/WPA-2 Enterprise networks, and the recommended workaround is a small router that supports EAP and rebroadcasts a PSK network. Stock firmware on low-power panels generally has the same limitation. Note that both workarounds mean putting an unmanaged third-party router on your network, which most IT teams will refuse, correctly.

There is a nastier version of this problem. Guest networks with a portal session timeout will drop the display every 24 hours. Because e-ink holds its last image, nobody notices for a week. Do not put room displays on a guest SSID with a portal, ever.

Which VLAN

Guest VLAN: no. Captive portals, session timeouts, aggressive idle disconnects and rate limiting. Every one of those is fatal to a device that cannot report its own failure.
Corporate VLAN: no. You cannot patch or MDM these devices, and they do not need to reach anything internal. Putting an unmanageable device on the trusted segment buys you nothing and costs you an audit finding.
IoT or device VLAN: yes. Outbound internet only, client isolation on, no route to corporate. That is exactly the profile a cloud-backed room display needs.

Client isolation is fine because displays never talk to each other. mDNS and Bonjour reflection are not needed. DHCP with a long lease is fine; static reservations are nicer for inventory but not required. One exception, if you self-host the server side rather than pointing the panels at a vendor cloud: the panels then do need to reach one internal host, so the rule becomes a single narrow allow from the device VLAN to that host and port, and nothing else.

One more exception worth naming: if you run Zoom Rooms scheduling displays, Zoom's own documentation requires the scheduling display and the Zoom Rooms computer to be on the same network. Appliance-based schedulers from the AV vendors often have similar constraints. Cloud-only displays like the e-ink and browser-based ones do not, because they talk to a cloud API rather than to anything in your building.

What to allowlist outbound

The list is short, and if a vendor asks for anything beyond it you should ask why.

TCP 443 outbound to the vendor's API hostname. This is where the calendar data and the rendered image come from.
TCP 80 outbound, often needed for captive portal detection and, on some firmware, for OTA firmware downloads.
UDP 123 outbound for NTP. See the next section; this one bites people.
UDP 53 to whichever resolver you point the VLAN at.
Nothing inbound. No port forwards, no NAT rules, no reachable management interface. If a room display vendor asks for an inbound rule, that is a design you should not deploy. Self-hosting changes the destination, not the direction: with a self-hosted server the panel fetches from an internal host on your own network instead of from a vendor's cloud, but it is still the panel making the outbound connection, and still nothing inbound from the internet.

Allowlist by hostname rather than by IP. Cloud vendors rotate addresses and CDN edges without notice, and an IP allowlist will fail six months later in a way nobody connects to the original change. If your firewall only does IP objects, ask the vendor for a stable hostname and use a DNS-resolving policy object. The exception, again, is a self-hosted server: if the panels fetch from a box you run, the address is yours and it does not move, so an IP object is correct there and arguably better than a hostname.

NTP and why clock drift breaks calendar rendering

A microcontroller-based display has no battery-backed real-time clock. It gets the time from NTP at boot and after every deep sleep cycle. Two things go wrong when NTP is blocked:

The timeline is wrong. The screen says "Available until 14:00" when it is already 14:06. Users lose trust in the display within a day, and once they stop trusting it they stop reading it.
TLS fails entirely. Certificate validation checks notBefore and notAfter against the device clock. A device that thinks it is 1970 cannot complete a handshake with any modern endpoint, and the error it reports will look like a network problem rather than a time problem.

Blocking outbound UDP 123 and forcing internal NTP is a very common hardening default. It is fine, as long as the device VLAN can actually reach your internal NTP servers, and as long as the device firmware lets you point it at them. If it does not, allow the device to reach a public pool.

Proxies, TLS inspection and DNS

Low-power firmware generally has no proxy support at all. No PAC file parsing, no NTLM or Kerberos auth, no CONNECT handling. If your egress is proxy-only, the display VLAN needs a direct-egress bypass rule for the vendor's domains.

TLS inspection is the other one. Many of these devices ship a fixed, small CA bundle, and on stock vendor firmware there is no supported way to install your corporate root certificate. Every request will fail with a certificate error. Bypass TLS inspection for the vendor's hostnames. This is a legitimate exception: the traffic is a device fetching a rendered image and a small JSON payload from a single known endpoint. The caveat is that these are open-source panels and you can flash them yourself, which is the normal case if you are self-hosting the server side. Firmware you build is firmware whose CA bundle you control, so you can trust your own root instead and skip the bypass entirely.

DNS is usually the easy one. Redirecting all port 53 to internal resolvers works fine as long as those resolvers answer for public names. Watch for split-horizon setups that NXDOMAIN external names by policy.

What happens when Wi-Fi drops

This differs by display type and it matters more than people expect.

Tablet or browser display: you get a visible failure. A blank page, a browser error, a spinning reload, or a screensaver. Ugly, but honest. Everyone walking past knows the screen is broken.
E-ink: the panel holds the last rendered image indefinitely at zero power draw. That is a real advantage. It is also a real risk. A dead display showing "Available, no bookings today" is indistinguishable from a working one, and someone will walk into an occupied room because of it.

The mitigation is not optional: every battery e-ink room panel should print its last sync time on screen, and the dashboard should alert when a device stops checking in. If a product does neither, you cannot trust what is on the wall. Ask the vendor this question directly during evaluation and look at a real screen rather than a marketing render.

MAC randomisation versus MAC allowlists

If your Wi-Fi uses MAC-based access control, this section decides whether your deployment works.

Tablets randomise. Apple's private Wi-Fi address feature gives each network a different address and can rotate it. On iOS 18 and later there are three modes (Off, Fixed and Rotating), with Fixed used as the default for secure networks such as WPA2. Apple's own guidance says organisations may need to update their network security to work with private addresses, or push an MDM profile to turn the feature off for that SSID. Android randomises per-network by default too. So: if you repurpose iPads or Android tablets as room displays and you use MAC allowlists, disable private addressing for that SSID via MDM, or register the address the device actually presents rather than the one on the box.

ESP32-class e-ink panels generally do not randomise. They present the factory MAC, which makes MAC allowlisting workable. Vendor setup flows often have you register that address by hand during onboarding — TRMNL's BYOD documentation is one published example — which tells you it is stable enough to be used as an identifier.

Worth saying plainly: a MAC allowlist is inventory control, not security. Addresses are trivially spoofable from any laptop. Use it to keep unknown devices off a segment, not as your security boundary.

Pre-deployment checklist for your network team

Is there a 2.4 GHz SSID available in the corridors where the panels will hang, or can one be created? Dual-band with band steering is not sufficient for 2.4-only devices.
Confirm the SSID is WPA2-PSK. If WPA3-only, confirm the device supports it before ordering; if unsure, order one unit and test.
Confirm PMF is disabled or optional on that SSID.
Pin the 2.4 GHz channel to 1, 6 or 11 rather than auto.
Confirm there is no captive portal and no 802.1X on that SSID. Both are hard blockers.
Place the SSID on an IoT or device VLAN with outbound internet only, client isolation on, and no route to corporate.
Allowlist outbound TCP 443 and 80, UDP 123 and UDP 53. Allowlist by hostname, not IP.
Confirm the VLAN can reach an NTP source, internal or public.
Add a TLS inspection bypass for the vendor's hostnames.
Add a proxy bypass if egress is proxy-only.
If using MAC allowlists: disable private Wi-Fi addressing on tablets via MDM, and register the panel MACs.
Do an RF survey at the actual mounting height and position, not at the door. A panel against a metal door frame at 1.2 m behind a glass wall reads several dB worse than a phone held at head height in the same corridor.
Confirm you have an alert when a display stops reporting in. This is the only thing standing between you and a stale screen nobody notices.

Lobby's own requirements, stated plainly

That is the build side. Here is the buy side, with the same numbers we would put in a ticket.

Lobby is a room display for Google Workspace and Microsoft 365 room resources, in three forms sharing one dashboard: a physical e-ink panel, a virtual display that is just a URL you open in any browser on a tablet or TV, and a room overview board for a reception screen. Lobby is hardware-agnostic. The panel we recommend by default is the Seeed reTerminal E1001, a 7.5-inch 800×480 monochrome e-paper device at USD 69 per room at 1 to 9 units, dropping to USD 62.99 at 10 or more, bought direct from the manufacturer and owned outright with no markup from us. TRMNL hardware works too and is still supported; it is one option among several rather than the option. Pricing is on our pricing page: free forever for up to three displays with 15-minute e-ink refresh and no credit card, then USD 30 per month billed yearly (USD 360 a year, or USD 50 month to month) for unlimited displays, and USD 60 per month billed yearly (USD 720 a year, or USD 100 month to month) for Pro Unlimited (5-minute refresh, EU hosting for e-ink devices, custom branding, QR room feedback, a Slack /book command). Yearly billing saves 40% against the month-to-month rate. Setup is under ten minutes and self-serve.

Network-wise: outbound HTTPS on 443 only, plus NTP and DNS. Nothing inbound. No agent, no on-premises connector, no server in your rack — unless you want one. Lobby supports a self-hosted server, in which case the panels fetch from that internal host instead of from us, and the two paragraphs above about hostname allowlisting and TLS inspection apply in their self-hosted form rather than their cloud form. The e-ink panels carry the constraints described in this post whichever vendor you buy them from, which means 2.4 GHz only, no captive portal, no 802.1X, and a battery that runs 3 to 6 months on a single charge in normal use depending on refresh interval. If your only wireless is 802.1X and you will not create a PSK SSID, the honest answer is that the virtual display on an existing corporate-managed tablet is the option that fits you, not the e-ink one.

Other things Lobby does not do, so you can rule it in or out quickly: no desk booking, no visitor management, no room automation or AV control, no enterprise SSO or SCIM at scale, no MDM on the e-ink hardware, and no on-premises Exchange without a hybrid configuration.

TL;DR

Most battery e-ink panels are 2.4 GHz only because of power budget. Create a dedicated 2.4 GHz SSID; band steering on a dual-band SSID will cause intermittent failures.
Use WPA2-PSK with PMF disabled or optional. WPA3 mandates PMF, which is the most common association failure on ESP32 hardware.
Captive portals and 802.1X are hard blockers for headless devices. The only workarounds involve putting a third-party router on your network, which most IT teams should refuse.
IoT VLAN, outbound only, client isolation on. Not guest, not corporate. Self-hosting adds exactly one narrow rule: the device VLAN to your own server.
Allowlist outbound 443, 80, UDP 123 and UDP 53 by hostname. Nothing inbound, ever. Against a self-hosted server, an IP object is the right choice instead.
Blocked NTP breaks both the timeline and TLS certificate validation, and it looks like a network fault.
Bypass TLS inspection and proxies for the vendor's hostnames. On stock firmware you cannot install a corporate root CA; if you flash the firmware yourself you usually can, and then you do not need the bypass.
E-ink holding its last image on failure is both the best and the worst property of the technology. Require an on-screen last-sync time and server-side offline alerting.
Disable private Wi-Fi addressing per SSID if you use MAC allowlists with tablets. Panels usually present a stable factory MAC.

Sources

Setting up TRMNL on tricky Wi-Fi situations, TRMNL Help Center, for the 2.4 GHz-only requirement, the dedicated-SSID advice and the captive portal and 802.1X workarounds
Device / WiFi troubleshooting, TRMNL Help Center, for the PMF firmware incident and the channel 9 disconnect case
BYOD device setup and MAC registration, TRMNL developer docs, for the MAC registration example
Seeed Studio reTerminal E1001 product documentation, for the ESP32-S3 module and 8 MB PSRAM, the USD 69 unit price and the 3 to 6 month battery figure
Use private Wi-Fi addresses on Apple devices, Apple Support
Privacy features when connecting to wireless networks, Apple Platform Security
Using Zoom Rooms scheduling display (same-network requirement), Zoom Support

Meeting Room Display Network Requirements (Wi-Fi, VLANs, Firewall and Captive Portals)