On 10/02/2013 06:11 AM, Nehal J Wani wrote:
On Wed, Oct 2, 2013 at 3:18 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
On Wed, Oct 02, 2013 at 03:08:00PM +0530, Nehal J Wani wrote:
On Wed, Oct 2, 2013 at 1:43 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
On Tue, Oct 01, 2013 at 05:39:02PM -0600, Eric Blake wrote:
On 09/26/2013 02:08 AM, Nehal J Wani wrote:
Introduce 3 new APIs, virNetworkGetDHCPLeases, virNetworkGetDHCPLeasesForMAC and virNetworkDHCPLeaseFree.
* virNetworkGetDHCPLeases: returns the dhcp leases information for a given virtual network.
For DHCPv4, the information includes: - Expirytime - MAC Address - IPv4 address (with type and prefix) - Hostname (can be NULL) - Client ID (can be NULL)
For DHCPv6, the information includes - Expirytime - IAID - IPv6 address (with type and prefix) - Hostname (can be NULL) - Client DUID
* virNetworkGetDHCPLeasesForMAC: returns the dhcp leases information for a given virtual network and specified MAC Address.
* virNetworkDHCPLeaseFree: allows the upper layer application to free the network interface object conveniently.
There is no support for flags, so user is expected to pass 0 for both the APIs.
+typedef struct _virNetworkDHCPLeases virNetworkDHCPLeases; +typedef virNetworkDHCPLeases *virNetworkDHCPLeasesPtr; +struct _virNetworkDHCPLeases { + long long expirytime; /* Seconds since epoch */ + union { + char *mac; /* MAC address */ + unsigned long iaid; /* Identity association identifier (IAID) */ + } id; I'm not sure I like iaid - the whole point of this interface was to return IP addresses associated with a MAC. Either the iaid is important and deserves a separate field, or all we care about is the MAC address. Not to mention that you didn't document which leg of the id union is valid based on the type discriminator. Agreed, we want the MAC address to be unconditionally available here. IMHO the IAID is not something we care about exposing. That is a impl detail of the DHCP comms protocol that is not useful to people outside.
So in case DHCPv6 is used by the client, should we report the rest of the lease fields and report MAC as NULL? No, we must report the MAC. This data is useless without the MAC address being present.
You can't even implement the virNetworkGetDHCPLeasesForMAC API without knowing the MAC for a lease. The issue is, in case of leases containing ipv6 addresses, there is no field for MAC address. Laine suggested extracting MAC address from the cliend DUID. For example:
1380692760 52:54:00:e7:85:1e 192.168.122.116 * * duid 00:01:00:01:19:dd:fb:37:f0:4d:a2:8c:14:51 1380692762 15172894 2001:db8:ca2:2:1::de * 00:01:00:01:19:dd:fb:af:52:54:00:e7:85:1e
The last 17 chars of the client DUID represent the MAC address [00:01:00:01:19:dd:fb:af:((52:54:00:e7:85:1e))]. But RFC3315 strictly suggests: """ Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. Clients and servers MUST NOT in any other way interpret DUIDs. Clients and servers MUST NOT restrict DUIDs to the types defined in this document, as additional DUID types may be defined in the future.
You aren't a client or a server (i.e. you aren't participating in the protocol). You are a third party who is already invading the internal state data store of one particular implementation of DHCP server - dnsmasq (and only dnsmasq) - to try and mine some useful information. It is a happy coincidence that the MAC address is contained in the DUID in dnsmasq, but it *is* there, and doesn't appear to be available anywhere else (without snooping packets on the bridge for a matching IP address). So your choices are use that, snoop the packets, or go home. (You should not, however, attempt to write a general purpose function intended to derive the MAC address from the DUID of a lease for *any* DHCP implementation - *that* is what the RFC says you must not do) BTW, I agree with Dan that all we care about are IP address and MAC address - IAID and DUID are just artifacts of the method used to assign an IP address, and won't mean anything to anybody except the DHCP server and client software.