On 13/01/15 16:16, George Wilkie wrote:
> 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.
Nope that pretty much covers thing. The key is that the DHCPRELEASE is 
unicast directly from client to server - routed via the relay box (but 
NOT seen by DHCP relay itself). Thus the DHCP server sees a release 
message from a "different" subnet (see the check inside 
locate_network()) yet the message has not been "tagged" as coming via a 
DHCP relay. Thus resulting in "unknown network segment" messages.

Hopefully that makes some sense,

Mark