Report information
The Basics
Id:
45165
Status:
open
Priority:
Medium/Medium
Queue:
dhcp-public
People
Owner:
Nobody in particular
Requestors:
Glen Mui <glen.mui@genband.com>
Cc:
AdminCc:
BugTracker
Version Fixed:
(no value)
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
(no value)
Priority:
(no value)
Severity:
(no value)
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
(no value)
Area:
bug
Dates
Created:Mon, 01 May 2017 11:29:09 -0400
Updated:Wed, 02 Aug 2017 13:07:40 -0400
Closed:Not set

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.

History
  Mon, 01 May 2017 11:29:09 -0400 Glen Mui <glen.mui@genband.com> - Ticket created
Subject: DHCPD 4.3.5 - Unable to include all DHCP/BOOTP options in payload
Date: Mon, 1 May 2017 15:29:04 +0000
To: dhcp-bugs@isc.org
From: "Glen Mui" <glen.mui@genband.com>

Bug Report from www.isc.org: Name: Glen Mui Email: glen.mui@genband.com Software Version: DHCPD 4.3.5 OS: Linux 2.6.27 Subject:Unable to include all DHCP/BOOTP options in payload Bug Detail =========== I am migrating a Solaris server running bootp to a Linux server running ISC dhcpd to support older bootp clients. After the migration it seems that we cannot see all the options being returned to the bootp client that they originally had when interacting with the Solaris bootp server. The dhcpd.conf file has the following content that includes several vendor specific options: # cat /etc/dhcpd.conf allow booting; allow bootp; always-reply-rfc1048 on; default-lease-time 100; max-lease-time 7100; option T129 code 129 = string; option T130 code 130 = string; option T160 code 160 = string; option T161 code 161 = string; option T162 code 162 = string; subnet 169.254.8.0 netmask 255.255.252.0 { } host 47.168.102.34.db { hardware ethernet 08:00:27:70:e5:04; fixed-address 169.254.8.82; filename "./cicm/pxelinux.0"; server-name "169.254.8.100"; next-server 169.254.8.100; option subnet-mask 255.255.252.0; option routers 47.168.102.33; option ntp-servers 169.254.8.101,169.254.8.102; option T129 43:43:30:31:38:41:00; option T130 2F:A8:66:24:2F:A8:66:25; option T160 43:31:32:31:30:30:00; option T161 00; option T162 2F:A8:2D:88; } The tcpdump on the linux server of the bootp reply shows that the ntp-server option is not included in the payload but instead there are 10 bytes of padding following the end option: 21:24:10.459442 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 169.254.8.100.bootps > 169.254.8.82.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xa2755420, Flags [ none ] (0x0000) Your-IP 169.254.8.82 Server-IP 169.254.8.100 Client-Ethernet-Address 08:00:27:70:e5:04 sname "169.254.8.100" file "./cicm/pxelinux.0" Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.252.0 Default-Gateway Option 3, length 4: 47.168.102.33 T160 Option 160, length 7: 67.49.50.49.48.48.0 T129 Option 129, length 7: 67.67.48.49.56.65.0 T161 Option 161, length 1: 0 T130 Option 130, length 8: 799565348,799565349 T162 Option 162, length 4: 799550856 0x0000: 4510 0148 0000 0000 8011 d4e2 a9fe 0864 E..H...........d 0x0010: a9fe 0852 0043 0044 0134 cd50 0201 0600 ...R.C.D.4.P.... 0x0020: a275 5420 0000 0000 0000 0000 a9fe 0852 .uT............R 0x0030: a9fe 0864 0000 0000 0800 2770 e504 0000 ...d......'p.... 0x0040: 0000 0000 0000 0000 3136 392e 3235 342e ........169.254. 0x0050: 382e 3130 3000 0000 0000 0000 0000 0000 8.100........... 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 2e2f 6369 636d 2f70 ........./cicm/p 0x0090: 7865 6c69 6e75 782e 3000 0000 0000 0000 xelinux.0....... 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 0104 ffff ........c.Sc.... 0x0110: fc00 0304 2fa8 6621 a007 4331 3231 3030 ..../.f!..C12100 0x0120: 0081 0743 4330 3138 4100 a101 0082 082f ...CC018A....../ 0x0130: a866 242f a866 25a2 042f a82d 88ff 0000 .f$/.f%../.-.... 0x0140: 0000 0000 0000 0000 ........ The ntp-server contains two IP addresses and is 8 bytes in length and thus should have fit in the bootp reply in the space occupied by the padding yet it was left off. If we were to specify only one IP address in the ntp-servers option then the option appears in the bootp reply with 4 bytes of padding: 21:27:58.876523 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 169.254.8.100.bootps > 169.254.8.82.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xce0c607c, Flags [ none ] (0x0000) Your-IP 169.254.8.82 Server-IP 169.254.8.100 Client-Ethernet-Address 08:00:27:70:e5:04 sname "169.254.8.100" file "./cicm/pxelinux.0" Vendor-rfc1048 Extensions Magic Cookie 0x63825363 Subnet-Mask Option 1, length 4: 255.255.252.0 Default-Gateway Option 3, length 4: 47.168.102.33 T160 Option 160, length 7: 67.49.50.49.48.48.0 T129 Option 129, length 7: 67.67.48.49.56.65.0 T161 Option 161, length 1: 0 T130 Option 130, length 8: 799565348,799565349 T162 Option 162, length 4: 799550856 NTP Option 42, length 4: 169.254.8.101 0x0000: 4510 0148 0000 0000 8011 d4e2 a9fe 0864 E..H...........d 0x0010: a9fe 0852 0043 0044 0134 2d81 0201 0600 ...R.C.D.4-..... 0x0020: ce0c 607c 0000 0000 0000 0000 a9fe 0852 ..`|...........R 0x0030: a9fe 0864 0000 0000 0800 2770 e504 0000 ...d......'p.... 0x0040: 0000 0000 0000 0000 3136 392e 3235 342e ........169.254. 0x0050: 382e 3130 3000 0000 0000 0000 0000 0000 8.100........... 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0080: 0000 0000 0000 0000 2e2f 6369 636d 2f70 ........./cicm/p 0x0090: 7865 6c69 6e75 782e 3000 0000 0000 0000 xelinux.0....... 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0100: 0000 0000 0000 0000 6382 5363 0104 ffff ........c.Sc.... 0x0110: fc00 0304 2fa8 6621 a007 4331 3231 3030 ..../.f!..C12100 0x0120: 0081 0743 4330 3138 4100 a101 0082 082f ...CC018A....../ 0x0130: a866 242f a866 25a2 042f a82d 882a 04a9 .f$/.f%../.-.*.. 0x0140: fe08 65ff 0000 0000 ..e..... It would seem to me that the available space in the options buffer is not being calculated properly. Perhaps there is space being reserved for the overload option that is supported for dhcp clients but may not be for bootp clients. Please advise. Thanks Glen --- This email was received through isc.org Bug Submission Form
  Fri, 30 Jun 2017 09:44:43 -0400 Glen Mui <glen.mui@genband.com> - Correspondence added
Subject: RE: [ISC-Bugs #45165] AutoReply: DHCPD 4.3.5 - Unable to include all DHCP/BOOTP options in payload
To: "dhcp-bugs@isc.org" <dhcp-bugs@isc.org>
Date: Fri, 30 Jun 2017 13:44:32 +0000
From: "Glen Mui" <glen.mui@genband.com>


Hi ISC!

 

I was wondering if there was any feedback for this issue that I reported.

 

Thanks

 

Glen

 

From: DHCP Bugs via RT [mailto:dhcp-bugs@isc.org]
Sent: Monday, May 1, 2017 11:29 AM
To: Glen Mui <glen.mui@genband.com>
Subject: [ISC-Bugs #45165] AutoReply: DHCPD 4.3.5 - Unable to include all DHCP/BOOTP options in payload

 

NOTICE: This email was received from an EXTERNAL sender



Greetings,

This message has been automatically generated in response to the
creation of a trouble ticket regarding:
"DHCPD 4.3.5 - Unable to include all DHCP/BOOTP options in payload",
a summary of which appears below.

There is no need to reply to this message right now. Your ticket has been
assigned an ID of [ISC-Bugs #45165].

Please include the string:

[ISC-Bugs #45165]

in the subject line of all future correspondence about this issue. To do so,
you may reply to this message.

Thank you,
dhcp-bugs@isc.org

-------------------------------------------------------------------------
Bug Report from www.isc.org:

Name: Glen Mui
Email: glen.mui@genband.com
Software Version: DHCPD 4.3.5
OS: Linux 2.6.27
Subject:Unable to include all DHCP/BOOTP options in payload


Bug Detail
===========
I am migrating a Solaris server running bootp to a Linux server running ISC dhcpd to support older bootp clients. After the migration it seems that we cannot see all the options being returned to the bootp client that they originally had when interacting with the Solaris bootp server. The dhcpd.conf file has the following content that includes several vendor specific options:

# cat /etc/dhcpd.conf
allow booting;
allow bootp;
always-reply-rfc1048 on;
default-lease-time 100;
max-lease-time 7100;
option T129 code 129 = string;
option T130 code 130 = string;
option T160 code 160 = string;
option T161 code 161 = string;
option T162 code 162 = string;

subnet 169.254.8.0 netmask 255.255.252.0 {
}

host 47.168.102.34.db {
hardware ethernet 08:00:27:70:e5:04;
fixed-address 169.254.8.82;
filename "./cicm/pxelinux.0";
server-name "169.254.8.100";
next-server 169.254.8.100;
option subnet-mask 255.255.252.0;
option routers 47.168.102.33;
option ntp-servers 169.254.8.101,169.254.8.102;
option T129 43:43:30:31:38:41:00;
option T130 2F:A8:66:24:2F:A8:66:25;
option T160 43:31:32:31:30:30:00;
option T161 00;
option T162 2F:A8:2D:88;

}

The tcpdump on the linux server of the bootp reply shows that the ntp-server option is not included in the payload but instead there are 10 bytes of padding following the end option:

21:24:10.459442 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 169.254.8.100.bootps > 169.254.8.82.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xa2755420, Flags [ none ] (0x0000)
Your-IP 169.254.8.82
Server-IP 169.254.8.100
Client-Ethernet-Address 08:00:27:70:e5:04
sname "169.254.8.100"
file "./cicm/pxelinux.0"
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
Subnet-Mask Option 1, length 4: 255.255.252.0
Default-Gateway Option 3, length 4: 47.168.102.33
T160 Option 160, length 7: 67.49.50.49.48.48.0
T129 Option 129, length 7: 67.67.48.49.56.65.0
T161 Option 161, length 1: 0
T130 Option 130, length 8: 799565348,799565349
T162 Option 162, length 4: 799550856
0x0000: 4510 0148 0000 0000 8011 d4e2 a9fe 0864 E..H...........d
0x0010: a9fe 0852 0043 0044 0134 cd50 0201 0600 ...R.C.D.4.P....
0x0020: a275 5420 0000 0000 0000 0000 a9fe 0852 .uT............R
0x0030: a9fe 0864 0000 0000 0800 2770 e504 0000 ...d......'p....
0x0040: 0000 0000 0000 0000 3136 392e 3235 342e ........169.254.
0x0050: 382e 3130 3000 0000 0000 0000 0000 0000 8.100...........
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 2e2f 6369 636d 2f70 ........./cicm/p
0x0090: 7865 6c69 6e75 782e 3000 0000 0000 0000 xelinux.0.......
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 6382 5363 0104 ffff ........c.Sc....
0x0110: fc00 0304 2fa8 6621 a007 4331 3231 3030 ..../.f!..C12100
0x0120: 0081 0743 4330 3138 4100 a101 0082 082f ...CC018A....../
0x0130: a866 242f a866 25a2 042f a82d 88ff 0000 .f$/.f%../.-....
0x0140: 0000 0000 0000 0000 ........

The ntp-server contains two IP addresses and is 8 bytes in length and thus should have fit in the bootp reply in the space occupied by the padding yet it was left off. If we were to specify only one IP address in the ntp-servers option then the option appears in the bootp reply with 4 bytes of padding:

21:27:58.876523 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 169.254.8.100.bootps > 169.254.8.82.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xce0c607c, Flags [ none ] (0x0000)
Your-IP 169.254.8.82
Server-IP 169.254.8.100
Client-Ethernet-Address 08:00:27:70:e5:04
sname "169.254.8.100"
file "./cicm/pxelinux.0"
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
Subnet-Mask Option 1, length 4: 255.255.252.0
Default-Gateway Option 3, length 4: 47.168.102.33
T160 Option 160, length 7: 67.49.50.49.48.48.0
T129 Option 129, length 7: 67.67.48.49.56.65.0
T161 Option 161, length 1: 0
T130 Option 130, length 8: 799565348,799565349
T162 Option 162, length 4: 799550856
NTP Option 42, length 4: 169.254.8.101
0x0000: 4510 0148 0000 0000 8011 d4e2 a9fe 0864 E..H...........d
0x0010: a9fe 0852 0043 0044 0134 2d81 0201 0600 ...R.C.D.4-.....
0x0020: ce0c 607c 0000 0000 0000 0000 a9fe 0852 ..`|...........R
0x0030: a9fe 0864 0000 0000 0800 2770 e504 0000 ...d......'p....
0x0040: 0000 0000 0000 0000 3136 392e 3235 342e ........169.254.
0x0050: 382e 3130 3000 0000 0000 0000 0000 0000 8.100...........
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 2e2f 6369 636d 2f70 ........./cicm/p
0x0090: 7865 6c69 6e75 782e 3000 0000 0000 0000 xelinux.0.......
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0100: 0000 0000 0000 0000 6382 5363 0104 ffff ........c.Sc....
0x0110: fc00 0304 2fa8 6621 a007 4331 3231 3030 ..../.f!..C12100
0x0120: 0081 0743 4330 3138 4100 a101 0082 082f ...CC018A....../
0x0130: a866 242f a866 25a2 042f a82d 882a 04a9 .f$/.f%../.-.*..
0x0140: fe08 65ff 0000 0000 ..e.....

It would seem to me that the available space in the options buffer is not being calculated properly. Perhaps there is space being reserved for the overload option that is supported for dhcp clients but may not be for bootp clients.

Please advise.

Thanks

Glen

---
This email was received through isc.org Bug Submission Form

Fri, 30 Jun 2017 09:44:44 -0400 The RT System itself - Status changed from 'new' to 'open'
  Fri, 30 Jun 2017 10:19:16 -0400 Thomas Markwalder <tmark@isc.org> - Correspondence added

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
  Wed, 02 Aug 2017 10:27:30 -0400 Glen Mui <glen.mui@genband.com> - Correspondence added
Date: Wed, 2 Aug 2017 14:27:17 +0000
To: "dhcp-confidential@isc.org" <dhcp-confidential@isc.org>
From: "Glen Mui" <glen.mui@genband.com>
Subject: RE: [ISC-Bugs #45165] DHCPD 4.3.5 - Unable to include all DHCP/BOOTP options in payload


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

Wed, 02 Aug 2017 13:07:40 -0400 Vicky Risk <vicky@isc.org> - Queue changed from #8 to dhcp-public
Wed, 02 Aug 2017 13:07:40 -0400 Vicky Risk <vicky@isc.org> - Area bug added