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-28559-1435950103-1264.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: 2087

> * 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

Hi Michael,

Thanks for this report,

We had conjectured that your problem might already have been addressed in recent changes going through, but we now suspect that it has not.

I'm passing on a question from our engineers therefore - is this a significant functionality problem, or is it just causing unwanted log messages, but in the end, the client is being given an appropriate lease?

Kind regards,

Cathy Almond
ISC Support