Convert sbin and usr.bin to check for imsgbuf_init failure and add
imsgbuf_allow_fdpass where needed.

OK tb@

Convert the common imsgbuf_read calls to the post EAGAIN world.

OK tb@

Use imsgbuf_clear() where appropriate instead of msgbuf_clear().

OK tb@

Rename imsg_init, imsg_clear, imsg_read, imsg_write and imsg_flush to
imsgbuf_init, imsgbuf_clear, imsgbuf_read, imsgbuf_write and imsgbuf_flush.

This separates the imsgbuf API from the per-imsg API

Rename imsg_init, imsg_clear, imsg_read, imsg_write and imsg_flush to
imsgbuf_init, imsgbuf_clear, imsgbuf_read, imsgbuf_write and imsgbuf_flush.

This separates the imsgbuf API from the per-imsg API.

OK tb@

show more ...

Convert imsg_write() callers to the new simplified return logic.

OK tb@

Introduce imsg_write() and use it instead of msgbuf_write().

imsg_write() is just a thin wrapper around msgbuf_write(). So this is
mostly search and replace.

OK tb@

Use i2s instead of hard coding the imsg type. Suggested by tb.

errno is unset, use fatalx(3) instead of fatal(3).

Be stricter in what we accept from the main process.

While here mention function where fatalx(3) occurred like everywhere
else.

Suggested by & OK tb

Do not peek inside of struct imsg.

input & OK tb

more sleepy florian knf issues

Switch to rebinding at the rebinding time not when one timeout past.

Spotted while hacking on dhcp6leased(8)

Only generate a new xid at the start of getting a new lease.

"RFC 2131 4.1 Constructing and sending DHCP messages" has this:

| Selecting a new 'xid' for each retransmission is an implementation
| d

Only generate a new xid at the start of getting a new lease.

"RFC 2131 4.1 Constructing and sending DHCP messages" has this:

| 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.

We used to change xid for each request / response cycle but this ran
into problems with slow dhcp servers where we would change the xid too
frequently and would ignore late coming replies from the server.

Andre S points out that table 5 in "4.4.1 Initialization and
allocation of network address" says for the xid field in "DHCPREQUEST"
messages:

| 'xid' from server DHCPOFFER message

This seems to suggest that we need to use the same xid for the whole
DHCPDISCOVER / DHCPOFFER / DHCPREQUEST / DHCPACK exchange of messages.

Nothing else in the RFC is saying this though.

But since there are DHCP servers out there that depend on this, we
only generate a new xid when entering the INIT, REBOOTING and RENEWING
state.

I do wonder if we should just go with a static value of 0x04, which
was chosen by a fair dice roll, so guaranteed to be random.

Issue reported, initial diff and fix tested by Andre S
deraadt likes this version
OK tb

show more ...

Put checksum flags in bpf_hdr to use them in userland dhcpleased.

Thus, dhcpleased accept non-calculated checksums which were verified by
hardware/hypervisor.

With tweaks from dlg@

ok bluhm@
mkay

Put checksum flags in bpf_hdr to use them in userland dhcpleased.

Thus, dhcpleased accept non-calculated checksums which were verified by
hardware/hypervisor.

With tweaks from dlg@

ok bluhm@
mkay tobhe@

show more ...

Use imsg_get_fd() to access the fd passed with the imsg.
Go ahead florian@ OK tb@

First stab at IPv6-only preferred from RFC8925.

This lets dhcpleased(8) request "IPv6-only preferred". If the
server replies with this option dhcpleased stops and does not request
a lease and deconf

First stab at IPv6-only preferred from RFC8925.

This lets dhcpleased(8) request "IPv6-only preferred". If the
server replies with this option dhcpleased stops and does not request
a lease and deconfigures IPv4 on the interface.

For now this is pretty much useless unless one dynamically configures
pf(4) to act as a CLAT. gelatod(8) from ports can help with this.

However, this helps me while hacking on a kernel based stateless CLAT
by moving dhcpleased out of the way while having an IPv6-mostly
network configured to compare behaviour with macOS.

Input jmc
OK phessler
Input & OK sthen

show more ...

typo: ignorning -> ignoring

From Laurie Tratt, ok florian

Switch the log_warnx() about trailing garbage to log_debug(). After a
maintenance window, my ISP started sending an unexpected 'ff' byte at
the very end which created noise in the log. Apparently th

Switch the log_warnx() about trailing garbage to log_debug(). After a
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

show more ...

As found by n18fuhtm AT tutanota.com there are dhcp servers that send a
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 violat

As found by n18fuhtm AT tutanota.com there are dhcp servers that send a
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

show more ...

According to RFC 2132, 2. BOOTP Extension/DHCP Option Field Format
ASCII data should not include trailing NUL but we MUST delete trailing
NULs on receiving.

Jan Vlach ( janus AT volny.cz) reported t

According to RFC 2132, 2. BOOTP Extension/DHCP Option Field Format
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

show more ...

Make host name DHCP option configurable.
Diff from hagen@sdf.org, tweaks by me.
OK phessler
testing & OK bket

Make sure we receive what we expect over imsg.

Instead of repairing potential garbage ensure that we receive proper C
strings. Inspired by a similar diff by deraadt@ for ldapd.

Only generate a new xid on state change.

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

Only generate a new xid on state change.

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

show more ...

Treat xid as a uint32_t in network byte order on the wire.

Internally this doesn't matter since we only care about equality.
This makes logging output comparable to tcpdump(8).

Pointed out by joel@

Treat xid as a uint32_t in network byte order on the wire.

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

show more ...

Replace struct member assignment with struct assignment to make the
code more compact. No binary change.
OK claudio