Skip to content
Hotspot-Box

What is inside one day of the archive?

Published: 08 October 2026Updated: 10 October 20264 min read

In brief

We open the ZIP you export from the panel: record rows field by field, the manifest, the timestamp file. No guest name, no message. And how to verify it with three commands.

Opening the ZIP

When you pick a day in the panel and export it, you get a ZIP file. Most business owners never open it; they say, reasonably, "the panel verified it, that is enough". But one day someone other than you will open it: an inspector, an expert witness, your own IT team. Knowing what is inside puts you at ease.

In this article we walk through an example day's directory. The rows are entirely fictional; file names and field order may differ slightly in your installation. The structure below is for explanation and is not a downloadable sample file.

Directory layout

A day is a directory named after itself. It holds three kinds of file:

2026-09-14/
  sessions.csv        record rows
  manifest.txt        file digests and chain link
  manifest.tsr        RFC 3161 timestamp token

When you export several days, there is one directory per day and, at the root of the ZIP, the verification report produced by the panel. The timestamp service's certificate chain is included too; openssl will need it.

Record rows, field by field

Three fictional rows:

start,end,mac,ip,nat_ip,nat_port,auth_type,auth_ref
2026-09-14T08:12:31+03:00,2026-09-14T09:40:02+03:00,a4:6b:xx:xx:21:0e,10.20.1.57,203.0.113.8,41022,sms,c1f3…9a
2026-09-14T08:15:04+03:00,2026-09-14T08:31:48+03:00,d8:3a:xx:xx:7c:f1,10.20.1.58,203.0.113.8,41023,coupon,KFE-4D7Q
2026-09-14T12:02:19+03:00,2026-09-14T14:02:19+03:00,f0:9e:xx:xx:b3:44,10.20.1.61,203.0.113.8,41031,email,7e02…d4
Field Meaning Note
start, end Session start and end Time zone included; clock synchronised by NTP
mac The guest device's hardware address Partly hidden in the example
ip The internal IP the box assigned to that device Official requests are matched on this field
nat_ip, nat_port Public IP and port, where present Lets you match a request behind CGNAT or a single public IP
auth_type Verification method sms, coupon, email, user
auth_ref Verification reference The phone number is never written in clear; it is kept encrypted or as a digest. A coupon code appears as is.

Look at the third row: the session lasted exactly two hours and then closed. That is the session limit defined in the plan expiring; the record closes even if the guest never logs out.

What is absent matters as much

The file does not contain: the guest's name, the sites they visited, URLs, message content, location, or the text of the SMS. The box does not collect these, so it cannot export them. When you show the archive to an inspector, say this plainly: the record is a record of internal IP assignment, not of content.

Phone numbers are stored encrypted in the box and shown masked to the authorised role in the panel. The format of the auth_ref field in the exported file depends on your installation setting; in no case is the number written in clear in the row.

manifest.txt is the day's fingerprint. Fictional content:

day: 2026-09-14
prev: 5b2e…c7a1          digest of the previous day's manifest
sha256 sessions.csv  e3a9…41f0
rows: 318

It does two things. First, it lists the SHA-256 digest of every file in the day; change one character in a file and the digest no longer matches. Second, through the prev line it carries the digest of the previous day's manifest, which ties today to the past. What we call the chain is simply manifests holding on to each other through this line.

The timestamp file: an independent witness

manifest.tsr is the RFC 3161 timestamp token. The box sends the digest of the manifest file to the timestamp service; the service writes its own clock next to the digest and signs it with its own key. The file is binary and will not open in a text editor; openssl reads it.

Once more: only the digest goes to the service. sessions.csv never leaves the box.

Verification in three commands

A computer with openssl and sha256sum is all you need. From inside the day's directory:

1. Do the file digests match the manifest?

sha256sum -c <(grep '^sha256' manifest.txt | awk '{print $3"  "$2}')

The output should be sessions.csv: OK. If not, the file changed after the manifest was written.

2. Is the chain tied to the previous day?

sha256sum ../2026-09-13/manifest.txt

The resulting digest should equal the prev line in today's manifest. Do this for several consecutive days and you have walked the chain by hand.

3. Is the timestamp valid, and does it belong to this manifest?

openssl ts -verify -data manifest.txt -in manifest.tsr -CAfile tsa-chain.pem

The output should be Verification: OK. That one line says three things at once: the token was signed by a valid service, it belongs to the digest of this manifest, and the time inside it is the time it was issued. To see the timestamp's date, openssl ts -reply -in manifest.tsr -text prints the token's contents as text.

If all three commands say OK, you hold a day that is intact, chained and dated. The panel's verification report runs the same three checks for you; the commands show that you can reach the same result without the panel.

If verification fails

Symptom Likely cause What to do
Command 1 FAILED File changed or was corrupted after export Export again from the panel or the SFTP copy
Command 2 does not match The previous day comes from a different export Export both days in the same run
Command 3 errors Certificate chain missing or timestamp file belongs to another day Use the certificate file from the ZIP, check the directory

If there is a genuine integrity problem in the file, do not hide it; compare against the panel's verification report and the SFTP copy, and note the result.

Why it matters

Opening one day's file and running these three commands once takes ten minutes. After that you say "the records are signed" from knowledge rather than from memory. Inspectors and expert witnesses can tell the difference.

You can read about the box's record-keeping mechanism on the box page; contact us with technical questions.

Let's talk about your business

How many devices connect, and which sign-in method do you want? We will show you in a 20-minute demo.