QR Support
QR Support
QR Support hands a live report about a device or a switch from an appliance to an engineer who is nowhere near it, without the appliance itself needing an internet connection. The report is turned into a QR code on screen; whoever is on site scans it with a phone, and a colleague elsewhere reads it back on privatelan.nl.
This is built for isolated and air-gapped networks, where the appliance deliberately has no route to the outside world. The appliance never sends anything itself — the phone that scans the code does, and only because it happens to have internet of its own.
Every report, for a device or for a switch, opens with the system name you set yourself under System settings, together with the licence identifier of the appliance — which is what PrivateLAN support uses to tell which customer a report belongs to. Both sit inside the encrypted report, so they are readable only by whoever you give the key to. The hand-off itself never sends anything that identifies you to privatelan.nl in readable form. If the system name is left empty the report simply shows a dash, so it is worth filling in.
One exception, so it is stated rather than discovered: if the report is opened by somebody who is signed in to privatelan.nl, their browser looks the licence identifier up so the page can name the installation. That lookup is made by their browser after decryption, never by the hand-off, it only answers for systems that account may already see, and it is not stored with the report. Whoever scans a code on site is not signed in, so nothing of the sort happens there.
Generating a code for a device
Open the device page and press QR Support in the Monitoring and control panel. A dialog opens where you tick which reports to include:
| Report | Contents |
|---|---|
| Running config | The configuration of the device's interfaces |
| Interface status | Link state, speed, duplex and counters |
| Authentication status | The 802.1x session on the port |
| MAB status | MAC Authentication Bypass state |
| Power | PoE consumption and class |
| MAC address table | The addresses learned on the port |
| LLDP neighbors | What the port sees on the other end |
| Log | Log lines mentioning this interface |
| Ping from switch | A ping to the device, issued by its own switch |
| ARP table | The ARP table of the device's VLAN |
Everything except the log and the ARP table is ticked to begin with. Those two are marked as large, because they are: the ARP table covers the whole VLAN rather than just this device, and on a busy network it alone can double the number of QR codes. Leave them off unless you need them.
The appliance then queries every switch the device is patched into — one session per switch, regardless of how many reports you ticked — and shows:
| Item | Description |
|---|---|
| QR code | One or more codes to scan, shown one at a time with Next |
| Code | Eight digits, used to find the report afterwards |
| Key | Sixteen characters, used to decrypt it |
In practice the default selection fits in one or two codes. Both the code and the key are shown on screen. Write down or photograph both if the report is going to be collected by someone typing them in rather than scanning.
What a device report always contains
Whatever you select, the report opens with the device's own registration, so the engineer reading it can judge the switch output against what the appliance believes the port should be doing:
- Device name, device group and VLAN, IP address and security mode
- The allowed MAC addresses
- For MAB and PEAP: the authentication username and password
- For a device with generated client certificates: common name, alternative names, generation and expiration date, and validity period
The authentication password is included deliberately — it is usually what an engineer is diagnosing when 802.1x refuses a device. Bear in mind that it therefore travels with the report, encrypted, and is readable by anyone you give the QR code or the code and key to. If that is not wanted for a particular hand-off, use a report the device does not authenticate with, or share the code and key over separate channels.
Switch reports
The same hand-off works for a switch. On the Switches overview, press the QR icon in the actions column of the switch you want to report on.
A switch report is built entirely from what the appliance has already read from that switch, so it appears immediately and still works when the switch itself is unreachable. It always opens with what the appliance knows about the switch: name, group, IP address, type, model, serial number, software version and location, followed by its status, whether the appliance has an SSH session to it, ping time, CPU, temperature, PoE usage, uptime and, for a stack, the number of units. The moment that data was read is stated with it, so the engineer can see how fresh the picture is.
On top of that you tick what to include:
| Report | Contents |
|---|---|
| VLANs | The VLANs on the switch, with their names and any routed addresses |
| Interface status (up/down) | One line per port: up or down, the VLAN and the description |
| Configuration (credentials removed) | The switch's running configuration |
The first two are ticked to begin with. The configuration is marked as large, because a full running configuration is by far the biggest thing a report can carry.
Passwords, community strings, keys and password hashes are removed from that configuration by the appliance before anything is encrypted — they appear as **. This happens on the appliance itself, so no credential leaves it in the first place.
Sending it
There are three ways to get the report out, and they all end at the same place:
- Scan it on site. The phone opens privatelan.nl, uploads the encrypted report and shows it straight away. Where the report is split over several codes, use Next on the appliance and scan them one after another — the last scan shows the complete report.
- Photograph the code. Send the photo to a colleague through any channel you like. They scan the photo and see the report, without needing the code or key separately.
- Read out the code and key. Your colleague opens privatelan.nl/support/qr-support, enters the eight digits, and then the key. Both are needed.
What is stored, and for how long
The report is encrypted on the appliance before it is turned into a QR code. What reaches privatelan.nl is that encrypted block and nothing else: the key stays in the scanned link and in your browser, and is never sent to any server.
PrivateLAN therefore cannot read the reports passing through this feature, and neither can anyone who obtains a copy of the database behind it. Reports are removed automatically after 7 days.
Anyone holding the QR code, or both the code and the key, can read the report. Treat a photograph of a QR code the same way you would treat the configuration itself.
Who can use it
QR Support carries data off the appliance, so it is deliberately restricted twice over:
- It must be included in the appliance's license. Without the option the button does not appear at all, which lets an organisation rule the capability out entirely.
- The user must hold the matching Can generate a QR Support code role — there is a separate one for devices and for switches. Roles are managed per user under user management.
Every generated code is written to the audit log, including who generated it, for which device or switch, and when. The key is deliberately not recorded there — an audit log that contained it would be enough to read the reports back.
Requirements
- The phone or computer that reads the report needs a reasonably current browser (Chrome, Safari, Firefox or Edge). Decryption happens in the browser itself.
- The appliance needs no internet access whatsoever, which is the entire point.
