Implementing getSubOptionValue
preaction opened this issue · 6 comments
I've got a need to implement the getSubOptionValue method: I need to get the option 82 subtype 1 to know what client just tried getting a DHCP address.
It looks like getSubOptionValue is implemented, but commented-out completely with a FIXME note above. What's left to fix so that I can make this method work?
The code there is just copied from getOptionValue, i havent gotten around to reworking it to decode suboptions.
Alright. I can do that and submit a PR.
I would be delighted to accept the PR
Just FYI There are packet captures of option 82 in the t/data directory and tests that are already examining those captures. Both would be a great lace to tune your code. If you have more exotic captures of option 82 thy would be great to have added!
It seems like RFC 3046 does not define what data types individual suboptions are required to take. Our use-case for it requires that suboption 1 (client id) is a string, but the pcap data files in the t/ directory have suboption 1 values that are clearly hex (leading null bytes).
Luckily, people can just use getSubOptionRaw() to get the raw string version, and getSubOptionValue() to get the hex value, but what about any other format? Do we just make people do the thing themselves?
Youre seeing why its not implemented :)
Have a go at it as best you can, and in general I just see what wireshark does with the packet then take that as being correct.