Version
=======
4.3.1

Description
===========
When the DHCP server receives DHCP "release" message from its client, it should clear the leased IP address from its pool, but it does not.

Topology
========
  +––––––––––+                 +–––––––––––+                 +–––––––––––+
  |          |                 |           |                 |           |
  | DHCP     +–––––––––––––––––+ DHCP      |–––––––––––––––––+    DHCP   |
  | SERVER   |                 | RELAY     |                 |    CLIENT |
  |          |                 |           |                 |           |
  +––––––––––+                 +–––––––––––+                 +–––––––––––+

Steps to Reproduce
==================
1. Configure DHCP Server to provision IPv4 address.
2. Configure DHCP Relay to relay DHCP messages from DHCP clients to DHCP server.
3. Configure DHCP client to acquire IP address from DHCP Server.
4. Verify that DHCP server is able to provision IP addresses to DHCP client.
5. From DHCP client, release IP address.
6. Verify that DHCP server receives the DHCP release message and clear the
    leased IP address from its DHCP pool.

Analysis
========
The issue is that the server is not happy with the format of the RELEASE
message:

2014-12-11T10:54:04.716201+00:00 server dhcpd: Listening on Socket/dp0s7
2014-12-11T10:54:04.716204+00:00 server dhcpd: Sending on   Socket/dp0s7
2014-12-11T10:54:04.716206+00:00 server dhcpd: Server starting service.
2014-12-11T10:54:43.576756+00:00 server dhcpd: DHCPDISCOVER from 52:54:00:98:6f:cd (VMgillott) via 11.1.1.22
2014-12-11T10:54:44.577913+00:00 server dhcpd: DHCPOFFER on 11.1.1.23 to 52:54:00:98:6f:cd (VMgillott) via 11.1.1.22
2014-12-11T10:54:44.579984+00:00 server dhcpd: DHCPREQUEST for 11.1.1.23 (10.1.1.1) from 52:54:00:98:6f:cd (VMgillott) via 11.1.1.22
2014-12-11T10:54:44.579995+00:00 server dhcpd: DHCPACK on 11.1.1.23 to 52:54:00:98:6f:cd via 11.1.1.22
2014-12-11T10:54:54.184752+00:00 server dhcpd: DHCPREQUEST for 11.1.1.21 from 52:54:00:98:6f:cd via dp0s7: ignored (not authoritative).
2014-12-11T10:55:25.827079+00:00  dhcpd: last message repeated 2 times
2014-12-11T10:56:27.332880+00:00  dhcpd: last message repeated 5 times
2014-12-11T10:56:27.595325+00:00 server dhcpd: DHCPRELEASE from 52:54:00:98:6f:cd via dp0s7: unknown network segment

Solution
========
The solution is to realise that DHCPRELEASE packets are unicast from client to
server - no relay agent involvement.
Thus there is no point in the server checking the subnet
(no agent options & giaddr is zero).
Essentially ignore the result of the call to locate_network():

2014-12-16T13:45:52.222230+00:00 server dhcpd: DHCPDISCOVER from 52:54:00:dd:d0:91 via 11.1.1.2
2014-12-16T13:45:53.223320+00:00 server dhcpd: DHCPOFFER on 11.1.1.25 to 52:54:00:dd:d0:91 (VRHost) via 11.1.1.2
2014-12-16T13:45:53.231773+00:00 server dhcpd: DHCPREQUEST for 11.1.1.25 (10.1.1.1) from 52:54:00:dd:d0:91 (VRHost) via 11.1.1.2
2014-12-16T13:45:53.231795+00:00 server dhcpd: DHCPACK on 11.1.1.25 to 52:54:00:dd:d0:91 (VRHost) via 11.1.1.2
2014-12-16T13:46:57.468725+00:00 server dhcpd: DHCPRELEASE of 11.1.1.25 from 52:54:00:dd:d0:91 (VRHost) via dp0s7 (found)

Patch
=====
Description: Ignore network check when processing DHCPRELEASE
   Since DHCPRELEASE messages are unicast direct from client to server none of
   fields used to verify the subnet are valid - no agent options & giaddr is
   zero - so don't bother.
Author: Mark Gillott <mgillott@brocade.com>
Origin: <upstream|backport|vendor|other>, <URL, required except if Author is present>
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/server/dhcp.c
+++ b/server/dhcp.c
@@ -85,6 +85,7 @@ dhcp (struct packet *packet) {
  	if (!locate_network(packet) &&
  	    packet->packet_type != DHCPREQUEST &&
  	    packet->packet_type != DHCPINFORM &&
+	    packet->packet_type != DHCPRELEASE &&
  	    packet->packet_type != DHCPLEASEQUERY) {
  		const char *s;
  		char typebuf[32];