The answers, including the awkward ones

It answers one question about a wall jack: is this drop good? It reports link state, speed and duplex; whether DHCP offered an address and what that address is; whether the gateway is reachable, and its round trip latency in milliseconds; whether DNS resolves; whether the internet is reachable; and your public IP. Where the switch advertises LLDP or CDP it also reports the switch name, the port ID and the VLAN. Everything rolls up into one verdict: PASS, WARN or FAIL.

It used to. The internet check was a bare TCP handshake, and a captive portal or a SYN proxy answers those for everything, so a jack behind one lit green and its report said the drop reaches the internet. That was wrong and it is fixed.

The check now completes a TLS handshake. That needs the far end to produce a ServerHello, a certificate and a finished key exchange, which an HTTP interceptor cannot do: it either refuses port 443, resets, or accepts the connection and speaks HTTP, and all three read as unreachable.

What it still does not prove, because you should know where the line is: the certificate is not verified. The tester has no certificate store and no clock until it syncs, so checking one would be theatre. A portal that transparently intercepts TLS with its own certificate would still pass. That is rare, since doing it breaks every HTTPS site for everyone on the network, but it is possible. PASS means something completed a TLS handshake, not that it was who it claimed to be.

Change it. The target lives in the tester's settings menu, address and port. It was compiled in, which meant a site that blocks Cloudflare got a WARN on every healthy jack in the building with no way to correct it, and a tester that is wrong about a whole site is worse than useless there: the technician learns to ignore the amber, and then ignores it on the jack that matters.

Use an IP address rather than a name where you can. This check exists to tell a broken resolver from a broken uplink, and it cannot do that if reaching it needs the resolver. If you set a name, the menu says so.

By traffic actually flowing through it, not by ping. Many gateways drop ICMP, and a tester that calls that a failure sends technicians chasing faults that are not there. ICMP is still used separately to report gateway latency, and internet reachability is checked by completing a TLS handshake with an address rather than a name, so a broken resolver and a broken uplink show up as different faults.

We will not print claims about anyone else's product on our own page, because those claims vary by model and we have not tested every one. What we will state are our own limits, so you can hold them against whatever you are comparing: JackProbe is 10/100 only, and it does not detect or measure PoE. Check both against the model you have in mind.

What you get in exchange: a self-contained HTML report for every save, carrying a label and typed notes, 394 reports in onboard flash, passive switch and port discovery, a JSON API, and a device that works with no account and no service to sign into.

No. There is no PoE detection and no PoE measurement of any kind. It will not tell you whether the port supplies power, at what class, or on which pairs. If you need that, carry something else for it.

No. There is no cable certification, no wiremap, no TDR, no cable length and no distance to fault. It is not a certification tool and cannot be used for structured cabling warranties. It tests whether the drop carries a working network, which is a different question from whether the cable meets a standard.

No. Ten and a hundred megabit only. On a port that also supports gigabit, the link will normally negotiate down to 100 and the tester will report 100. On a port forced to gigabit with autonegotiation off, it may not link at all. Read the speed it reports as the speed of this test, not as the ceiling of the port.

It will not authenticate. It is not a supplicant and it carries no credentials, so a port that demands them will not let it on.

It will often tell you that the port asked, though. The tester listens for the switch's identity request and says so when it hears one, along with whether an address was handed out anyway. That is genuinely useful: link up with no DHCP offer looks the same as several other faults, and knowing the port wanted credentials separates them.

It can never tell you a port does NOT use 802.1X. The switch sends its requests when a device appears and then stops, and re-authentication is off by default, so on a port whose requests finished before you plugged in no amount of waiting produces one. There is no reading that claims otherwise, and what you get instead is what was heard plus how long the tester listened and how many frames went past while it did.

Where a port falls back to a guest or remediation VLAN you may get an address on the wrong network and a passing result. Open mode, a guest VLAN, an auth-fail VLAN and MAC address bypass all look identical from outside, and the tester names all four rather than picking one.

No to both. There is no traffic capture or packet inspection available to you, no spectrum analysis, and no survey of surrounding WiFi networks. Its radio exists to serve its own hotspot and nothing else. IPv6 is also not tested.

Nothing. Switch name, port ID and VLAN are learned passively, by listening for the LLDP and CDP advertisements the switch already sends onto the wire. The tester transmits nothing to obtain them and does not probe or scan. If the switch does not advertise, those fields stay empty.

In its default state it behaves like an ordinary host: it takes a DHCP lease, talks to the gateway, pings it for latency, resolves a name, opens one outbound TCP connection to check the internet is reachable and learn the public IP, and listens for LLDP and CDP. It does no scanning, offers no packet capture or inspection to the user, and does not do 802.1X.

One setting changes this. Internet sharing turns the tester into a NAT router, which is exactly what network access control looks for. It is off unless you turn it on and the device warns you first. Leave it off on any network you do not own.

The DHCP result reads as no offer, no address is assigned, and everything downstream of an address cannot run: gateway, DNS, internet and public IP. The run cannot return a PASS, and the light shows the verdict it reached. The link section is still valid, so you will know whether the port came up and at what speed and duplex, which usually separates a dead drop from a live drop on a VLAN with no address pool. Any LLDP or CDP data still arrives, because listening for it does not need an address.

For verdicts, yes. The light gives you PASS, WARN or FAIL on its own, and the button re-runs the test and saves reports. You can walk a floor of jacks reading verdicts with nothing in your hand but the tester.

The phone comes out when you want a labelled report. A double press saves the test, but the label and notes are typed, so naming a report means the web console. You can also save unlabelled at each jack and rename them afterwards from the list.

The tester runs a WiFi hotspot called JACKPROBE. Join it from a phone or laptop and open http://172.16.0.1 or jackprobe.local. You get a live console that refreshes itself, the saved reports, the settings, and a JSON API at /api/status. There is also a serial console over USB-C at 115200 baud if you would rather be wired.

By default, yes. You can set a password from the tester's settings menu, in the web console. If you set one and forget it, hold the button until the light goes white, about five seconds, and the password is cleared and the hotspot reopens.

A double press, or Save in the web console, runs a fresh test and writes a self-contained HTML file: one file, no external assets, opens in any browser. It carries the label and notes you type, plus local time and UTC. A save takes about a second and a half end to end.

They come off through the web console over the hotspot: one at a time from the button on a report, or all of them at once as a ZIP.

In the device's internal flash. Capacity is 394 reports, a number that came from filling the partition rather than from an estimate. There is no memory card: the slot on the board is unused. Reports can be renamed, downloaded and deleted from the web console, individually or all at once.

There is an optional webhook. When you save a report the tester POSTs a flat JSON summary to a URL you configure: verdict, label, notes, switch, port, VLAN, addresses and timestamps. It does not send the HTML document, so reports themselves still come off through the console. HTTPS is accepted but the certificate is not verified, because the device has no certificate store. Nothing is queued and nothing is retried, so a failed POST is lost. Treat it as convenience, not as a record.

The clock is set by SNTP once a tested drop has internet, and your time zone choice survives a restart. The clock itself does not: after a power cycle the time is only as good as the next sync.

Reports carry local time and UTC. A report saved before any sync is stamped honestly rather than plausibly, with the uptime instead of an invented date. If exact times matter, sync the tester on a drop with internet before you start and keep it powered.

This is the one place we cannot answer from tested hardware. Packaging, pricing, warranty terms and support channels are not part of the device specification, and we would rather leave the question open than invent an answer on a page whose whole point is that the numbers on it are real. Ask directly and you will get the current terms.