link is lost. devd will start a new dhclient instance when link is
restored.
PR: bin/166656
Submitted by: Peter Jeremy (mostly)
Reviewed by: brooks (earlier version from Peter)
MFC after: 1 month
In the original Domain Search option patch, an invalid option value
would cause the whole lease to be rejected. However, DHCP servers who
emit such an invalid value are more common than I thought. With this new
patch, just the option is rejected, not the entire lease.
PR: bin/163431
Submitted by: Fabian Keil <fk@fabiankeil.de> (earlier version)
Reviewed by: Fabian Keil <fk@fabiankeil.de>
Sponsored by: Yakaz (http://www.yakaz.com)
that changed 0.0.0.0/0.0.0.0 prefix to 0.0.0.0/255.0.0.0.
In the r228313 this behavior was fixed, and since dhclient-script
got broken.
I'm not sure this fix is a perfect one, it just changes
dhclient-script to set 0.0.0.0/255.0.0.0 explicitly.
PR: kern/163206
The "domain-search" option (option 119) allows a DHCP server to publish
a list of implicit domain suffixes used during name lookup. This option
is described in RFC 3397.
For instance, if the domain-search option says:
".example.org .example.com"
and one wants to resolve "foobar", the resolver will try:
1. "foobar.example.org"
2. "foobar.example.com"
The file /etc/resolv.conf is updated with a "search" directive if the
DHCP server provides "domain-search".
A regression test suite is included in this patch under
tools/regression/sbin/dhclient.
PR: bin/151940
Sponsored by Yakaz (http://www.yakaz.com)
it to configure the interface. When the script is complete, dhclient
monitors the routing socket and will terminate if its address is
deleted or if its interface is removed or brought down.
Because the routing socket is already open when dhclient-script is
run, dhclient ignores address deletions for 10 seconds after the
script was run.
If the address that will be obtained is already configured on the
interface before dhclient starts, and if dhclient-script takes more
than 10 seconds (perhaps due to dhclient-*-hooks latencies), on script
completion, dhclient will immediately and silently exit when it sees
the RTM_DELADDR routing message resulting from the script reassigning
the address to the interface.
This change logs dhclient's reason for exiting and also changes the
10 second timeout to be effective from completion of dhclient-script
rather than from when it was started.
We now ignore RTM_DELADDR and RTM_NEWADDR messages when the message
contains no interface address (which should not happen) rather than
exiting.
Not reviewed by: brooks (timeout)
MFC after: 3 weeks
packets instead of allowing the protocol stack to pick a random source port.
This fixes the behaviour where dhclient would never transition from RENEWING
to BOUND without going through REBINDING in networks which are paranoid about
DHCP spoofing, such as most mainstream cable-broadband ISP networks.
Reviewed by: brooks
Obtained from: OpenBSD (partly - I'm not convinced their solution can work)
MFC after: 1 week (pending re approval)
internal buffer sizes.
When we 'append', assume we're appending to text. Some MS dhcp servers will
give us a string with the length including the trailing NUL. when we 'append
domain-name', we get something like "search x.y\000 z" in resolv.conf :(
MFC after: 1 week
Security: A buffer overflow (by one NUL byte) was possible.
In the MPSAFE TTY branch, I noticed PTY's to be leaked, because
dhclient's privileged process was run inside the session of, say, the
login shell. Make sure we call setsid() here.
Approved by: philip (mentor), brooks
interface is one with the default route (or there isn't one). Use it to
decide if we should adjust the default route and /etc/resolv.conf.
Fix the delete of the default route. The if statement was totally bogus
and the delete only worked due to a typo. [1]
Reported by: Jordan Coleman <jordan at JordanColeman dot com> [1]
MFC after: 1 week
lease: track the current bssid and if it changes (as reported in an
assoc/reassoc) event only then kick the state machine. This gives us
immediate response when roaming but otherwise causes us to fallback on
the normal state machine.
Reviewed by: brooks, jhb
MFC after: 3 weeks
The original DHCP specification includes a route option but it supports
only class-based routes. RFC3442 adds support for specifying the netmask
width for each static route. A variable length encoding is used to minimize
the size of this option.
PR: bin/99534
Submitted by: Andrey V. Elsukov <bu7cher@yandex.ru>
Reviewed by: brooks
length != BPF_WORDALIGN(length)
This meeans that it is possible for this to be true:
interface->rbuf_offset > interface->rbuf_len
Handle this case in the test for running out of packets. While
OpenBSD's solution of setting interface->rbuf_len to
BPF_WORDALIGN(length) is safe due to the size of the buffer, I think
this solution results in less hidden assumptions.
This should fix the problem of dhclient running away and consuming 100%
CPU.
PR: bin/102226
Submitted by: Joost Bekkers <joost at jodocus.org>
MFC after: 3 days
despite the interface link status.
Add dhclient_flags_iface and background_dhclient_iface rc.conf options.
(where iface is a specific interface). These can be used to give
interface specific flags to dhclient.
Reviewed by: brooks@
with NACK if I don't set it. Setting 'option dhcp-client-identifier' is
alternative but it is inconvenient because I have to keep the list of
all MAC addresses. As bin/94743 pointed out, it is always sent from
Windows clients and I found Mac OS X does the same.
OK'd by: brooks
option if none is given in the config file. Also add #ifdefd out
support for sending a client ID based on our MAC address.
PR: bin/94743, bin/76401
Submitted by: Frank Behrens <frank at pinky dot sax dot de>
X-MFC after: 6.1-RELEASE
/tmp may not be writeable yet when dhclient is first run via
/etc/rc.d/netif so using it may not work. Also, writing to a
predictable file in /tmp as root is a really bad idea since a malicious
user may be able to win a race and insert a symlink which will allow
them to cause any file to be overwritten. To solve these problems,
create the tempory file in /var/run which will exist this early and is
writable only by root.
Security: Local risk if users can cause dhclient to run on demand
(such as by unplugging and replugging the network cable).
entries from the interface rather than using ifconfig's delete command.
This preserves non-dhclient configured addresses (though they are wiped
out when dhclient is restarted).
MFC after: 1 week
renewal, or we lose link, be more forceful about clearing interface
state so another interface that connects to the same network has a
chance of working. This doesn't address attemping to connect to both at
once, but appears to allow unplugging from a wired interface and then
inserting a wireless card that associates with an AP bridged to the same
LAN.
