jdbdump - Dumps fields from the DHCP dynamic databases.
/usr/sbin/jdbdump [-a] [-c] [-e] [-f character] [-k key] [-s date] tag...
-a Dumps dates in a readable form. The default is to dump all date-time
fields as UCT (seconds since GMT 1/1/70 00:00).
-c Display currently active leases only.
-e Display expired leases only.
Uses character as the field separator. The default is the pipe (|)
Requests that a specific record with the given key be dumped. The key
has three fields: the client's hardware type, hardware address, and IP
address of its subnet. These three components should be separated by
whitespace and enclosed within quotes (otherwise the shell will create
Dumps records timestamped since date. The default is to dump all the
records regardless of the date of last modification.
The jdbdump command reads the databases used by the joind daemon to store
information on client IP address leases and dynamic names and prints
selected fields. Each record is terminated by a newline, and the fields
within each record delimited by default with the pipe (|) character,
although this may be changed with the -f command line option. Date fields
are displayed in Universal Coordinated Time (UCT), seconds since 00:00
01/01/1970 GMT, unless the -a option is given, which alters the format to a
more readable form.
The following fields are always dumped:
This is the identifier which uniquely identifies the client. It may be
the client's MAC address or an opaque object, uninterpreted by the JOIN
Client id type
If nonzero, then the client id is the MAC address of the client
corresponding to this type. If zero, then the client id may be any
byte array which serves to uniquely identify the client.
Client id length
The length of the identifier in 8-bit bytes. Note that if the client id
corresponds to a MAC address then this field is redundant. But in the
more general case, it may be needed in order to determine whether the
client id is to be interpreted as a literal or as a decimal or hexade-
cimal encoding of a byte string. Resolving this ambiguity becomes
important when a file produced by jdbdump has to be reloaded into the
database by jdbmod.
The IP address assigned to the client. If this value is null or
0.0.0.0 it means "none". The presence of this value does not neces-
sarily mean that the client is actually at this address. Even when the
lease is unexpired, clients may hold valid leases on addresses for more
than one network. If the client has assignments on n different net-
works, then jdbdump will generally dump n different records for that
The time at which this lease began.
The time at which this lease will expire.
The time at which this lease may be renewed. Requests to renew the
lease prior to this will be answered by a reply determined by the resi-
dual time remaining on the lease until expiration. After this time has
passed, the client will receive an entirely new lease whose duration is
determined by the bootptab database.
Time when client last acquired or renewed this lease.
IP address of server "owning" the lease.
The client's name (without the domain name).
The client's domain (without the leaf name). If a client's fully quali-
fied domain name were a.b.c.d, the hostname field would contain a and
the domain field would contain b.c.d.
These fields are any fields given by the command line tag arguments.
These tags identify DHCP configuration parameters. They may be
numeric, a two character symbol, or the parameter's long name. See
RFC2132 for the numerical values or see bootptab(4) for the symbolic or
long names. Note that the values dumped are those that the client
would have were it to occupy this IP address. It does not necessarily
mean that the client is presently operating with those values.
Following these fields are any fields given by the command line "tag" argu-
ments. These tags identify DHCP configuration parameters. They may be
numeric, a two character symbol, or the parameter's long name. Consult
RFC1533 for the numerical values or see bootptab(4) for the symbolic or
Commands: jdbmod(8), joind(8)