Bjørn Mork <bj...@mork.no> writes: > RFC3942 reserved the range 224 - 254 for site-specific options. .. > Unfortunately the udhcp code still hard codes vendor-specific > usage of options 249 and 252. This makes many site-specific use > cases impossible.
Any hope of a comment/reject/friendly hug here? This is a real issue for me since I depend on a DHCP server using option 252 to signal some local state, coded as a low valued 16 bit big endian integer. I.e two bytes where the first one always is 0 and the second one is important. Decoding option 252 as OPTION_STRING results in an empty string being sent to the udhcpc script, losing the original content. For no good reason AFAICS. The bogus mapping even bloats the code by a couple of unnecessary bytes. Can we please just clean it up and become more standards compliant? Bjørn _______________________________________________ busybox mailing list busybox@busybox.net https://lists.busybox.net/mailman/listinfo/busybox
