Manual

Every control, and what it does

One button, one light, one web console. This page is the whole instrument. The timings and figures here are taken from the firmware and checked against it automatically, so the page cannot drift away from the device.

The button

Four gestures

The tester has one button. A hold is recognised when you let go, not while you are holding, and the light changes colour as you pass each threshold so you can see which gesture you are about to commit before you commit it.

PRESS

Turn the page on the screen

A single press. Shows the second page of detail, and goes back to the verdict on its own after 20 seconds. On a unit with no screen fitted this runs a fresh AutoTest instead, which is what it did before there was a page to turn: the tester already re-tests every eight seconds while it is plugged in, so the press was buying at most eight seconds and a screen needed a gesture more than that did.

PRESS ×2

Save a report

Two presses inside 350 ms. Runs a fresh test and writes an HTML report, then flashes white twice to say it was written, or red three times if it was not. The screen says SAVING while it works and then names the file, or says SAVE ERROR. The report is saved without a label; to name it, use the web console instead, or rename it there afterwards.

HOLD 1.5 s

Turn internet sharing on or off

Hold until the light turns amber, then let go. The setting is stored and the tester restarts, except that it only turns sharing on once the hotspot has a key: over an open hotspot, which is how it ships, the screen says NEEDS KEY and nothing changes. Otherwise, while you hold, the screen says which way it will go, that it reboots, and that there is a longer hold after this one. See the warning further down this page before using it on a network you do not own.

HOLD 5 s

Reopen the hotspot

Hold until the light turns white, then let go. Clears the hotspot password and leaves the hotspot open. If sharing is on, it also turns sharing off and restarts, because the tester never shares its connection over an open hotspot. While you hold, the screen says OPEN WIFI and either that anyone will be able to connect or, with sharing on, that sharing turns off and the tester reboots, so the last second before you let go is a decision rather than a surprise. This is the way back in when the key has been forgotten, and it needs no cable and no computer: anyone holding the button for five seconds is standing at the device, which is the same trust boundary the key was protecting.

Presses shorter than 40 ms are ignored, which is the contact bouncing rather than a person. Because a single press has to wait 350 ms to find out whether a second one is coming, every single press carries that much delay before it acts.

A press held for more than 30 seconds is discarded rather than treated as the longest gesture. That is not a person deciding something; it is usually the tester in a bag with the button against whatever is next to it, and the gesture it would otherwise reach leaves the WiFi open.

The light

Every colour it shows

Test results

Green

PASS. Link, addressing and internet reachability are all healthy.

Amber

WARN. On the network, but something is off.

Red

FAIL. This drop is not usable.

Blue

A test is running.

Waiting, and gestures

Dim green

Cable is in and linked, waiting for the next test.

Dim red

No cable, or nothing at the other end of it.

Amber, while held

You have reached the internet sharing gesture. Let go to commit it.

White, while held

You have reached the reopen-the-hotspot gesture. Let go to commit it.

White, two flashes

A report was written. Three red flashes mean it was not.

Purple, four flashes

The hotspot password has been cleared. The tester's own WiFi is now open to anyone in range until you set a new one.

Amber and white appear twice each in that table, once steady and once flashing, and the difference is not decorative. A steady colour is a state; a flash is something that just happened. Amber steady is a WARN verdict, and amber steady while you hold the button is the sharing gesture, which is why the table says while held: that colour cannot appear unless a finger is on the button, and it goes back to the verdict the moment you let go.

Opening the hotspot gets its own colour and its own count because it is the one gesture that makes the tester less secure, and it must never look like a routine save. It used to flash white twice, exactly like a written report. That was wrong and is fixed.

The screen

Two pages, and what interrupts them

A 1.3 inch panel, fitted or not. The tester asks the bus at startup whether a screen is there and runs exactly the same either way, so a unit without one is not a unit with a fault.

Page one, the verdict

PASS, WARN or FAIL

The same verdict the light is showing, in letters, so it can be read across a room and photographed.

Speed, duplex, address

For example 100M full 192.0.2.87. Half duplex is written in capitals because it is almost always a fault.

Switch, port and VLAN

What the switch announced about itself, on one line, because it is one observation. The VLAN appears only when the switch actually sent one. This line is the reason a screen beats a light: it is what saves the walk to the comms room.

Devices, frames, and SWEPT

How many devices were heard and how many frames went past while listening. If an active sweep contributed, the word SWEPT is on this line, on the page that is always shown.

Page two, the rest

Netmask, gateway, DNS

The addressing the lease actually handed out.

Public address

Shown only if it was learned. A blank line and a zero address are different things and are not allowed to look the same.

802.1X

Whether the port asked us to authenticate. Never whether it did not: see further down this page for why that state does not exist.

It goes back on its own

20 seconds after the last press the screen returns to the verdict, so a tester left on a desk is never showing a page somebody turned to yesterday.

While you hold the button

HOLD 1.5 s

SHARE ON, SHARE OFF, or NEEDS KEY

Which way it will go, that it reboots the tester, and that keeping hold reaches something else. Over an open hotspot it says NEEDS KEY instead, and letting go changes nothing. Nothing else on the device mentions the five second hold, so without this line it is undiscoverable.

HOLD 5 s

OPEN WIFI

That releasing clears the password and that anyone will be able to connect, or, with sharing on, that it also turns sharing off and reboots the tester. Both holds act when you let go, which is what makes this worth printing: there is still a decision left to make while you are reading it.

When a name is too long for the panel it is cut and the cut is marked with a >. A clipped switch name is not a shorter name, it is the wrong name, and a technician acting on it walks to the wrong rack. Nothing on this screen is allowed to be trimmed silently.

The image shifts by a pixel every minute. A verdict screen holds the same word in the same pixels for as long as the instrument is on, which is not the duty cycle OLED lifetimes are quoted at.

If the screen stops answering, the tester gives up on it after five failed checks, or after three seconds of them, whichever comes first, and carries on without it. It also asks the bus BEFORE sending a frame rather than after: a display that has come loose must not make the instrument slower, and it would, because each attempted frame is dozens of stalled bus transactions in the same loop that watches the link. Asking first turns about a second into fifty milliseconds.

The web console

Getting to it

The tester runs its own WiFi access point. Join it from a phone or a laptop and open the address below. Nothing is installed, and no internet connection is involved: you are talking to the instrument directly.

The hotspot is open when the device leaves the factory. You can set a password under Setup, and if it is forgotten, the five second button hold clears it. Joining the hotspot puts you on the tester, not on the network it is testing: with sharing off it forwards nothing between the two.

Connection

Network nameJACKPROBE

Addresshttp://172.16.0.1

Or by namejackprobe.local

Passwordopen by default

Key length8 to 63 characters

Serial consoleUSB-C, 115200 baud

Setup

Every setting, and what it changes

The console is a panel with a rail down the side: the drop, the segment, the switch and port, the reports, and setup. On a phone that rail becomes a row of controls at the bottom, within reach of a thumb. Everything below lives under Setup, and the ones that were true when a test ran are also printed under the verdict, beside the result they belong to.

Saved reports

The list of reports held on the tester, newest first. From here you open one, rename it, delete it, download one, download all of them as a ZIP, or delete every one of them. Renaming changes the label, never the date.

Internet sharing

Shares the tested drop's internet connection with the phone joined to the hotspot. Off unless you turn it on, and only the button can: set a hotspot key, then hold the button until the light turns amber. Here you can see whether it is on, and turn it off. While it is off, the tester forwards nothing between the hotspot and the tested drop, and the hotspot offers no router; the status the console serves counts the packets refused.

Active sweep

Arms or disarms the ARP sweep described below. Off unless you turn it on, and it asks first. Arming the setting does not run a sweep by itself; the sweep itself is a separate button on the console, next to the segment inventory.

Time zone

Which zone report timestamps are written in. The choice is stored and survives a restart. Daylight saving is handled by the zone rather than by a fixed hour offset, so a report taken in March and one taken in November are both right.

Hotspot key

Sets or clears the hotspot password. Leave it empty to keep the hotspot open. With internet sharing off, a change restarts the access point only, so the phone you are holding drops off and has to rejoin. With sharing on, any change restarts the whole tester, and clearing the key also turns sharing off.

Internet check

What the tester connects to in order to prove a drop reaches the internet, as an address and a port. It completes a TLS handshake there, which a captive portal cannot answer. Change it if your network blocks the default of 1.1.1.1:443, and prefer an address over a name: this check exists to tell a broken resolver from a broken uplink, and it cannot do that if reaching it needs the resolver. It cannot be pointed at the network under test: an address inside the tested drop's own subnet is refused when set, and a target that comes to resolve there is skipped rather than probed, with the internet reported as not tested.

Notifications

A webhook address. Each time a report is saved the tester posts a summary there. See below for exactly what it sends and what it does not. It cannot be an address on the network under test: one inside the tested drop's own subnet is refused when set, and judged again on what it resolves to before every send, so the tester never posts a network's own findings to a machine on it.

About this unit

Serial number, firmware version, time zone, and how much report storage is left.

Reports

What is saved, and how to get it out

A saved report is one HTML file. Everything it needs is inside it: no images to fetch, no stylesheet to find, nothing that stops working when it is mailed to somebody else. It opens in any browser and prints cleanly.

It carries the verdict, every reading, the label and the notes you typed, the switch and port where those were advertised, the unit's own serial, and both local time and UTC.

Reports are held in the tester's internal flash. There is no memory card. To get them out, use the web console: download one from the button beside a report, or all of them at once as a ZIP.

Storage

Whereinternal flash

Partition3.4 MB

Capacity394 reports

One reportabout 6 KB

Memory cardnone

Capacity was measured by filling the partition, not estimated from a file size. The console shows a slightly lower number as it counts down, because a report grows a little with a longer label and longer notes.

Notifications

The webhook, precisely

What it sends

An HTTP POST with a flat JSON body, each time a report is saved. It carries the verdict, the label and notes, the report's filename, the unit serial and MAC, local and UTC time, link state and speed, whether DHCP answered, the IP, gateway and public address, the gateway, DNS and internet results, the gateway latency, and the switch name, port and VLAN where they were advertised.

What it does not

It does not send the HTML document, only the summary. Nothing is queued and nothing is retried, so a POST that fails is lost and the console says so. It is not attempted at all on a drop with no internet, for the obvious reason.

HTTPS addresses are accepted but the certificate is not verified. This device has no certificate store and no clock until the drop has internet, so a check would be theatre rather than security.

Treat it as a convenience, not as a record. The report on the tester is the record. The webhook is a copy sent once, on a best effort, to somewhere you chose.

Listening

What the tester overhears, and what that is worth

Three things are learned by listening rather than asking: the switch, whether the port wants you to authenticate, and what else answers DHCP here. Nothing is transmitted to obtain any of them.

None of these can tell you something is absent. That is a property of listening, not a shortcoming we intend to fix, and the tester will never claim otherwise. Read the next two panels before relying on a quiet result.

802.1X

It can tell you a port asked. Never that it did not.

A switch enforcing 802.1X sends an identity request when a device appears, then a couple more, and then stops. Re-authentication is off by default on most switches. So on a port whose requests finished before you plugged in, no amount of waiting will produce one.

That is why there is no "802.1X not in use" reading. A tester that offered one would be inventing it out of a silence that proves nothing. What you get instead is what was heard, with how long it listened and how many frames went past while it did.

DHCP

It reports what answered. Not how many exist.

The useful finding is a second DHCP server: two of them handing out conflicting addresses is a real outage, and the second is usually a small router somebody plugged into a wall port. The tester names both, with the MAC address of each, which is what you need to find the port it is on.

It cannot tell you there is only one. Moving between jacks, the tester usually renews the address it already has rather than asking from scratch, so nothing prompts a second server to speak up and its silence means nothing.

Reading a quiet result

"No 802.1X seen yet. Listening 26 s, 344 frames."

Nothing was heard, and the segment was busy while we listened. The tester is working; either the port does not use 802.1X, or its requests finished before you arrived. You cannot tell which from here, and neither can the tester.

"Nothing heard at all in 26 s."

Zero frames. This is a statement about the tester, not about the network: on a live segment something always arrives. Suspect the cable or the port before you suspect the finding.

"This port asked us to authenticate, and let us on anyway."

A request was heard and an address was still handed out. Open mode, a guest VLAN, an auth-fail VLAN and MAC address bypass all look identical from outside, so the tester names all four rather than guessing. It never says a port is enforcing anything, because a port configured to ask and then let everyone through sends exactly the same frames as one that does not.

"Not checked: the tester could not listen on this jack."

The listening tap is not in place. Nothing about 802.1X or DHCP on this report means anything; treat those sections as blank rather than as negative.

Segment inventory

What else is on this segment

Every MAC address the tester sees while it listens goes into a table on the console: how it appeared, its address if it has one, its vendor, and any name or class it volunteered over DHCP. Getting into this table never requires a question; entries arrive from ordinary ARP traffic, from DHCP requests the tester overhears, and from IPv4 frames that pass the tap.

Vendor column

Names the network card. Not the device.

The vendor is read from the first three bytes of the MAC address, the block a manufacturer registered for its network interfaces. A Raspberry Pi reads as "Raspberry Pi Trading" whether it is a media player or a door controller, and a laptop with an Intel network card is not an Intel product. Read the column as who made the interface, never as what the box does or who owns it.

Randomised addresses

No manufacturer was ever assigned one.

Most phones and recent laptops randomise their MAC address by default. That is not a lookup that failed, it is a different category: nobody registered the address, so there is nothing to find, and the row says "Randomised address, no lookup performed" rather than sitting blank next to a real vendor name, which would read as a broken lookup instead of the truth. A third label, "Not in registry", is different again: that address is globally unique but the block is not in the tester's copy of the registry, which is a gap in the table rather than a property of the device.

A passive listen and a swept run do not read the same, on purpose. The line above the table states how many devices were seen, over how long, and out of how many frames, the same way the other listening features on this page do. When a sweep contributed, that line says so, with how many addresses were sent an ARP request and how many answered, and every row the sweep is the only reason for reads "Sweep only" rather than "Volunteered". A saved report carries the same distinction, so nobody reading it later has to take your word for which mode produced it.

Active sweep

The one thing this instrument transmits to discover

Off by default, and it asks before it runs. The active sweep sends an ARP request to each address across the local subnet, one at a time, to see what answers. It stays at Layer 2 on purpose: it does not leave the broadcast domain, open a connection, or probe a port. It transmits, which is detectable, and on a secure or monitored network that can get the port flagged or shut down, so it is a setting you turn on rather than a default, and the console warns you before you enable it.

Turn the setting on under Setup, then run the sweep from the button on the segment inventory card. A run takes two to three seconds, and the table above it fills in as replies arrive. Four things govern whether it sends anything at all, and the console names the one that applies:

The setting is off

Where it starts, and where it stays until you turn it on. Nothing is sent.

No address on this drop

No DHCP lease means no subnet to sweep. Sweeping a guessed range would be guessing, not sweeping.

The subnet is wider than a /24

It still runs, capped at the first 256 addresses instead of the tens of thousands the full range would take, and the report says the run was capped.

Internet sharing is on

Both settings can get a port flagged, and they should not compound without you choosing that, so the sweep refuses until sharing is turned off first.

Internet sharing

Read this before turning it on

It makes the tester a router. With sharing on, the device forwards traffic from the phone on its hotspot out through the tested drop. That is exactly the behaviour network access control looks for, and on a client's secured network it can get the port shut down and you escorted out of the building. It is off unless you turn it on, and only the button can turn it on. The console cannot, from the hotspot or from the network under test, because anyone who can reach that page could. Set a hotspot key, then hold the button on the tester for 1.5 seconds. It never shares its connection over an open hotspot, so clearing the key turns sharing off. Turning it off always works, from anywhere. The sensible default on any network you do not own is to leave it alone.

With sharing off, it forwards nothing. Every packet that would cross between the hotspot and the tested drop, whichever way it is going, is refused inside the tester's network stack, and the console counts them (fwd_refused in the status it serves). The hotspot also stops offering itself as a router, so a phone joined to it has no route through the tester to begin with. This was not so before 0.10.1: the stack underneath forwarded whenever it could, and a phone on the hotspot could reach the tested network with its own address on the packets. It was seen on a bench, fixed, and the fix was watched refusing 126 packets while a capture on the far side saw none. The changelog has the account.

What it is genuinely useful for: your own bench, a site you own, or a situation where you need the phone online to look something up and the drop you are testing is the only connection in the room.

Time

What the timestamps are worth

The clock is set by SNTP the first time the tester reaches the internet through a drop. Your time zone choice is stored and survives a restart; the clock itself is not, so after a power cycle the time is only as good as the next successful sync.

A report saved before any sync is stamped honestly rather than plausibly: its filename says there was no clock and gives the uptime instead of inventing a date. Those reports sort to the bottom of the list, because they have no place on a timeline.

If exact times matter for the work you are doing, plug the tester into a drop with internet before you start, and keep it powered.

Timing

How long a test takes

934 milliseconds, and about once a minute a little over four seconds. Both figures are measured, and the second one has a reason.

The number on the front page is not an estimate. It comes out of the log the tester wrote about itself: twenty-two consecutive runs on a healthy jack, every one of them between 923 and 943 milliseconds.

Roughly one run a minute takes four seconds instead. That is not a slow jack and not a fault. The tester also looks up how the drop is seen from the internet, which is a name lookup plus a request that has to go out and come back, and it keeps that answer for sixty seconds rather than asking again on every run. The run that pays for it is the one that refreshes it.

Every leg is timed separately and written into each record, so a run that took longer than usual can say where the time went rather than leaving it to be guessed at:

Leg	Typical	On the run that refreshes
Name resolution	13 ms	13 ms
Internet, by completed TLS handshake	488 ms	488 ms
Gateway, three echoes	450 ms	450 ms
Public address	not asked	3067 ms
Whole run	934 ms	4019 ms

The typical column does not add up, and that is not an error in it. Its three legs come to 951 ms and the typical whole run is 934. Each figure is the middle value of that leg across twenty-two runs, and middle values do not add: within any single run the legs do sum to that run's total, but the legs are not all slow on the same run, so the middle of each lands 17 ms above the middle of the whole. The refreshing column is one kind of run rather than a middle, and that one does add.

The gateway leg is the interesting one. The gateway here answers in under a millisecond, and the leg still costs 450 ms, because it is three echoes with a gap between them rather than one. When a cable is pulled out during a test, the same leg costs 2101 ms, which is three timeouts of 700 ms exactly: the tester waiting on a gateway that is no longer there.

These are readings from one unit on one network, not a specification. A jack with a slow resolver or a distant gateway will produce different numbers, and the tester will report them rather than the ones printed here.