Bug#690889: udhcpc always returns a domain of "bad" when receiving a valid dhcp ack packet

[Иван Сусанин <susanin@gmail.com>]

Thank you for reply, Michael,

Standards are good, but you can't reverse the time and make already existent software to follow them on global scale. How would you fix dhclient stuff for old OSes?

IMHO, it still possible to follow standard and have partial acceptance of old way - instead of replacing whole domain line by "bad", take only part till space, eg:

if (ch == '\0' || ch == ' ' || ch == '.' )
                               return label;

Then, there is 100% correct domain (abusers of opt. 15 usually know what they are doing), everything conformant to standard, and no breakage for old software! Everyone is happy again :)

And, if you do insist on standards, then yes, "/* NS_MAXLABEL; labels must be 63 chars or less */" , we want this.

Thanks,

D

2014-04-18 10:06 GMT+03:00 Michael Tokarev <mjt@tls.msk.ru>:

18.04.2014 00:21, Иван Сусанин wrote:
[]

> I've already reopened original udchpc bug at busybox bugtracker (https://bugs.busybox.net/show_bug.cgi?id=3979), but it looks like I'm asking for a miracle...

I've seen that discussion.  And frankly, I strongly support Denis here.
We've a well-documented dhcp options used for various things - namely,
for setting domain name and for setting domain search path.  However,
for some reason, those options has been abused (or, rather, used
incorrectly) for years.  Now, when software actually refuses to let
this abuse happen, we complain that the software is bad.  But it just
follows the standard.

> What can be done on this matter?

I think the best is to fix the  setup.

Thanks,

/mjt