In the field
What it is actually for
Every situation below turns on a measurement this instrument really takes. Where a reading depends on the customer's switch being configured a certain way, that is said in the same breath, because the moment it matters is the moment you are standing in front of somebody.
Which switch port is this jack on
Fifteen year old office, nobody labelled anything, and the sticker under the desk says B-14 while the patch panel says nothing at all. You have been asked to move this one desk onto the voice VLAN and you cannot touch the switch config until you know which port it is. The comms room is two floors up.
Today
Toner and probe, or two people with radios, or you pull patch cords one at a time and watch for a link light to drop. On a live network that means knocking someone else offline while you guess, and it still takes two trips.
With the tester
Plug into the jack and wait for the switch to advertise itself. Where LLDP or CDP is running, the tester reads the switch name, the port ID and the VLAN and shows them on your phone. It sends nothing to learn this, so the port sees an ordinary endpoint. Knowing the switch and port is what lets you make the change without tracing the panel at all.
What settles it: switch name, port ID and VLAN, read passively from LLDP or CDP advertisements, where the switch sends them.
Link light is on and nothing works
The user says the port is dead. The link light on their laptop is lit, so the first line has already closed the ticket once. You need to know whether the port is up but on the wrong side of the network.
Today
Plug in a laptop, run ipconfig, see a self-assigned address, and conclude nothing more than that DHCP did not answer. You still cannot tell whether the port is on the wrong VLAN or the scope has run out, so it goes back to the network team as a shrug.
With the tester
In a case like this it reports link at 100 full duplex, no DHCP offer, and, where the switch advertises, VLAN 1 while the rest of the floor is on VLAN 20. That is a port on the wrong VLAN, and it is one line of switch config rather than another site visit.
What settles it: link speed and duplex, the absence of a DHCP offer, and the VLAN the switch reports for the port.
The desk that stopped working this morning
MSP engineer, client site, one desk out of forty. The user says the internet is down. The client's IT contact says the network is fine.
Today
Borrow a laptop, or bring your own, then work down the stack by hand: ipconfig, ping the gateway, nslookup, open a browser. And if the gateway drops ICMP you have to talk yourself out of a false failure.
With the tester
One press walks the whole chain and tells you which step broke: link, DHCP, gateway, DNS, internet. Gateway reachability is judged by traffic actually flowing through it rather than by ping, so a gateway that ignores ICMP does not read as dead. Gateway latency and the public address come with it.
What settles it: which single step in the link, DHCP, gateway, DNS and internet chain fails, under one PASS, WARN or FAIL.
Sixty desks before Monday
New floor, sixty jacks, and the furniture arrives Friday. You have to know which drops are live and on the right VLAN before anyone sits down, and the client wants something in writing that says so.
Today
A laptop, a spreadsheet and a phone camera. You type the results in by hand at the end of each row, which is where the transcription errors happen, and the evidence you hand over is a spreadsheet somebody typed.
With the tester
Walk the row. At each jack, double press to run a fresh test and save a report; the save itself takes about a second and a half. Type the jack label and any notes on your phone through the console, either at the jack or by renaming afterwards from the list. The tester holds 394 reports, and each is a self-contained HTML file you can hand over.
What settles it: up to 394 saved reports, each carrying its label, notes and verdict, and the switch, port and VLAN where those were advertised.
Facilities says the drop is dead, IT says the switch is fine
This has been going back and forth by email for a week. Facilities booked a cabling contractor, IT cancelled it, and nobody has stood at the jack with an instrument.
Today
Two teams describing symptoms to each other in a ticket. Whoever gives up first pays for the callout.
With the tester
Test the jack and save the report. It always records whether DHCP answered, the link state, the reachability results and the local time and UTC it happened. Where the switch advertises LLDP or CDP, it also names the switch and the port the jack lands on and the VLAN. That is one file, and it either points at the switch port or it does not.
What settles it: a timestamped HTML report carrying the verdict and every reading at that moment, with the switch and port where they were advertised.
Before the ceiling closes
AV install in a boardroom. The display and the codec go up on a lift that leaves at four, and the jack that will feed them is above the tile. Nobody has confirmed it is on the AV VLAN.
Today
Mount everything, plug the codec in, discover it landed on the guest VLAN, and book the lift again for next week.
With the tester
Test the jack from the lift before anything is mounted, standing where the problem would otherwise be found. The test tells you whether DHCP answered and whether the address it handed out can reach the internet, and where the switch advertises, which VLAN and port the jack is on.
What settles it: the DHCP address, mask, gateway and DNS at that jack, plus the VLAN where the switch advertises it.
Catching the fault while it is happening
A user reports the connection drops a few times a day and is fine whenever you visit. You get down there while it is actually broken and you have about a minute before it clears.
Today
You arrive, it works, you write "could not reproduce" and leave. The ticket reopens on Thursday.
With the tester
A short press re-runs the test on the spot; a double press saves a report of the failed state, so the bad moment is on record rather than remembered. Sync the tester on a working drop first, so the timestamp on the failure is real. If a webhook is configured it also posts a JSON summary, as a single attempt with no queue and no retry, which makes it a notification and not a delivery guarantee.
What settles it: a saved report of the failed state, carrying local time and UTC from the tester's clock.
The contractor says the drops are live
Fit out is finished and the cabling contractor wants sign off on eighty new drops. You are the one who has to say yes, and you will own every one that turns out not to work.
Today
Spot check a handful with a laptop, sign, and find the rest over the following month one help desk ticket at a time.
With the tester
Walk all eighty, save a report at each one, and hand back the files for the drops that did not pass.
Know the boundary on this one. This checks that the drop carries a working network at 10 or 100 Mbps. It is not a cable certification: no wiremap, no length, no distance to fault, no gigabit, and it does not replace the certifier report a structured cabling warranty requires.
What settles it: a per-jack PASS, WARN or FAIL with link speed and duplex, the DHCP result and the switch port behind it, one HTML file each.