Content-Transfer-Encoding: base64 X-RT-Original-Encoding: utf-8 content-type: text/html; charset="utf-8" Content-Length: 12180
Hi Thomas!
Thanks for your feedback. I was wondering if you can comment on the following analysis and proposed update.
In the function store_options() in “./dhcp-4.1.0p1/common/options.c” there is a condition below that decides when to add an option to the options buffer:
/* Try to fit it in the options buffer. */
if (!splitup &&
((!six && !tix &&
(i == priority_len - 1) &&
(bufix + 2 + length < bufend)) ||
(bufix + 5 + length < bufend))) {
base = buffer;
pix = &bufix;
The only time when the options buffer only reserves 2 bytes for the end option is when we have reached the end of the priority list otherwise we are reserving
5 bytes for the overload + end options. The problem is that we are creating a bootp reply which has no support for overload and we have also not reached the end of the priority list. This means we are reserving an extra 3 bytes that will never be used in
this context and may not populate options that could very well fit otherwise. I would like your opinion the following suggested change to the above code:
/* Try to fit it in the options buffer. */
if (!splitup &&
((!six && !tix &&
((i == priority_len - 1) || (!first_cutoff && !second_cutoff)) &&
(bufix + 2 + length < bufend)) ||
(bufix + 5 + length < bufend))) {
base = buffer;
pix = &bufix;
The cons_options() function is passed “0” for the overload_avail when called in ./dhcp-4.1.0p1/server/bootp.c. This results in the first_cutoff and second_cutoff
to be “0” when passed to store_options(). By adding these variables to the condition above we can avoid reserving the extra 3 bytes for the overload when there is no possibility that it will be used.
Please let me know your opinion.
Thanks
Glen
From: Thomas Markwalder via RT [mailto:dhcp-confidential@isc.org]
Sent: Friday, June 30, 2017 10:19 AM
To: Glen Mui <glen.mui@genband.com>
Subject: [ISC-Bugs #45165] DHCPD 4.3.5 - Unable to include all DHCP/BOOTP options in payload
NOTICE: This email was received from an EXTERNAL sender
Hello Glen:
We are currently in the middle of preparing our next maintenance releases 4.3.6 and 4.1-ESV-R15 for beta release, currently scheduled for 7/14 with final release on 7/31.
As time permits we will investigate your issue and update you with our findings. We're a small non-profit with finite resources and work on what we can as we can. We do offer support contracts if your needs are more pressing:
https://www.isc.org/support/
We appreciate your interest and thank you for reporting the issue to us and for your continued patience until we can address it.
Regards,
Thomas Markwalder
ISC Software Engineering