Bug 175411 - dhcpd fails to send Vendor Info in OFFER message, although it is provided in ACK message.
dhcpd fails to send Vendor Info in OFFER message, although it is provided in ...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: dhcp (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-09 16:41 EST by Terry Yoder
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-13 11:37:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Terry Yoder 2005-12-09 16:41:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
Client DISCOVER message contains Option 60, Vendor ID
Server OFFER message fails to contain Option 43, Vendor Info
Client REQUEST message contains Option 60, Vendor ID
Server ACK message does contain Option 43, Vendor Info.

Bug is that Server's OFFER should contain Option 43 Vendor Info

Version-Release number of selected component (if applicable):
3.0pl1

How reproducible:
Always

Steps to Reproduce:
1. Set up DHCP Server to provide Vendor Info
2. Set up DHCP Client to provide Vendor ID
3. Boot Client
  

Actual Results:  Client boots, gets DHCP address.  Server's DHCP OFFER fails to contain Vendor Info.

Expected Results:  Server's DHCP OFFER should contain Vendor Info (Option 43)

Additional info:
Comment 1 Jason Vas Dias 2005-12-09 17:05:38 EST
Firstly, you are running an ancient version of dhcp - I'd recommend updating
at least to the dhcp-3.0.1-10_EL3 of RHEL-3 Update 4 or to dhcp-3.0.1-44_EL3,
the latest RHEL-3 update candidate, available from :
    http://people.redhat.com/~jvdias/dhcp

Secondly, I'd really need to see your server dhcpd.conf and client dhclient.conf
files to determine what may be the cause of the problem here. If you'd like to
keep them confidential, then please gzip them and send them to me:
jvdias@redhat.com.

In order to obtain the vendor info, the vendor encapsulated options must be 
declared in both the server dhcpd.conf and the client dhclient.conf; then the
client must request them, ie. the vendor encapsulation has to be in the dhclient
.conf 'request' line, along with the default options, otherwise the client 
will not request the vendor info and the server will not send it. Sending me
your config files would enable me to advise further - thank you .
Comment 2 Terry Yoder 2005-12-09 18:34:50 EST
Jason,

Regardless of what ancient version of dhcpd I have, my bugzilla
search revealed that this bug was never logged or fixed.  I did
try updating but rpm reported a problem doing this.

I can send you my dhcpd.conf file, but I would want to keep it
confidential. However, I think you can recreate this yourself.
Are you experience setting up Vendor ID's in dhcpd.conf?  If
you aren't and you need mine for reference, let me know.
If you are experienced, or if you happen to have an environment
where a client provides a Vendor ID and the server provides
Vendor Data, then you can validate the bug easily by looking
at a network trace of the DISCOVER, OFFER, REQUEST, ACK
sequence.

I will not be able to help you set up a client to recreate this. 
The client is my application written for a product. It sends
the vendor ID.  This works correctly with Microsoft's DHCP
Server.  It works close to correctly with Linux DHCP Server,
with the bug exception that Linux Server does not send the
Vendor Info in its OFFER message.  It only sends it in the
ACK.  
Comment 3 Jason Vas Dias 2005-12-09 19:38:14 EST
Yes, I have set up dhcp-3.0.1 - dhcp-3.0.3 dhcpd servers and dhclient clients
to serve and obtain vendor encapsulated options .

The bug may never have been logged because, AFAIK, no bugs have been found with
sending / receiving vendor options with ISC DHCP .

It is not enough for a client to just "send the vendor ID" - it also has to
request the vendor encapsulation and vendor options, otherwise the server will
not send them.

The current dhcp server for RHEL-3 is dhcp-3.0.1-44_EL3 - dhcp-3.0plx is no
longer supported by RHEL-3, and I've only tested with a 3.0.1+ server and client.

Please can you send me the dhcpd.conf file you use on the dhcp-3.0.1+ server,
and the output of this tcpdump command run on the server while the problem is 
reproduced with your client application :

# tcpdump -nl -i any -vvv -s 4096 port bootps or port bootpc >/tmp/tcpdump.log \
       2>&1 

And compress and send me the /tmp/tcpdump.log and /etc/dhcpd.conf files -
I guarantee to keep them confidential - thank you .
Comment 4 Terry Yoder 2005-12-09 20:25:01 EST
I installed the 3.0.3 version to the same effect.

I will provide my dhcpd.conf and an Ethereal trace.

The vendor data is formed in NVT format, so I do 
indeed ask for one of the vendor options in the 
Parameter Request List, although not all.

However, I'm not sure how the client should request 
vendor encapsuluation.  

Just curious, have you seen a network trace of
the client/server request sequence that shows Vendor
Data provided in the OFFER? If so, I'd be interested
in seeing the dhcpd.conf file and a network trace.
That would help me understand how to set my system
up correctly.
Comment 5 Jason Vas Dias 2005-12-13 11:37:29 EST
The trace file requested were received - thank you!

To preserve confidentiality, I've replied in detail to you by mail, showing
" a network trace of the client/server request sequence that shows Vendor
  Data provided in the OFFER ".

This issue does not appear to be a bug with the RHEL-3 dhcpd server, which
is certainly able to send vendor encapsulated options in the OFFER - 
closing as NOTABUG. 

If you disagree, please re-open this bug. 

Note You need to log in before you can comment on or make changes to this bug.