Device discovery and inventory

Software 3.4 · reviewed 2026-07-29

How a device is found

Discovery is deliberately dull. For every address in a range the unit sends one SNMP GET for sysObjectID and sysDescr. Anything that answers is asked four more questions; anything that does not answer twice is dropped and not retried until the next scheduled scan. There is no ping sweep, no port scan and no mDNS: a printer that ignores SNMP is invisible to the unit, and that is the correct behaviour.

Step	Asked for	Used as
1	sysObjectID	Vendor and platform family
2	sysDescr	Model string, and firmware on most platforms
3	prtGeneralSerialNumber	Serial number — the identity anchor
4	sysName	Display name, if the site has set one
5	ifPhysAddress	MAC, the fallback identity anchor

Scan ranges and schedule

Ranges are written in CIDR or as a start–end pair. Keep them tight: a /16 is 65,536 addresses and a scan that takes eleven hours is a scan nobody waits for.

mluctl scan range add 10.20.4.0/24 --label "HQ floor 2"
mluctl scan range add 10.20.5.10-10.20.5.60 --label "HQ floor 3 printers"
mluctl scan range list
mluctl scan run --range "HQ floor 2"

Default schedule	Full scan nightly at 01:30 site time
Parallelism	32 addresses at a time, fixed. Raising it upsets small switches more than it saves time.
Timeout	1.5 s per probe, two attempts
Typical rate	a /24 in about 25 s
Staggering	Ranges with different labels are scanned in sequence, never together

On sites above 150 devices, split the ranges by label and let them run in sequence. Poll load then never peaks, and a branch link carrying a nightly backup is not also carrying a scan.

SNMP credentials

One default credential plus exceptions per range. The unit tries the range-specific credential first, then the default, then gives up — it never walks a list of guesses, because three failed SNMPv3 authentications in a row lock accounts on some platforms.

Version	Fields	Notes
SNMPv1	community	Accepted for old devices. Read-only; the unit never writes.
SNMPv2c	community	The common case. Still plain text on the wire.
SNMPv3	user, auth (SHA), privacy (AES)	Preferred where the fleet supports it. Note that a few MFPs support v3 for status but answer meter OIDs only over v2c.

Read-only, always. The unit asks for nothing it cannot read and has no write community configured anywhere. If a platform requires a write community to expose meters, document the exception and raise it with the manufacturer rather than storing one here.

Profiles and matching

A profile says where the useful values live on a given platform: which OID holds the mono counter, whether colour is split by size, how supplies are numbered. The unit ships with profiles for the common platforms and falls back to the standard Printer MIB for everything else.

Match result	What you get	What to do
Exact	All counters and supplies, per-model thresholds	Nothing.
Family	Total pages and main supplies; size breakdown may be missing	Usable. Report the model to the documentation desk so a profile can be added.
Generic	Total pages only, supplies as percentages	Check the total against the device’s own configuration page before billing on it.
None	Device listed, no readings	It answered SNMP but not the Printer MIB — often a print server box or a scanner. Exclude it.

mluctl device show 10.20.4.31
mluctl device profile 10.20.4.31 --set kyocera-ecosys-generic
mluctl device profile --list | grep -i versalink

Identity and duplicates

A device is the serial number, not the address. When an address changes the record follows it; when a serial changes at the same address the unit treats it as a new device, because that is what a replacement is.

Serial number matches an existing record → same device, address updated.
No serial reported, MAC matches → same device.
Neither matches → new record.
Serial matches and a second live device reports the same serial → both are flagged ambiguous and neither is billed until a human decides.

Rule 4 is not theoretical. Some budget devices report a blank or a constant serial. The unit falls back to MAC for those automatically, but if a whole batch reports the same serial and is behind one NAT, discovery cannot tell them apart and neither can you. Address them statically and exclude the range from serial matching.

Manual and excluded devices

Two lists exist for the awkward cases: devices that are outside any scan range and must be polled anyway, and devices that answer but should never be recorded.

# a printer on a subnet we do not scan
mluctl device add 10.60.2.9 --credential "branch-v3" --label "Branch North reception"

# stop recording something that is not a printer
mluctl device exclude 10.20.4.250 --reason "print server appliance"
mluctl device exclude --list

Excluded addresses are still probed — cheaply — so that the exclusion can be reviewed when the thing at that address changes. Nothing about them reaches reports or alerts.