Reader Discovery
When you add a reader on your local network, Discover asks the network which readers are there. If the reader you want doesn't show up, this article explains why that happens and what to do instead. The same guidance appears on the Discovery step itself: after a scan finds nothing, from your third scan, or any time from the Not seeing your reader? link under the results.
Discovery Runs From the Server
Discovery runs from the Tagnet server, not from your browser. A reader you can open on your laptop may still be invisible to the server, because the two can sit on different networks with different firewall rules between them and the reader. Check from the server: open the reader's address in a browser on the Tagnet server itself, or ask whoever manages the server to try it.
Why a Reader Doesn't Show Up
- The reader isn't reachable from the server. It may be powered off, still booting, on a different network or site, or blocked by a firewall between the two.
- Your network blocks discovery. Discovery uses multicast: mDNS on UDP port 5353 for Impinj readers and WS-Discovery on UDP port 3702 for Zebra readers. Readers answer with UDP sent to a random high port on the server. A firewall that only allows specific ports drops both the question and the answers, and multicast never crosses subnets, VLANs, or sites, so a server can only discover readers on its own network segment. A blocked scan raises no error: it simply finds nothing.
- The reader doesn't announce itself. Discovery may be turned off on the reader, or the model may not support it.
- You see other readers but not this one. Readers already added to Tagnet are shown greyed out. The one you want may be on another subnet or site, or slow to answer. Scan once more, then try an IP range.
What to Do Instead
Scan an IP Range
Turn on Advanced discovery, enter a Start IP and End IP, and choose the port (80 or 443). Tagnet then asks each address in the range directly over HTTP or HTTPS. That only needs TCP from the server to the readers, so it works where multicast is blocked, including across subnets and sites.
Enter the Address Manually
Choose Manual entry (or Enter the address manually in the discovery guidance) and type the reader's IP address or hostname. This is the most direct path whenever you know the address.
Which One to Use
In a centrally managed deployment, where the Tagnet server sits in a data center and the readers are spread across sites or VLANs, multicast discovery will not reach them however the firewall is set up. Use an IP range scan when you know a reader's subnet but not its address, and manual entry when you have the address, for example from a DHCP reservation or your network team.
Network Requirements
| Traffic | Direction | Ports | Reach |
|---|---|---|---|
| Discovery, Impinj (mDNS) | Server to readers, answers back to the server | UDP 5353 multicast to 224.0.0.251; answers to a random high UDP port on the server | Same network segment only |
| Discovery, Zebra (WS-Discovery) | Server to readers, answers back to the server | UDP 3702 multicast to 239.255.255.250; answers to a random high UDP port on the server | Same network segment only |
| IP range scan | Server to readers | TCP 80 or 443 | Any network the server can route to |
| Reader management (connect, deploy, start, stop) | Server to readers | TCP 80 or 443 | Needed for every locally managed reader |
| Tag reads | Readers to server | The server's web port (TCP 5000 by default, or 443 with HTTPS), at its External URL | Needed for every reader |
Discovery is a convenience. Only reader management and tag reads are required for a reader to work, which is why an IP range scan or manual entry is all a locked-down network needs. See Installation for the server's own requirements.