Jason Guy writes: > I am not entirely sure why the ONIE documentation shows the IANA and ONIE > suboptions,
=> the IANA block is a round around for an ISC DHCP bug and is fully useless for Kea. > but this is a "real-world" use-case => so in fact this is not... > although I don't know if they are in the same packet. => they are (DHCPv6 but not DHCPv4 uses multiple options, one per vendor, and as it is used by DHCPv4-over-DHCPv6 it is correctly handled by the code (but not by configs because they are a bit too specialized for cable labs :-)). > When you say that "full support of multiple > vendors", do you mean in the same packet, or in the config? => same packet again. When you receive a VIVSO only the first vendor block is unpacked. If you try to send one (by config or using current code) only the first vendor block is handled. > I suppose this is easy enough to do in a hook though. => not so easy because the OptionVendor class was not designed to handle multiple vendors. > I suppose that makes sense since the substring matching is done in hex. > Since the client classification I am working with, needs to return a VIVSO > option > with additional suboptions populated by the classifier, then defining the > schema in an option-def is necessary, right? => it is not necessary: an unknown (sub)option is considered as being binary and can be specified only by its code. Not very convenient but still working. > > => almost this but hex uses hexadecimal so you have to translate "powerpc" > > in 0x706f7765727063 > > I read in the docs that a substring match with the .hex is compared as > ASCII to the right operand. => you are right. > I figured there would be an ordering feature... For now it is good to know > the classes are ordered lexicographically. => the ticket fixing this is in the review queue. > > "option-data": [ > > > { > > > "code": 125, > > > "csv-format": true, > > > "data": "42623,0", > > > > => I don't believe this data works (at least it didn't when I created > > a ticket to fix it some years ago :-). => according to what I read from the code the ",0" is simply ignored. > This raises an interesting question in general. If I wanted to use vendor > options from multiple vendor enterprise-ids (not in the same packet), this > may not work? => with the "not in the same packet" it should be possible to find a way to have different option-data entries and to control which one will be used. > Would this be the proper syntax to define/support multiple VIVSO options? => there is none for the same option-data. For different option-data entries it is like other options. > > > { > > > "code": 0, > > > > => if it does not bug it should! > > > > Hmm...the configuration was accepted. I can look in the logs, hopefully it > was gracefully handled and ignored. => I have to see how code 0 is handled. It is forbiden in most of spaces but not in VIVSO suboptions according to the standard. Thanks Francis Dupont <fdup...@isc.org> _______________________________________________ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users