Bjørn Mork <[email protected]> writes: > Bjørn Mork <[email protected]> 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?
I take it "outsider" contributions are not welcome here? Or am I just too impatient again? Bjørn _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
