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