According to RFC3396 long dhcp options must be splitted
mthielemann opened this issue · 2 comments
If using long dhcp options (e.g. option 43) these should be splitted into multiple options. Currently if using addOptionRaw(DHO_VENDOR_ENCAPSULATED_OPTIONS ... with a value > 255 bytes Net::DHCP creates a malformed dhcp packet because it puts the whole data into a single option 43. According to RFC3396 Net::DHCP must split the option into multiple options of the same type. So currently we have for example a single option 43 with 500 bytes but there should be two options 43. One with the first 255 bytes of the value and another one with the remaining 245 bytes. This applies not just for the option 43 but here it is most common that you have a lot of data.
H Marc
Thanks for the bug. If you would like to submit a patch i will gladly include it, otherwise i will look at this sometime in janurary.
Hi Dean,
I found a way to make it work for me. I noticed that addOptionRaw is also able to take an arrayref as argument and then the resulting dhcp packet contains multiple occurrences of the same dhcp option. But anyway. There should be an "emergency split" if someone tries to put too much data into a dhcp option. So it's just to avoid corrupt dhcp packets in some special cases and to be more rfc compliant ...