Hello Moe,
>>> "Moe Garcia" <mgarcia01752@xxxxxxxxx> 2008-04-19 11:08 >>>
> Hope this is an easy answer:
>
<snip>
> Option: (t=43,l=128) Vendor-Specific Information
> Option: (43) Vendor-Specific Information
> Length: 128
> Value: 01063C6E756C6C3E020445535442030845434D3A45535442...
>
> It there a switch that will allow me a more verbose to complete value
> return?
I'm sorry but I do NOT believe there is an "easy answer". How to
interpret the DCHP option 43 is by definition "Vendor-specific". ;-)
Generally speaking a DHCP client machine can (and will) advertise that
they are interested in some type of vendor-specific attribute by presenting
a "Vendor Class Attribute" TLV (Type=60) in their DHCP_DISCOVER,
DHCP_REQUEST and/or DHCP_INFORM packets.
The DHCP server, if designed and configured to do so, can respond to
the DHCP client request with the Vendor Class Identifer with a reply
containing a vendor-specific attribute. How one should parse/dissect
any vendor-specific attribute generally must be made in the context of
the initial advertised vendor-class.
The DHCP specification states that the vendor-specific attribute is an
opaque blob, but suggests that the vendor-specific information can be
organized into its own TLV structure so that multiple pieces of information
can be conveyed. But their is no requirement for the vendor to actually
use a TLV structure; the vendor is free to construct the vendor-specific
attribute in whatever way is best for their needs.
Further complicating this issue is that in my (someone limited) review of
traces containing DHCP packets with a vendor-specific attributes,
that the DHCP servers do not appear to be obligated to return the
original advertised Vendor-Class attribute within their DHCP reply.
If one only looks at a DHCP reply in isolation, then the lack of a
vendor-class attribute within the DHCP reply makes it much harder for
something like Wireshark to be able to determine how best to parse
the current vendor-specific attribute.
There is some code within Wireshark's bootp/dhcp dissector
(packet-bootp.c) that does handle a few very specific vendor-specific
attribute cases. I recently modified this same dissector to help
troubleshoot a problem we had with a specific vendor's vendor-specific
attribute. Since I was dealing with a very specific vendor issue I opted
to "hardwire" my custom bootp/dhcp dissector to always parse the
vendor-specific attributes (type=43) as if ALL vendor-attributes were
from this one specific vendor.
At that time I started looking to see if I could use something like the
Wireshark's conversation mechanism to pair DHCP requests and
replies with one another (using something like "bootp.id" field).
My thinking was that once specific bootp requests and replies are
paired with one another, it should make it much possible for Wireshark's
DHCP dissector to be able to use the vendor-class attribute seen in
the request to determine how to parse/interpret a vendor-specific
attribute seen in its reply.
Now back to YOUR specific case, it DOES appear that in your specific
vendor-specific attribute data is in a TLV format....
Value: 01063C6E756C6C3E020445535442030845434D3A45535442...
Type=01
Length=06
Value=3C6E756C6C3E
Type=02
Length=04
Value=45535442
Type=03
Length=08
Value=45434D3A45535442...
What those specific sub-Types mean is defined by the vendor. Hopefully
your vendor will make available the information necessary for you
to make sense of the values.
I hope you find this information useful.
Jim Y.
