MIME-Version: 1.0
In-Reply-To: <rt-3.8.6-2416-1421160783-888.38303-5-0@isc.org>
References: <RT-Ticket-38303@isc.org> <54AE8011.3080806@brocade.com> <rt-3.8.6-2416-1421160783-888.38303-5-0@isc.org>
Message-ID: <54B544F2.8050808@brocade.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Subject: Re: [ISC-Bugs #38303] [PATCH] DHCP server receives "release" message from client but does not release IP address from pool.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0
Date: Tue, 13 Jan 2015 16:16:50 +0000
To: "dhcp-bugs@isc.org" <dhcp-bugs@isc.org>, <mgillott@brocade.com>
Content-Transfer-Encoding: 8bit
From: George Wilkie <gwilkie@brocade.com>
RT-Message-ID: <rt-3.8.6-2416-1421165818-273.38303-0-0@isc.org>
Content-Length: 4931

Hi Cathy, ...

On 01/13/2015 02:53 PM, Cathy Almond via RT wrote:
> 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?

It is just a simple setup. The client routes packets via the same box 
which does the dhcp relay.
The DHCPRELEASE is sent directly to the server, so it routed through 
without doing any of the dhcp
relay stuff. The server seems to be expecting the packet to have been 
handled by the relay.
Mark, anything else to add?

Thanks,

George.

> Kind regards,
>
> Cathy Almond
> ISC Support?
>