OMAPI: Retrieve lease object given hardware-address and state

[Robin Breathe]

Greetings to all.

I run ISC-DHCP 3.0.2 on our halls of residence network (multiple 
subnets). I'm currently in the process of developing an ARP consistency 
database. It will retrieve a copy of the live ARP table from a router at 
the core of the network and then check each record against DHCP. I hope 
to individually lookup each IP/MAC address retrieved from the router via 
OMAPI with the aim of finding inconsistencies (i.e. IP spoofing, manual 
configuration post-lease, etc).

Given the IP address from ARP (arp_ip), I need to retrieve the expected 
hardware-address (exp_hw) from DHCP - that associated with the arp_ip 
lease object. This is to catch users masquerading as others. I also want 
to know the hardware-address that should be using arp_ip.

Given the MAC address from ARP (arp_hw), I need to retrieve the expected 
ip-address (exp_ip) from DHCP. This is to catch users who, having 
obtained a valid lease, assign themselves a different IP address. I also 
want to know the ip-address that they *should* be using.

Lastly, if neither MAC nor IP are known, I want to know about it.

Anyhow, the point of this query... despite what it says in dhcpd(8) I 
don't seem to be able to filter lease objects by 'state'.

Given ip-address I can always retrieve a unique lease object. It seems 
though that 'state' on my lease object set prior to 'open' is ignored 
(dhcpd(8) indicates that 'state' is a valid lookup field on lease 
objects). When I specify 'state = 2', and there's no match I'd expect to 
receive a "no match" error. The actual behaviour -- of ignoring 'state' 
-- is unexpected but not a showstopper since a unique record is 
retrieved none-the-less, and I can determine state with post-processing.

The real problem comes when I start trying to lookup leases given just 
hardware-address/-type. If I specify only hardware-address, 
hardware-type and state, it more often than not reports that "more than 
one object matches key". Manual inspection of the leases file makes it 
apparent that in these cases there are indeed multiple leases with the 
same hardware-address (for example in different subnets), but that only 
one is active (I have "one-lease-per-client on" set). Thus ignoring 
'state' has become a real problem, since I can't retrieve *any* lease 
object.

Examples with omshell(1):

 > connect
obj: <null>
 > new lease
obj: lease
 > set ip-address = 161.73.60.192
obj: lease
ip-address = a1:49:3c:c0
 > set state = 2
obj: lease
ip-address = a1:49:3c:c0
state = 2
 > open
obj: lease
ip-address = a1:49:3c:c0
state = 00:00:00:01
dhcp-client-identifier = 01:00:0c:29:d7:02:f2
subnet = 00:00:01:08
pool = 00:00:01:09
hardware-address = 00:0c:29:d7:02:f2
hardware-type = 00:00:00:01
ends = 43:03:3d:85
starts = 43:03:3b:2d
tstp = 43:03:3d:85
tsfp = 00:00:00:00
cltt = 00:00:00:00
 > close
 > new lease
 > set hardware-address = 00:0c:29:d7:02:f2
 > set hardware-type = 1
 > set state = 2
 > open
can't open object: more than one object matches key
obj: lease
hardware-address = 00:0c:29:d7:02:f2
hardware-type = 1
state = 2
 >

Is this expected behaviour? Can anyone come up with a fix or workaround? 
Would a copy of my configuration or leases file help?

I've dug through the dhcpctl/omshell code, only to find of course 
another layer of abstraction (beneath omapi_protocol_send_message()). 
Unfortunately I don't currently have the time to get to grips with the 
next layer down (the inner workings of omapi(3)).

Any help would be greatly appreciated.

Kind regards,
Robin