meshO Manager

Appearance

Reaching the server: name or IP ​

Audience: Event organisers setting up admin laptops, volunteer workstations, phones and TVs to reach the Manager server.

Settings → Server lists two kinds of address for every app — one built on the computer's name, one on its LAN IP (tagged IP in the table). They reach the same server, but they are not interchangeable: which one works depends on the device and the browser. Handing the wrong one to a download laptop is the most common reason a volunteer reports "I can't reach the server."

The short version ​

DeviceWhich link to use
Phones, tablets, spectator TVsName link — mobile devices find the computer's name on their own.
Admin laptops — card download, station backup, entry deskIP link. These usually run Chrome, and Chrome often can't resolve the name.
The server computer itselfNeither — open http://localhost:5154/manager. See HTTPS and certificates.

Rule of thumb: the name is for devices people carry; the IP is for laptops doing the work.

Why the name doesn't always work ​

The name link isn't resolved by ordinary DNS. No server anywhere holds a record for it — instead the computer answers a multicast query on the local network, a mechanism called mDNS (Apple calls it Bonjour). That's why it needs no configuration at all: it works the moment both devices are on the same network.

The catch is that each device decides for itself whether to ask that way.

  • iOS, iPadOS, Android, macOS and Safari do mDNS natively. Phones, tablets and TVs resolve the name without you doing anything — which is exactly the audience the name link is good for.

  • Firefox asks the operating system rather than resolving names itself, so it inherits whatever the machine can do — on a Mac or a phone, that means the name works.

  • Chrome ships its own DNS resolver and frequently won't use mDNS, most consistently on macOS. It sends the lookup to your router as an ordinary DNS query, the router has never heard of a .local name, and Chrome reports:

    This site can't be reached
DNS_PROBE_FINISHED_NXDOMAIN

    The same machine will usually load the same address perfectly in Safari, which is a good way to confirm this is what you're hitting.

There is no Chrome setting that reliably fixes it. Turning off Secure DNS doesn't, and neither does the BuiltInDnsClientEnabled policy — both are worth a try but neither can be relied on at an event.

This lands hardest exactly where it hurts. Reading SportIdent cards in the browser needs the Web Serial API, which is supported by Chrome, Edge and Firefox 151+ — see Downloading cards. In practice download and station-backup laptops run Chrome, the one browser least likely to resolve the name. Give those machines the IP link. Firefox 151+ is now a genuine alternative on those laptops and does resolve the name, but the IP link works everywhere and stays the safe default.

Giving the laptops a name that works ​

If you'd rather not hand out IP addresses — they're easy to mistype and they can change — have your router serve the name instead. A router-served name is ordinary DNS, so every browser resolves it, Chrome included.

Most home and event routers do this from one screen:

  1. Note the server's current address from Settings → Server (shown as LAN IP under the computer name).
  2. In the router's admin page, find DHCP reservations (sometimes "static leases" or "address reservation") and add one for the server.
  3. Give the reservation a host name — mesho is a good choice.
  4. Save, then restart the server so it picks up the new address.

Devices then reach it at that name plus whatever local domain your router uses — commonly mesho.lan, mesho.home, or mesho.localdomain. Manager notices the change and the Access links table starts offering the new name on its own; you don't have to configure it anywhere in Manager.

This also pins the IP, which solves the next problem for free.

It has to be the router that's changed, not the computer. Renaming the server computer to something like mesho.localdomain looks like the same idea and doesn't work: it only changes what that machine calls itself, and no device on the network gains any way to look the name up. The address may still open on the server itself, which makes it seem fixed when it isn't — test from a second device before trusting it. The router is the thing that has to answer.

When the IP changes ​

Without a reservation, the server's address comes from DHCP and can differ from one event to the next — the links volunteers bookmarked last month may point nowhere. Two things worth knowing:

  • A DHCP reservation stops it changing. Worth doing once for a machine that's regularly the server.
  • A new IP doesn't mean redoing certificates. If you use HTTPS, Manager reissues the server certificate itself and the CA your devices already trust still covers it — you just restart the server. See If the server is renamed or its IP changes.

Troubleshooting ​

What you seeWhat it meansWhat to do
DNS_PROBE_FINISHED_NXDOMAIN in ChromeChrome won't resolve the mDNS nameUse the IP link from the Access links table, or set up a router host name (above)
The name works in Safari or Firefox but not Chrome on the same laptopSame cause — confirms it's the browser, not the networkAs above
No link works from another device, name or IPNetwork access is off, or a firewall is blockingCheck Allow access from other devices on the network in Settings → Server, then the server's firewall
The IP link loads but shows a certificate warningNormal until the device trusts meshO's CATrusting the certificate
Card download controls don't appear, even though the page loadsNot an addressing problem — Web Serial needs Chrome, Edge or Firefox 151+ and a secure contextDo you even need HTTPS?