Report information
The Basics
Id:
37426
Status:
resolved
Worked:
13.83 hours (830 minutes)
Users:
tmark: 12 hours (720 minutes)
sar: 1.83 hours (110 minutes)
Priority:
Medium/Medium
Queue:

BugTracker
Version Fixed:
4.3.2
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
4.3.2 4.2.8 4.1-ESV-R11
Priority:
(no value)
Severity:
S2 Normal
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
(no value)
Area:
(no value)

Attachments
0001-dhcrelay-fix-setting-of-UPSTREAM-DOWNSTREAM-flags-of.patch 0001-Work-around-for-hop-limit-set-to-1.patch

Dates
Created:Thu, 09 Oct 2014 13:41:14 -0400
Updated:Fri, 07 Jul 2017 20:04:40 -0400
Closed:Mon, 19 Jan 2015 14:01:05 -0500



This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

Subject: dhcrelay -6 and Hop Limit
Date: Thu, 09 Oct 2014 19:41:09 +0200
To: dhcp-bugs@isc.org
From: Jiri Popelka <jpopelka@redhat.com>
Hi,

RFC 3315, 20. Relay Agent Behavior:
"If the relay agent relays messages to the All_DHCP_Servers multicast address or other multicast addresses, it sets the Hop Limit field to 32.
"

dhcrelay -6 however sometimes sets hop limit to 1.
This depends what is specified first on command line, whether '-l' or '-u'.

As I understand it the problem is that we use the same socket for both/all interfaces
and when we register the socket we set the hop limit only in case of 'upper' interface,
but if the first interface which registers the socket is 'lower' the hop limit is not set (i.e. set to 1).

There are 2 patches attached:
0001-Work-around-for-hop-limit-set-to-1.patch
 - work-around for the above problem, proper solution would probably be in using different socket for 'lower'/'upper' interface(s).

0001-dhcrelay-fix-setting-of-UPSTREAM-DOWNSTREAM-flags-of.patch
 - few minor improvements that came to my mind when investigating the above problem.


With regards,
Jiri Popelka
Red Hat, inc.

Message body is not shown because sender requested not to inline it.

Message body is not shown because sender requested not to inline it.

Hello Jiri: Thank your for reporting the issue and for submitting a patch. After digging a bit some additional nuances were found, so while your patch was inspirational some additional changes were needed. The submitted patch corrects the case when -l and -u are the same value but does not correct the problem of -u given before -l. The latter arises from the fact the dhcrelay's internal list of interfaces ends up in the reverse order of how they are given on the command line; combined with the v6 interface registration logic registering only the first interface. Thus when -l is last on the command line, it becomes the first one in the list of interfaces and hence is the interface that gets registered. Since the logic to set the hop limit count was being done during interface registration, it remained unset for the upper interface. Secondly, the code when it did set the hop limit count, did so irrespective of the upstream address. Per the RFC it should set it only if the upstream address is a multicast address. We moved the logic to set the hop limit count to its own function and now call that function from setup_streams() for the upstream interface only if the upstream address is a multicast address. This fix will be in 4.3.2, 4.2.4, and 4.1-ESV-R11, due to be released next month. Again, accept our thanks for your ongoing interest and contributions. Sincerely, Thomas Markwalder ISC Software Engineering