In brief
A record answers "which device, which IP, when"; a wrong clock breaks the third answer. NTP monitoring, drift levels, and why the timestamp service's time is independent evidence.
An internal IP assignment record answers three questions: which device, which internal IP, when. The first two come from the network and cannot be wrong. The third comes from the box's clock. If that clock is ten minutes behind, a third of every record is wrong, and the error can go unnoticed for years. This post explains why the clock matters so much, how the box monitors it, and what "timestamp offset" means.
Why the clock is critical
If records are ever reviewed, it will be because of a question from outside: "Which subscriber was behind traffic from this public IP at this date and time?" The question arrives with the operator's clock. You kept your records with your box's clock. If the two differ:
- You may point to the wrong guest; the same internal IP belonged to another device an hour earlier.
- The day boundary shifts; a record from 23:55 ends up in the wrong day's chain.
- Session lengths, idle calculations and reports become inconsistent.
Clock error starts small. A device's crystal drifts a few seconds a day; over a year that is minutes. Without regular syncing, nobody sees the drift.
NTP: how the box syncs its clock
NTP (Network Time Protocol) lets a device correct its clock against trusted time servers. As long as the box is running, it talks to NTP servers and adjusts. This happens in the background; you never see it.
Hotspot-Box goes one step further: it monitors that the sync actually works. The panel shows two things:
- Last successful sync. When did the box last reach an NTP server?
- Measured drift. The difference between the box's clock and the reference.
If syncing stops or drift grows, the panel raises an alert. Alerts arrive through the same channels as everything else, e-mail, Telegram or webhook, alongside disk usage and SMS credit warnings.
Warning and critical: two levels
The drift alarm has two levels.
| Level | What it means | Likely cause | What to do |
|---|---|---|---|
| Warning | Drift above normal, or sync has been failing for a while | NTP server intermittently unreachable; DNS problem; UDP 123 blocked on the router | Check internet and DNS; if it does not clear within a few hours it escalates to critical |
| Critical | Drift large enough to affect record reliability, or no sync for a long time | Extended connectivity loss; wrong NTP server address; hardware clock fault | Act now; restore internet, verify the NTP setting, ask for support if needed |
Warning means "take a look", critical means "fix it today". Both should clear on their own: once syncing resumes, the alarm drops. An alarm that does not clear is an ongoing problem.
Timestamp offset: independent evidence
The box computes a SHA-256 digest of each day's records and obtains an RFC 3161 timestamp for it. The service that issues the stamp writes its own time into it. That time is not the box's clock; it is an independent clock from outside, beyond the box's control.
The panel reports the box's clock relative to the timestamp service. We call this the "timestamp offset": the difference between the box's current time and the time in the stamp. Having two clocks check each other tells you:
- If the offset is small, the box's clock is trustworthy, and so is the time on the records.
- If the offset is large, the box's clock has drifted. But the stamp still proves that the day's digest existed at the moment of stamping.
That second point matters. Even if the box's clock were somehow wrong, the stamp is an outside witness saying "this record existed no later than this moment". The records never go to the timestamp service, only the digest, so the witness does not know the content; it testifies only to existence and time.
The verification report shows each day's stamp time. The gap between the day's close and the stamp is normally minutes; for days queued during an internet outage it can be hours or days, and the report states that plainly.
The clock on a virtual appliance
If you run the software as a virtual appliance there is one more detail: the virtual machine's clock initially comes from the host (the hypervisor). If the hypervisor's guest tools also try to correct the time, two mechanisms compete and the clock jumps back and forth. Pick one source: either disable the hypervisor's time sync and leave it to the box's NTP, or the other way round. Monitoring works either way and shows the jumps as warnings.
Checks when an alarm arrives
- Is the internet up? If the box is offline, NTP cannot work either; fix connectivity first.
- Does DNS work? If NTP server names cannot be resolved, there is no sync.
- Is the router blocking UDP 123? Some routers and firewalls block NTP traffic.
- Is the NTP server setting correct? Are the servers configured on the box reachable?
- Was there a power cut? A freshly rebooted box can show a large drift before its first sync; give it a few minutes.
- Is the alarm still on? If everything above is fine and the alarm does not clear, contact support.
Preventive habits
- Put the box on a UPS; fewer reboots.
- Use Telegram as the alarm channel; a clock alarm in e-mail gets overlooked.
- Glance at the timestamp offset in the panel once a month; it should be near zero.
- When you replace the router, confirm NTP still gets through.
The clock is the quietest component of the box. When it works, nobody notices; when it fails, the value of the records quietly erodes. That is why monitoring it is part of the product. See the box page for the record architecture and the FAQ for other questions.
This is a technical guide, not legal advice.