Re: DHCP client error: domain_not_set.invalid
Hi, Mark Andrews wrote: This is just the attitude that's going to get people to use other software. People are going to laugh at you trying to get a network connection and joke it works fine with Windows. Then you try and explain that it's not your OS's fault and somebody messed up some setting somewhere else. And then they laugh some more watching you struggle. Actually it is reasonable. Windows lets users violate RFC's in many ways. Yes, it might be reasonable, but it is still going to stop you from being able to connect to a network, whereas Windows users have no problems. RFC 952 specifies what is legal in a hostname. While one can theoretically search for things other than hosts the only real use of the search strings today is for hostnames and/or mail domains (which are syntactically indentical to hostnames). What would be really interesting to know is what they expect the customers to find using this suffix. Actually the entire search domain thing is pretty useless in most cases for home users (unless they have their own internal network, in which case they have their own DNS and DHCP servers). People navigate the internet using fully qualified domain names and it is almost never necessary to have a search domain; it just slows things down having it search for hostnotfound.domain.com.mysearchdomain.com. My bet is that this really is just a configuration error on their part. Could be, or more probably it's just the default setting of the modem. I've had one of these modems, and it took me forever to find the proper setting because in the web interface of the modem they obviously didn't feel like calling it search domain; I can't remember what they called it but they annotated it with the comment necessary for some ISPs, which just completely wrong-footed me. I'm not fall into an endless discussion so I'm going to wrap it up, but I think it would be really nice if the FreeBSD user could solve this problem themselves instead of having to rely on other people that may not be inclined to put much priority on the issue. And by that I mean a solution other than hacking the code, which is quite much to ask of a regular user. An option to ignore the setting would be just fine, an option to override it even better. I don't know if you can even disable the search domain (haven't read the RFC) but this would be even better in many cases, avoiding queries that are not necessary. Greetings, Seb* ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DHCP client error: domain_not_set.invalid
Hi, Greg Barniskis wrote: Mark Andrews wrote: Yes it is reasonable to expect ISP to fix things like this. You pay the ISP to operate there part of the network within the operational contraints of the RFCs (Standards track and BCP). I totally agree. Make sure when calling tech support on things like this that you are *not* asking them to provide FreeBSD support, that you can handle that angle of the connection quite well, thanks. Explain that the evidence shows that their system appears to violate global connectivity standards (if you can name which RFC and exactly how it's violated, great, but don't expect first tier help desk phone operators to understand that as it is probably way, way beyond their troubleshooting script). I think this would all be reasonable in a perfect world. In the real world you're paying the operator to get internet access and they often list which operating systems they support (and they don't list FreeBSD). They're going to ask you what operating system are you running, then ask you if your connection works; and when you say it works under windows but violates an ``RFC'' they're just not going to give it much priority. Then when the help desk staff goes uhm..., politely ask to be escalated to second tier and clearly and politely state your case there, again making it clear that you are *not* asking for FreeBSD support, but support by them of global connectivity standards that every ISP ought to be respecting. At least you have a chance of getting your trouble ticket marked something like Unresolved -- Bug instead of Resolved -- Unsupported OS. That is to say, the kind of ticket that self-escalates to engineers and managers somewhere away from the help desk proper. The word chance says it all. And all the time you're hoping for this chance to become reality you cannot use your broadband connection. Furthermore there are two other problems with this approach: 1) it often costs you a lot of money (even though it can be argued that it is reasonable that ISPs fix real problems free of charge and not charge you an arm and a leg for it, in the real world the situation is often not so perfect). 2) it often costs you a lot of time; it's going to be really hard to even get your request escalated to second tier, and it's definately going to take days and mulitple calls before they start to take you seriously. In the end, it's the FreeBSD user that suffers. Greetings, Sebastiaan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DHCP client error: domain_not_set.invalid
Mark Andrews wrote: What would be really interesting to know is what they expect the customers to find using this suffix. My bet is that this really is just a configuration error on their part. As is often said: Never attribute to malice what can adequately be explained by incompetence. :) And I'm afraid that's just the case here. signature.asc Description: OpenPGP digital signature
Re: DHCP client error: domain_not_set.invalid
Mark Andrews wrote: --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 13, 2005 at 07:14:00PM -0800, Mark Space wrote: Hi all, =20 I just set up the latest 6.0 release, and I'm getting errors with the=20 DHCP client. Trying to pull a network address during start up, I get: =20 Bogus domain search list 15: domain_not_set.invalid =20 This repeats several times before giving up. Google tells me that this= =20 problem was report by two users on the bsd-current list. No one ever=20 replied to their inquiries (at least on the list), so I thought to try=20 once more to see if there's any interest in addressing this issue.=20 =20 More info was in the original post: http://lists.freebsd.org/pipermail/freebsd-current/2005-October/057034.ht= ml We should really bitch and then ignore this value when it's bogus rather than rejecting the lease. We should also probably allow underscores since they are popular among clueless Microsoft admins. Please try the follow patch. Yes. They are clueless. However giving into their cluelessness just perpetuates the cluelessness. Underscores have never been legal in hostnames. Underscores are deliberately used to provide namespaces which do not collide with the hostname namespace. Accepting underscores just allows the namespaces to collide. Mark Sorry for the late reply. I just read this thread and this issue affects me as well. Hopefully I'm not commenting on something that has been fixed but I can't test STABLE at the moment to verify that... I understand the idea that bad values should be rejected, but in reality, I have the same DSL modem that these others have and there is no way to change the domain search list that it sends. No way that I could find at least. This is SBC-Yahoo in California, so there are a lot of people out there with this modem. I had to modify the source code to accept the lease anyway. Now my network stops working every time I rebuild and forget to re-patch the source. I shouldn't have to patch the source code to be able to accept a lease. A single bad lease option shouldn't prevent a lease from being accepted without choice. dhcpd should either 1. accept bogus names (warnings are fine) 2. offer a configuration option or command line switch to allow the bogus domain if we wish 3. offer a configuration option like isc-dhcpd does so that we can ignore or override the setting Number 3 is the best IMHO, number 2 is easier but similar, and number one has already been done in less than a line of code and could be deployed right now. - Sam Nilsson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DHCP client error: domain_not_set.invalid
Sorry for the late reply. I just read this thread and this issue affects me as well. Hopefully I'm not commenting on something that has been fixed but I can't test STABLE at the moment to verify that... I understand the idea that bad values should be rejected, but in reality, I have the same DSL modem that these others have and there is no way to change the domain search list that it sends. No way that I could find at least. This is SBC-Yahoo in California, so there are a lot of people out there with this modem. Well ring your ISP and complain. Too many people just accept crappy service. I had to modify the source code to accept the lease anyway. Now my network stops working every time I rebuild and forget to re-patch the source. I shouldn't have to patch the source code to be able to accept a lease. A single bad lease option shouldn't prevent a lease from being accepted without choice. Use cvs rather than cvsup. That way your changes are preserved. You can either use the cvs servers directly or if you have enough disk space you can use cvsup to copy the repository and run cvs against the local copy of the repository. dhcpd should either 1. accept bogus names (warnings are fine) 2. offer a configuration option or command line switch to allow the bogus domain if we wish 3. offer a configuration option like isc-dhcpd does so that we can ignore or override the setting Number 3 is the best IMHO, number 2 is easier but similar, and number one has already been done in less than a line of code and could be deployed right now. - Sam Nilsson -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DHCP client error: domain_not_set.invalid
Hi, I understand the idea that bad values should be rejected, but in reality, I have the same DSL modem that these others have and there is no way to change the domain search list that it sends. No way that I could find at least. This is SBC-Yahoo in California, so there are a lot of people out there with this modem. Well ring your ISP and complain. Too many people just accept crappy service. This is just the attitude that's going to get people to use other software. People are going to laugh at you trying to get a network connection and joke it works fine with Windows. Then you try and explain that it's not your OS's fault and somebody messed up some setting somewhere else. And then they laugh some more watching you struggle. Furthermore it's really not realistic to expect that ISP's are going to do anything about it either. They have a billion other more important issues other than solving that insignificant problem that that guy who is using an unsupported OS has. They really don't care. dhcpd should either 1. accept bogus names (warnings are fine) 2. offer a configuration option or command line switch to allow the bogus domain if we wish 3. offer a configuration option like isc-dhcpd does so that we can ignore or override the setting I would have to agree here. I think option 2 is great, because it gets people to be aware of the problem, but it allows them to workaround it if necessary. I really think it's terrible to have the software just reject a lease because of an invalid search domain, without you being able to fix it without hacking code. That's going a bit overboard IMHO and is just going to cause more problems than it's going to solve. Greetings, Sebastiaan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DHCP client error: domain_not_set.invalid
Hi, I understand the idea that bad values should be rejected, but in reality, I have the same DSL modem that these others have and there is no way to change the domain search list that it sends. No way that I could find at least. This is SBC-Yahoo in California, so there are a lot of people out there with this modem. Well ring your ISP and complain. Too many people just accept crappy service. This is just the attitude that's going to get people to use other software. People are going to laugh at you trying to get a network connection and joke it works fine with Windows. Then you try and explain that it's not your OS's fault and somebody messed up some setting somewhere else. And then they laugh some more watching you struggle. Actually it is reasonable. Windows lets users violate RFC's in many ways. Furthermore it's really not realistic to expect that ISP's are going to do anything about it either. They have a billion other more important issues other than solving that insignificant problem that that guy who is using an unsupported OS has. They really don't care. Yes it is reasonable to expect ISP to fix things like this. You pay the ISP to operate there part of the network within the operational contraints of the RFCs (Standards track and BCP). RFC 952 specifies what is legal in a hostname. While one can theoretically search for things other than hosts the only real use of the search strings today is for hostnames and/or mail domains (which are syntactically indentical to hostnames). What would be really interesting to know is what they expect the customers to find using this suffix. My bet is that this really is just a configuration error on their part. Mark dhcpd should either 1. accept bogus names (warnings are fine) 2. offer a configuration option or command line switch to allow the bogus domain if we wish 3. offer a configuration option like isc-dhcpd does so that we can ignore or override the setting I would have to agree here. I think option 2 is great, because it gets people to be aware of the problem, but it allows them to workaround it if necessary. I really think it's terrible to have the software just reject a lease because of an invalid search domain, without you being able to fix it without hacking code. That's going a bit overboard IMHO and is just going to cause more problems than it's going to solve. Greetings, Sebastiaan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DHCP client error: domain_not_set.invalid
Mark Andrews wrote: Yes it is reasonable to expect ISP to fix things like this. You pay the ISP to operate there part of the network within the operational contraints of the RFCs (Standards track and BCP). I totally agree. Make sure when calling tech support on things like this that you are *not* asking them to provide FreeBSD support, that you can handle that angle of the connection quite well, thanks. Explain that the evidence shows that their system appears to violate global connectivity standards (if you can name which RFC and exactly how it's violated, great, but don't expect first tier help desk phone operators to understand that as it is probably way, way beyond their troubleshooting script). Then when the help desk staff goes uhm..., politely ask to be escalated to second tier and clearly and politely state your case there, again making it clear that you are *not* asking for FreeBSD support, but support by them of global connectivity standards that every ISP ought to be respecting. At least you have a chance of getting your trouble ticket marked something like Unresolved -- Bug instead of Resolved -- Unsupported OS. That is to say, the kind of ticket that self-escalates to engineers and managers somewhere away from the help desk proper. -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) gregb at scls.lib.wi.us, (608) 266-6348 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DHCP client error: domain_not_set.invalid
I had this as well. It means that your DHCP server returns an invalid search domain. The easy way to solve it (if you have access) is to set the search domain to something valid in your DHCP server (Linksys router by any chance?). I couldn't find a flag on dhclient to tell it to ignore invalid search domains: this would be really handy so that you can connect to badly set up networks when you don't have access to the router. Greetings, Sebastiaan Mark Space wrote: Hi all, I just set up the latest 6.0 release, and I'm getting errors with the DHCP client. Trying to pull a network address during start up, I get: Bogus domain search list 15: domain_not_set.invalid This repeats several times before giving up. Google tells me that this problem was report by two users on the bsd-current list. No one ever replied to their inquiries (at least on the list), so I thought to try once more to see if there's any interest in addressing this issue. More info was in the original post: http://lists.freebsd.org/pipermail/freebsd-current/2005-October/057034.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DHCP client error: domain_not_set.invalid
On Sun, Nov 13, 2005 at 07:14:00PM -0800, Mark Space wrote:
Hi all,
I just set up the latest 6.0 release, and I'm getting errors with the
DHCP client. Trying to pull a network address during start up, I get:
Bogus domain search list 15: domain_not_set.invalid
This repeats several times before giving up. Google tells me that this
problem was report by two users on the bsd-current list. No one ever
replied to their inquiries (at least on the list), so I thought to try
once more to see if there's any interest in addressing this issue.
More info was in the original post:
http://lists.freebsd.org/pipermail/freebsd-current/2005-October/057034.html
We should really bitch and then ignore this value when it's bogus rather
than rejecting the lease. We should also probably allow underscores
since they are popular among clueless Microsoft admins. Please try the
follow patch.
-- Brooks
Index: dhclient.c
===
RCS file: /home/ncvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.11
diff -u -p -r1.11 dhclient.c
--- dhclient.c 2 Sep 2005 17:35:35 - 1.11
+++ dhclient.c 14 Nov 2005 17:42:46 -
@@ -67,6 +67,7 @@ __FBSDID($FreeBSD: src/sbin/dhclient/dh
#definePERIOD 0x2e
#definehyphenchar(c) ((c) == 0x2d)
+#defineunderscorechar(c) ((c) == 0x5f)
#definebslashchar(c) ((c) == 0x5c)
#defineperiodchar(c) ((c) == PERIOD)
#defineasterchar(c) ((c) == 0x2a)
@@ -76,7 +77,7 @@ __FBSDID($FreeBSD: src/sbin/dhclient/dh
#definewhitechar(c) ((c) == ' ' || (c) == '\t')
#defineborderchar(c) (alphachar(c) || digitchar(c))
-#definemiddlechar(c) (borderchar(c) || hyphenchar(c))
+#definemiddlechar(c) (borderchar(c) || hyphenchar(c) ||
underscorechar(c))
#definedomainchar(c) ((c) 0x20 (c) 0x7f)
#defineCLIENT_PATH PATH=/usr/bin:/usr/sbin:/bin:/sbin
@@ -2252,6 +2253,8 @@ check_option(struct client_lease *l, int
if (!res_hnok(sbuf)) {
warning(Bogus Host Name option %d: %s (%s), option,
sbuf, opbuf);
+ l-options[option].len = 0;
+ free(l-options[option].data);
return (0);
}
return (1);
@@ -2260,7 +2263,8 @@ check_option(struct client_lease *l, int
if (!check_search(sbuf)) {
warning(Bogus domain search list %d: %s (%s),
option, sbuf, opbuf);
- return (0);
+ l-options[option].len = 0;
+ free(l-options[option].data);
}
}
return (1);
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgpO2iV1xJxOj.pgp
Description: PGP signature
Re: DHCP client error: domain_not_set.invalid
Thanks to Sebastian and Brooks for their quick replies. I took the easy
way out and installed the ISC client which works just fine.
The problem is my DHCP server is a DSL modem. I don't see any way to
set the domain field. In addition, this interface is really not on a
network but a connection between two networks (its PPPoE), it make sense
that my ISP has configured the modem this way. The interface is one
that will be addressed only by address, it really doesnt have a name.
Or at least, the DHCP server doesn't assign a domain, its set elsewhere.
So I think Brooks is correct. The dhcp client should just ignore the
domain setting and just assume that there is no domain associated with
this interface. Should we suggest this to the OpenBSD client maintainer?
Brooks Davis wrote:
On Sun, Nov 13, 2005 at 07:14:00PM -0800, Mark Space wrote:
Hi all,
I just set up the latest 6.0 release, and I'm getting errors with the
DHCP client. Trying to pull a network address during start up, I get:
Bogus domain search list 15: domain_not_set.invalid
This repeats several times before giving up. Google tells me that this
problem was report by two users on the bsd-current list. No one ever
replied to their inquiries (at least on the list), so I thought to try
once more to see if there's any interest in addressing this issue.
More info was in the original post:
http://lists.freebsd.org/pipermail/freebsd-current/2005-October/057034.html
We should really bitch and then ignore this value when it's bogus rather
than rejecting the lease. We should also probably allow underscores
since they are popular among clueless Microsoft admins. Please try the
follow patch.
-- Brooks
Index: dhclient.c
===
RCS file: /home/ncvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.11
diff -u -p -r1.11 dhclient.c
--- dhclient.c 2 Sep 2005 17:35:35 - 1.11
+++ dhclient.c 14 Nov 2005 17:42:46 -
@@ -67,6 +67,7 @@ __FBSDID($FreeBSD: src/sbin/dhclient/dh
#define PERIOD 0x2e
#define hyphenchar(c) ((c) == 0x2d)
+#defineunderscorechar(c) ((c) == 0x5f)
#define bslashchar(c) ((c) == 0x5c)
#define periodchar(c) ((c) == PERIOD)
#define asterchar(c) ((c) == 0x2a)
@@ -76,7 +77,7 @@ __FBSDID($FreeBSD: src/sbin/dhclient/dh
#define whitechar(c) ((c) == ' ' || (c) == '\t')
#define borderchar(c) (alphachar(c) || digitchar(c))
-#definemiddlechar(c) (borderchar(c) || hyphenchar(c))
+#definemiddlechar(c) (borderchar(c) || hyphenchar(c) ||
underscorechar(c))
#define domainchar(c) ((c) 0x20 (c) 0x7f)
#define CLIENT_PATH PATH=/usr/bin:/usr/sbin:/bin:/sbin
@@ -2252,6 +2253,8 @@ check_option(struct client_lease *l, int
if (!res_hnok(sbuf)) {
warning(Bogus Host Name option %d: %s (%s), option,
sbuf, opbuf);
+ l-options[option].len = 0;
+ free(l-options[option].data);
return (0);
}
return (1);
@@ -2260,7 +2263,8 @@ check_option(struct client_lease *l, int
if (!check_search(sbuf)) {
warning(Bogus domain search list %d: %s (%s),
option, sbuf, opbuf);
- return (0);
+ l-options[option].len = 0;
+ free(l-options[option].data);
}
}
return (1);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DHCP client error: domain_not_set.invalid
--61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 13, 2005 at 07:14:00PM -0800, Mark Space wrote: Hi all, =20 I just set up the latest 6.0 release, and I'm getting errors with the=20 DHCP client. Trying to pull a network address during start up, I get: =20 Bogus domain search list 15: domain_not_set.invalid =20 This repeats several times before giving up. Google tells me that this= =20 problem was report by two users on the bsd-current list. No one ever=20 replied to their inquiries (at least on the list), so I thought to try=20 once more to see if there's any interest in addressing this issue.=20 =20 More info was in the original post: http://lists.freebsd.org/pipermail/freebsd-current/2005-October/057034.ht= ml We should really bitch and then ignore this value when it's bogus rather than rejecting the lease. We should also probably allow underscores since they are popular among clueless Microsoft admins. Please try the follow patch. Yes. They are clueless. However giving into their cluelessness just perpetuates the cluelessness. Underscores have never been legal in hostnames. Underscores are deliberately used to provide namespaces which do not collide with the hostname namespace. Accepting underscores just allows the namespaces to collide. Mark -- Brooks -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DHCP client error: domain_not_set.invalid
On Mon, Nov 14, 2005 at 10:48:09AM -0800, Mark Space wrote:
Thanks to Sebastian and Brooks for their quick replies. I took the easy
way out and installed the ISC client which works just fine.
The problem is my DHCP server is a DSL modem. I don't see any way to
set the domain field. In addition, this interface is really not on a
network but a connection between two networks (its PPPoE), it make sense
that my ISP has configured the modem this way. The interface is one
that will be addressed only by address, it really doesnt have a name.
Or at least, the DHCP server doesn't assign a domain, its set elsewhere.
So I think Brooks is correct. The dhcp client should just ignore the
domain setting and just assume that there is no domain associated with
this interface. Should we suggest this to the OpenBSD client maintainer?
OpenBSD already does this. If someone can test the two behaviors I'll
commit them.
-- Brooks
Brooks Davis wrote:
On Sun, Nov 13, 2005 at 07:14:00PM -0800, Mark Space wrote:
Hi all,
I just set up the latest 6.0 release, and I'm getting errors with the
DHCP client. Trying to pull a network address during start up, I get:
Bogus domain search list 15: domain_not_set.invalid
This repeats several times before giving up. Google tells me that this
problem was report by two users on the bsd-current list. No one ever
replied to their inquiries (at least on the list), so I thought to try
once more to see if there's any interest in addressing this issue.
More info was in the original post:
http://lists.freebsd.org/pipermail/freebsd-current/2005-October/057034.html
We should really bitch and then ignore this value when it's bogus rather
than rejecting the lease. We should also probably allow underscores
since they are popular among clueless Microsoft admins. Please try the
follow patch.
-- Brooks
Index: dhclient.c
===
RCS file: /home/ncvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.11
diff -u -p -r1.11 dhclient.c
--- dhclient.c 2 Sep 2005 17:35:35 - 1.11
+++ dhclient.c 14 Nov 2005 17:42:46 -
@@ -67,6 +67,7 @@ __FBSDID($FreeBSD: src/sbin/dhclient/dh
#define PERIOD 0x2e
#define hyphenchar(c) ((c) == 0x2d)
+#define underscorechar(c) ((c) == 0x5f)
#define bslashchar(c) ((c) == 0x5c)
#define periodchar(c) ((c) == PERIOD)
#define asterchar(c) ((c) == 0x2a)
@@ -76,7 +77,7 @@ __FBSDID($FreeBSD: src/sbin/dhclient/dh
#define whitechar(c) ((c) == ' ' || (c) == '\t')
#define borderchar(c) (alphachar(c) || digitchar(c))
-#define middlechar(c) (borderchar(c) || hyphenchar(c))
+#define middlechar(c) (borderchar(c) || hyphenchar(c) ||
underscorechar(c))
#define domainchar(c) ((c) 0x20 (c) 0x7f)
#define CLIENT_PATH PATH=/usr/bin:/usr/sbin:/bin:/sbin
@@ -2252,6 +2253,8 @@ check_option(struct client_lease *l, int
if (!res_hnok(sbuf)) {
warning(Bogus Host Name option %d: %s (%s), option,
sbuf, opbuf);
+l-options[option].len = 0;
+free(l-options[option].data);
return (0);
}
return (1);
@@ -2260,7 +2263,8 @@ check_option(struct client_lease *l, int
if (!check_search(sbuf)) {
warning(Bogus domain search list %d: %s
(%s),
option, sbuf, opbuf);
-return (0);
+l-options[option].len = 0;
+free(l-options[option].data);
}
}
return (1);
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgpUNEcGfxjnX.pgp
Description: PGP signature
