| Age | Commit message (Collapse) | Author |
|---|
|
With this
dhcpleasectl em0
does the same as
dhclient em0
used to do. To please people's muscle memory one can be aliased to the other.
earlier version OK benno
with lots of help massaging the output & OK deraadt
|
|
Problem reported by claudio
OK benno
|
|
The only indication we get is sendto(2) failing, so if our UDP packet
is silently dropped somewhere we won't notice.
This has been observed in the wild with a dhcp server at the remote
end of a VPN. The dhcp server is reachable via broadcast so we get an
initial lease. However the server is not in the same subnet as the
lease we are getting so to reach it unicast we depend on a default
route being set. When the VPN goes down we lose the default route [*]
and when dhcpleased then tries to renew the lease (unicast), sendto(2)
fails with "network unreachable".
[*] The exact mechanics on how this happens are unclear. I.e. why
didn't dhcpleased(8) see a link-state change and transitioned to
REBOOTING / INIT? Regardless, we shouldn't ignore sendto(2) errors.
Reported by stsp, OK benno
|
|
we get a RTM_IFANNOUNCE message not a RTM_IFINFO message.
Handle this message to not accumulate "unknown" interfaces.
OK benno
|
|
|
|
|
|
From Scott Bennett, thanks!
|
|
as ignoring servers entirely.
Tested by bket
Parser looks reasonable to benno
man page OK jmc
|
|
This tries to reaquire the current lease and if that failes will send
a DHCPDISCOVER message to request any lease.
OK benno
|
|
server responds to our DHCPDISCOVER but is then slow to respond to our
DHCPREQUEST.
MAX_EXP_BACKOFF_FAST was introduced to get us quickly out of the
REBOOTING state when we switch networks and no dhcp server would NAK
our old lease but just ignore us. This is not the issue here, there is
a dhcp server willing to talk to us, it's just slow.
Problem reported, tested & OK jca
|
|
REBOOTING. There will be a few more cases internal to dhcpleased that
have nothing to do with the control socket.
While here move requesting a new lease via a call to dhclient under
ifndef SMALL, nothing on the ramdisk uses this.
|
|
|
|
An upcoming diff for dhclient(8) will make it exit when it discovers
an autoconf flag at startup.
"Quite a pleasing diff." deraadt@
|
|
Suggested by schwarze
|
|
|
|
concern raised by kn.
ok florian
|
|
|
|
client identifier (option 61). Some dhcp servers expect these options
and refuse to hand out a lease without them.
Need for vendor class identifier pointed out & tested by bket
Need for client identifier pointed out by sthen
Input & reads OK sthen (as part of a larger diff)
OK kn (as part of a larger diff)
|
|
configuring the same IP.
Found the hard way by afresh1
|
|
defaults before validating the times to prevent excessive logging.
Found the hard way & OK brynet
|
|
probably stuck in some way and the user wants a mostly clean slate.
If we already have an IP address transition to state REBOOTING so that
we no longer unicast dhcp requests. We will then try to reacquire our
lease twice before giving up and transition to INIT and send dhcp
discover messages accepting any IP address.
|
|
whether the address we received in our lease is already configured.
In the case I observed, no default route was added to the routing table
even though the server provided both an address and a route option.
As it happened the leased address was already configured on the interface.
This should not prevent routing table updates, but it did.
ok florian
|
|
resolvd(8), slaacd(8) and dhcpleased(8) are different from other daemons
in that there must only be a single instance.
resolvd already does this, adjust slaacd and dhcpleased accordingly while
moving the lockfile paths under /dev/ such that they work early on boot and
don't run into races should /var be (un)mounted between daemon starts.
Locking is especially required in the installer where all three daemons are
started every time the "(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? "
prompt is entered, i.e. restarting installation or dropping into a shell
and back into the prompt again would start multiple instances.
To avoid expected lockfile error messages in between installer prompts,
discard standard error when starting the autoconf daemons; none of them
has other potential failure cases in installer mode before daemon(3)izing.
Input sthen deraadt
OK deraadt
|
|
as mandated by RFC3442.
Pointed out by, initial diff, testing & OK bket@
|
|
fails to report the path that the failure occured on. Suggested by
deraadt@ after some tech discussion.
Work done and verified by Ashton Fagg <ashton@fagg.id.au>
ok deraadt@ semarie@ claudio@
|
|
file for the installer.
|
|
|
|
in previous.
|
|
For this we need to be able to handle multiple routes being sent from
the engine to the main process as well as to the control tool.
The configuration of the various cases (default route, directly
connected routes, non-default route via a gateway) was inspired by
dhclient's set_routes() and should behave the same way.
Tested by Uwe Werler
|
|
the control socket instead of fatal().
OK deraadt
|
|
switching from chroot("/var/empty") to unveil("/", "").
This is just an extra pair of suspenders since these processes
pledge(2) to not access the filesystem.
OK deraadt
|
|
|
|
padding because the ethernet header in front is only 14 bytes.
Found the hard way by me while testing on sparc64.
Solution suggested by & OK deraadt
|
|
values as specified in RFC2131 section 4.4.5. Allows my Comtrend VI-3223u
to work.
OK florian@
|
|
Doing so implies support for it, but dhcpleased(8) currently ingores it
entirely and does not configure any route from it.
As per RFC 3442 servers SHOULD NOT respond with a "routers" option when
"classless-static-routes" is set.
dhcpd(8)/dhcpd.conf(5) follows that, hence requesting but not using static
routes results in not installing any routes at all.
Stop signaling support for this option and only request "routers" such that
dhcpleased continues to install a default route and properly ignores the
unsupported option if used by the server.
Report from Uwe Werler <uwe @ werler dot is> about a default route not
being set when requesting the "classless-static-routes" dhcp-options(5)
from dhcpd(8), thanks!
OK florian
|
|
need to provide the address of the interface behind which the default
router is in case they are on the same subnet otherwise the kernel
can't figure out which route we are talking about
This happens for example when your wifi and wired networks are bridged.
Pointed out by claudio some time ago.
|
|
interoperable with BOOTP we should also send packets that have a
minimum size of 300.
I haven't seen a DHCP server that actually enforces this except the
one in vmd(8), but it doesn't cost us much and prevents hair pulling
later on when we find one in the wild.
OK deraadt
|
|
|
|
getifaddrs on every route message.
This also allows us to drop the route pledge since we only need to
fetch the interface state with getifaddrs on startup.
|
|
state of the machine on startup using ioctl(2) and getifaddrs(3).
We can then update this state with information provided by route
messages. We still need getifaddrs(3) to check if the layer 2 address
has changed.
This simplifies error handling (what should we do if ioctl(2) fails?),
reduces kernel round trips (no need to ask the kernel again for
information RTM_IFINFO provided already) and prevents a theoretical
race between RTM_IFINFO and getaddrinfo(3).
In a fast link state UP -> DOWN -> UP transition RTM_IFINFO informs us
that the link went down but we were not using this information but
rather looked at getifaddrs(3) information which might see the link as
already up again. We would then do nothing while we should try to get
a new lease.
By storing all interface information in the frontend process we can
skip imsgs to the engine process if we get an RTM_IFINFO without
relevant changes for us.
|
|
|
|
it.
|
|
AF_LINK and skip one ioctl.
OK benno
|
|
behind -vv or by deleting unneeded output.
While here reword some debug output to make it more useful.
(There is more to be done here.)
|
|
handles this for us by doing a state transition if we have been stuck
in "rebooting" or "requesting" for too long.
Makes the code a bit simpler and we only have one place were we need
to special case the timeout cap.
|
|
they don't like them instead of sending a DHCPNAK. Found the hard way
by benno who didn't want to wait 127 seconds.
Due to another bug dhcpleased would have exit through a fatal() in the
frontend process if he had waited long enough for a Rebooting -> Init
transition because we didn't deconfigure our IP address and thus
didn't close our UDP socket. Upon configuring a new IP address we would
open a new UDP socket send it to the frontend which would then fatal()
due to an unexpected fd passed in.
Aproporiate timings are rather underspecified in RFC 2131. Instead of
doing an exponential backoff up to 64 in the "Rebooting" and
"Requesting" state only go up to 2 for a total of 3 packets and total
timeout of 3 seconds before going into "Init" state and sending a
DHCPDISCOVER.
To prevent the fatal() in the frontend process we reshuffle the state
transition into the "Init" state and deconfigure the IP when
appropriate.
|
|
I'm worried we could see packets we shouldn't during a small time window.
|
|
|
|
when the lease directory does not exist.
This means that dhcpleased(8) will no longer request a previously
configured IP address from the dhcp server and will fall back to
DHCPDISCOVER which requests any IP address from the dhcp server.
This likely makes diskless(8) work with dhcpleased(8).
A normal diskless(8) setup has only / mounted via nfs when
dhcpleased(8) starts. /var exists but nothing is mounted there yet,
meaning /var/db/dhcpleased does not exist so lease files are disabled.
dhcpleased(8) sends a DHCPDISCOVER to request any IP address but since
the dhcp server has (very likely) a 'fixed-address' configured we get
the same IP back that is already configured.
If /var/db/dhcpleased/ exists on / (and /var is *NOT* mounted later)
in a diskless(8) setup, care must be taken that the root file system is
not shared between machines.
If /var/db/dhcpleased/ exists on / and /var on NFS is mounted over
this later bad things probably happen. This is a configuration error
and must befixed.
discussed with deraadt@
Actuall tests on existing diskless(8) setups would be appreciated.
|
|
|
