From www@isc.org Mon Feb 23 21:15:47 2015 CC: marketing@isc.org MIME-Version: 1.0 X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG, MIME_HTML_ONLY,RCVD_IN_DNSWL_NONE,TO_NO_BRKTS_HTML_ONLY,T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 X-Mailer: PHPMailer 5.2.7 (https://github.com/PHPMailer/PHPMailer/) content-type: text/html; charset="utf-8" Message-ID: <0aa9988c20dae8d9300b3900623014d6@www.isc.org> Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by bugs.isc.org (Postfix) with ESMTP id 3EF8271B6F0 for ; Mon, 23 Feb 2015 21:15:47 +0000 (UTC) Received: from iscwebprod.isc.org (iscwebprod.isc.org [IPv6:2001:4f8:1:d::16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 5706F349315 for ; Mon, 23 Feb 2015 21:15:45 +0000 (UTC) Received: from www (uid 80) (envelope-from www@iscwebprod.isc.org) id 7b7d18 by iscwebprod.isc.org (DragonFly Mail Agent v0.9); Mon, 23 Feb 2015 21:15:44 +0000 Delivered-To: dhcp-bugs@bugs.isc.org Subject: dhcp-4.2.5-27.0.1.el7_0.2 - dhcrelay drops responses inappropriately Return-Path: X-Original-To: dhcp-bugs@bugs.isc.org X-Priority: 3 Date: Mon, 23 Feb 2015 21:15:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org X-PHP-Originating-Script: 20001:class-phpmailer.php To: dhcp-bugs@isc.org Content-Transfer-Encoding: 8bit From: "Michael Glasgow" X-RT-Original-Encoding: utf-8 X-RT-Interface: Email Content-Length: 1973

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.