MIME-Version: 1.0
In-Reply-To: <0aa9988c20dae8d9300b3900623014d6@www.isc.org>
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Disposition: inline
X-RT-Interface: Web
References: <0aa9988c20dae8d9300b3900623014d6@www.isc.org>
 <RT-Ticket-38699@isc.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.2.8-64694-1440693558-195.38699-0-0@isc.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
RT-Send-CC:
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 2512

On Mon Feb 23 21:15:48 2015, glasgow@beer.net wrote:
> Bug Report from www.isc.org:
> 
> * Name: Michael Glasgow
> 
> * Email: glasgow@beer.net
> 
> * Software Version: dhcp-4.2.5-27.0.1.el7_0.2
> 
> * OS: Oracle Linux 7
> 
> * Subject:dhcrelay drops responses inappropriately
> 
> Bug Detail
> 
> Bitten by this bug today:
> 
> https://lists.isc.org/pipermail/dhcp-users/2014-April/017829.html
> 
> Quoting the main part:
> 
> dhcrelay creates link-level AF_PACKET socket and bind()s it to the
> interface
> facing clients. This socket has a read event handler got_one() that
> further
> calls do_relay4() that does the actual relaying logic. Another socket
> that
> dhcrelay creates is AF_INET. This socket is used ONLY to send DHCP
> requests to
> the DHCP server, but it is NOT USED to read any packets from the DHCP
> server.
> This is because AF_INET socket is using fallback_discard() handler
> whenever a
> packets arrives. This callback, you guessed it right,
> simply drops all the packets that server sent.
> 
> The upshot is that there is presently no way to prevent dhcrelay from
> serving
> client requests on the subnet where it will receive replies from the
> DHCP
> server, e.g.:
> 
> dhcpd <- s1 -> dhcrelay <-s2-> dhclient
> 
> where "s1" and "s2" are distinct subnets, and I need dhcrelay to
> service
> clients on "s2" but not on "s1" (because dhcpd is already listening
> there).
> 
> Excluding dhcrelay's interface on "s1" using -i <s2> results in the
> aforementioned behavior, breaking clients on "s2". This would seem to
> be a
> relatively common configuration for a router running a dhcp relay, so
> it seems
> like it should be supported.
> 
> ---
> 
> This email was received through isc.org Bug Submission Form
> 
> All information within this email is considered confidential and for
> internal
> use only.

Hi Michael,

Thanks for this report,

This behaviour is something that has been around in ISC DHCP for a very long time - and we agree that it can result in duplicate requests being received by the DHCP servers, but at the same time, it should not be causing any problems.

As this has been the way that ISC DHCP has operated for a long time, we're a little reluctant to try to change it now - but before we make that decision, we'd first like to check back with you whether or not this is causing you a significant operational issue, beyond the inevitable logging of the duplicated requests on the same subnet as the DHCP server?

Kind regards,

Cathy Almond
ISC Support