Hi,
RFC 2132 chapter 8.4 gives you an answer
If a vendor potentially encodes more than one item of information in
this option, then the vendor SHOULD encode the option using
"Encapsulated vendor-specific options" as described below:
The Encapsulated vendor-specific options field SHOULD be encoded as a
sequence of code/length/value fields of identical syntax to the DHCP
options field with the following exceptions:
Thus suboptions should be encoded with identical syntax to the DHCP
options. So in theory you could reenter bootp_option() again. But then
again that is not fool proof. Vendor specific implementations for Alcatel
AVA, PXE and CableLabs are already in place and that won't be the end of
it. Maybe you can handle it by means of a preference: "Interpret vendor
specific options conforming to RFC 2132".
Thanx,
Jaap
On Fri, 5 Jan 2007, Pichlmaier, Martin wrote:
> Hi all,
>
> I am trying to give a better view for the vendor-specific option in the
> bootp/dhcp options.
> The attached patch creates subtrees for all vendor-spefific suboptions.
>
> But there is one issue left I do not know how to solve:
> I give out the values as string, number (if 1, 2 or 4 bytes) and as an
> IP (if 4 bytes)
> because I do not know what is actually the real interpretation.
> Every vendor may use that option and the vaules are different types for
> the same subcodes.
>
> Does anyone have a good idea how I could decide what view to use (how I
> should present
> the data for each suboption)?
>
> Thank you,
> Martin
>
