| Age | Commit message (Collapse) | Author |
|---|
|
various *d, *conf, *ctl files (where relevant) and simple;
also makes "man -k routing" more useful;
help from claudio and florian
ok claudio florian millert
|
|
Luckily routesock would never be <= 2 so shutdown would always failing
with EINVAL and not shutting down random other sockets.
The kernel was just uselessly piling up route messages that we were
never reading.
This mistake first showed up in slaacd(8) and then was copied to the
other daemons.
Reported & fixed by Josiah Frentsos (jfrent at tilde.team), thanks!
OK kn
|
|
florian@ and myself. ok florian@
|
|
When started manuall from single-user mode (/ still read-only), the current
error is misleading:
# slaacd -dv
slaacd: already running
The lock was specifically added to prevent multiple instances in the
installer, which discards the error message entirely anyway.
Retain the useful EAGAIN/"already running" message, but otherwise print the
real error reason:
# slaacd -dv
slaacd: /dev/slaacd.lock: Read-only file system
Feedback OK deraadt millert
|
|
resolvd, slaacd, unwind.
The mitigation story is way better: syscalls are in a randomly located
libc, and every syscall stub is randomly located inside that due to
random relinking. As opposed to fixed offset inside a release binary.
There is one known consequence: /usr nfs mounting must use statically
configured IP addresses.
ok kettenis florian, others
|
|
Feedback OK jmc
|
|
interface.
This works around a problem where the kernel always deletes
the first default route if there are multiple present
with the same gateway.
This only fixes the problem when running ifconfig inet -autoconf.
There are other cases where we call configure_rotures(RTM_DELETE), for
example when setting ignore routes in dhcpleased.conf and issuing a
reload. To fix that we either need help from the kernel to distinguish
routes by IFP or track priorities and hope they are unique.
Problem reported by mbuhl.
OK claudio
|
|
to the same gateway.
Unfortunately this doesn't help with deleting the correct route when
issuing ifconfig inet -autoconf, the kernel always deletes the first
route. This is the one with the lowest priority if the routes have
different priorities.
What does work is identifying routes by priority but dhcpleased(8)
doesn't set the priority so that the kernel choses the right one
when adding a route and it doesn't yet track the priority the
kernel set.
Another issue is that we might end up with routes having the same
gateway and same priority pointing out of different interfaces. For
example when two ethernet interfaces are set to autoconf and they are
connected to the layer 2 network. This seems like a bad idea but it is
something that could be configured.
Problem reported by mbuhl, claudio suggested to try to send an IFP.
Even though it doesn't work, it seems worthwhile to send the IFP for
when the kernel gains the ability to distinguish routes by IFP.
|
|
FDs in flight. Things then get confusing. The kernel tells us we can
read from the bpf FD but the data is actually "on the other FD", so
read(2) returns 0.
Found the hard way by, and patiently debugged with weerd@
One way to trigger this is booting a vmm VM where dhcpleased(8)'s
init_ifaces() loses a race against netstart(8). init_ifaces() would
already see the autoconf flag and request a bpf FD.
But then it would receive a RTM_IFINFO message without the autoconf flag
set from when the interface came up. Then it will see another RTM_IFINFO
message with the autoconf flag set and request yet another bpf FD. If
the first bpf FD had not arrived yet we ended up with two in the frontend
process.
While here make sure a bpf FD has been received for an iface before
trying to close(2) it.
tweak & OK dv
|
|
so add the missing .Cm macros; markup error reported by espie@;
OK florian@ espie@
|
|
maintenance window, my ISP started sending an unexpected 'ff' byte at
the very end which created noise in the log. Apparently this came up
before.
From and ok florian
|
|
domain name option with length 1 and a single \0.
We strip trailing \0 and then end up with length 0.
This is a protocol violation, the minimum length for domain name option
is 1, and we ignore the lease.
Since we are not going to get this fixed this server side, we might as
well just pretend that we didn't receive a domain name (or host name).
We only ever care about them in the installer anyway. Not getting a
lease because of this corner case is not helpful.
OK deraadt
|
|
The minimum length of a hostname is 1 according to RFC 2132.
Found the hard way by Ibrahim Khalifa (ibo AT trukonsult.se) with DHCP
Relay on a Cisco ASA in the installer where we don't have a hostname
yet.
Ibrahim also provided a diff which I simplified a bit.
OK tb
|
|
jmc@ dislikes a comma before "then" in a conditional, so leave those
untouched.
ok jmc@
|
|
this avoids having to test for NULL and swap the right name in place
in a bunch of places. it also avoids having NULL passed to format
strings in the parser.
the only place where it actually matters if we're using the default
or not is when we're parsing the config. if you don't specify a
config, and the default file doesnt exist, that's ok.
ok florian@
|
|
ASCII data should not include trailing NUL but we MUST delete trailing
NULs on receiving.
Jan Vlach ( janus AT volny.cz) reported that Microsoft DHCP server
sends the domain name option with a trailing NUL which the installer
put into /etc/myname as a trailing ^@ which smtpd does not like.
Fix some whitespace while here.
Input & OK millert
|
|
Diff from hagen@sdf.org, tweaks by me.
OK phessler
testing & OK bket
|
|
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)
|
