| Age | Commit message (Collapse) | Author |
|---|
|
Instead of repairing potential garbage ensure that we receive proper C
strings. Inspired by a similar diff by deraadt@ for ldapd.
|
|
macro-build a replacement for sccsid, and was done without any concern
for namespace damage. Unfortunately this practice started infecting
other code as others were unaware they didn't need the file.
ok millert guenther
|
|
When we first request a lease (INIT or REBOOTING state) we run with
very short timeouts. If the dhcp server is slow to respond we already
have a new xid and ignore the server's response. This goes on until we
increase the timeout high enough. If we just stick to an xid this will
not happen and we accept "late" responses.
RFC 2131 has:
Selecting a new 'xid' for each retransmission is an implementation
decision. A client may choose to reuse the same 'xid' or select a new
'xid' for each retransmitted message.
Problem seen by phessler on german train wifi.
OK phessler
|
|
Internally this doesn't matter since we only care about equality.
This makes logging output comparable to tcpdump(8).
Pointed out by joel@
OK claudio
|
|
code more compact. No binary change.
OK claudio
|
|
requested-ip option as well as setting ciaddr.
This started with joel@ pointing out that their CPE is ignoring
RENEWING and REBINDING requests when ciaddr was not set.
RFC 2131 4.3.6, Table 4 has a good overview, we got a bunch of it
wrong.
Previously the logic for this was all over the place which made it
difficult to reason about, it is now contained in the engine process
in request_dhcp_request() and request_dhcp_discover().
Problem pointed out by, lots of testing and review as well as OK joel@
Additional testing and 50% review benno@
|
|
client identifier is configured like the man page claims we would do.
Problem found and patch by Joel Knight (knight.joel AT gmail), thanks!
|
|
calculate the next timeout based on the rebinding time (T2), not
renewal time (T1). At this point T1 already expired and we would wait
way too long, past the lease lifetime.
Spotted while investigating a problem reported by Zack Newman on misc@
|
|
There is no requirement other than replying to client port 68/udp
as per RFC 2131, so drop the 67/udp check.
Same conclusion from florian
Reported and tested by Roc Vallès < vallesroc AT gmail DOT com>, thanks!
|
|
Problem reported by Guy Godfroy on bugs, thanks!
|
|
functions that take "char *" arguments. Where such chars are
assigned to int or passed to ctype functions, explicitly cast them
to unsigned char.
For OpenBSD's clang, -Wpointer-sign has been disabled by default,
but when the parse.y code was built elsewhere, the compiler would
complain.
With help from millert@
ok benno@ deraadt@
|
|
Committing on behalf of jmc
OK deraadt
|
|
Requested by & OK sthen
mdoc clue by schwarze
|
|
should be used when the client identifier is not a hardware address,
for example if it's just a string. It turns out that the majority of
dhcp clients (and possibly servers?) does not do this but rather
transmits the client identifier verbatim if a string is
configured. The first character becomes the hardware type.
Make dhcpleased(8) behave the same.
Difference in behavior with dhclient(8) and interoperability issues
with dhcp(8) first pointed out by Olivier Cherrier on misc@
OK sthen
fine to get it in for 7.0 deraadt
|
|
behind its back. When a lease gets renewed dhcpleased simply adds all
routes and lets the kernel sort duplicates out.
This however leads to "failed to send route message: File exists"
messages in /var/log/daemon which are confusing. Since this is
expected do not log it as an error.
While here change the error message when proposing nameservers so that
it can be distinguished from failed routes.
Pointed out by deraadt
|
|
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
|
