X-RT-Original-Encoding: utf-8
content-type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Content-Length: 3072

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