MIME-Version: 1.0 In-Reply-To: <54AE8011.3080806@brocade.com> X-Mailer: MIME-tools 5.428 (Entity 5.428) Content-Disposition: inline References: <54AE8011.3080806@brocade.com> Content-Type: text/html; charset="UTF-8" Message-ID: Content-Transfer-Encoding: binary X-RT-Original-Encoding: utf-8 RT-Send-CC: Content-Length: 6288 On Thu Jan 08 13:03:24 2015, gwilkie@brocade.com wrote:
> 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];
>
>

Hi George,

Thanks for your report.

Is it possible that the client in your example is dual-homed and is routing the DHCPRELEASE via a default route which isn't the one from the interface on which the lease was granted?

Kind regards,

Cathy Almond
ISC Support?