DHCP non-issues
Look guys, it's simple. If you want IPv6 (SLAAC) autoconfiguration, you set "inet6 autoconf" for that interface. slaacd(8) will then automatically handle things. If you want IPv4 (DHCP) autoconfiguration, you set "inet autoconf" for that interface. dhcpleased(8) will then automatically handle things. If you require special DHCP options that dhcpleased(8) doesn't include, then you don't enable autoconfigurarion and run dhclient(8) instead, which can be extensively configured. Both slaacd(8) and dhcpleased(8) pass nameserver information to resolvd(8), which adds those nameservers to /etc/resolv.conf unless unwind(8) is running. If you don't want that to happen for some other reason, you turn off resolvd(8). And that's it. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: DHCP non-issues
On Mon, Jul 19, 2021 at 01:42:41PM +0200, Christian Weisgerber wrote: > Look guys, it's simple. > > If you want IPv6 (SLAAC) autoconfiguration, you set "inet6 autoconf" > for that interface. slaacd(8) will then automatically handle things. > > If you want IPv4 (DHCP) autoconfiguration, you set "inet autoconf" > for that interface. dhcpleased(8) will then automatically handle > things. If you require special DHCP options that dhcpleased(8) > doesn't include, then you don't enable autoconfigurarion and run > dhclient(8) instead, which can be extensively configured. > > Both slaacd(8) and dhcpleased(8) pass nameserver information to > resolvd(8), which adds those nameservers to /etc/resolv.conf unless > unwind(8) is running. If you don't want that to happen for some > other reason, you turn off resolvd(8). > > And that's it. Hi Christian, Would OpenBSD be interested in a daemon that gets nameserver information from pppoe0 and passes this nameserver information to resolvd(8)? Currently there is no way to do that, so a userland daemon that uses a bpf device to spy on pppoe(4) may be worthwhile to write? Is this overcomplicating things? Let me know what you think about this proposal, I've worked around it for so long but always wanted to write something like this. The old userland pppoed could probably be used for an example, no? Best Regards, -peter > -- > Christian "naddy" Weisgerber na...@mips.inka.de >
Re: DHCP non-issues
On Mon, Jul 19, 2021 at 01:42:41PM +0200, Christian Weisgerber wrote: | Look guys, it's simple. | | If you want IPv6 (SLAAC) autoconfiguration, you set "inet6 autoconf" | for that interface. slaacd(8) will then automatically handle things. | | If you want IPv4 (DHCP) autoconfiguration, you set "inet autoconf" | for that interface. dhcpleased(8) will then automatically handle | things. If you require special DHCP options that dhcpleased(8) | doesn't include, then you don't enable autoconfigurarion and run | dhclient(8) instead, which can be extensively configured. | | Both slaacd(8) and dhcpleased(8) pass nameserver information to | resolvd(8), which adds those nameservers to /etc/resolv.conf unless | unwind(8) is running. If you don't want that to happen for some | other reason, you turn off resolvd(8). One thing of note though, is the fact that dhcpleased does its work in the background. This means that other services will start before you get a lease. In the past, dhclient(8) ran in the foreground, trying to get a lease until some timeout expired. *Usually*, that timeout didn't trigger (at least, in my use cases). So far, I've found NFS and syslogd to need configuration changes or /etc/hosts entries to ensure they start properly. One could argue that in these cases, one shouldn't use DHCP and just use statically configured addresses (especially in the case of syslog, where you lose messages when the service starts before an address is configured, even with your remote syslog host added to /etc/hosts) Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: DHCP non-issues
On Mon, 19 Jul 2021 at 04:48, Christian Weisgerber wrote: > > Look guys, it's simple. > > If you want IPv6 (SLAAC) autoconfiguration, you set "inet6 autoconf" > for that interface. slaacd(8) will then automatically handle things. > > If you want IPv4 (DHCP) autoconfiguration, you set "inet autoconf" > for that interface. dhcpleased(8) will then automatically handle > things. If you require special DHCP options that dhcpleased(8) > doesn't include, then you don't enable autoconfigurarion and run > dhclient(8) instead, which can be extensively configured. > > Both slaacd(8) and dhcpleased(8) pass nameserver information to > resolvd(8), which adds those nameservers to /etc/resolv.conf unless > unwind(8) is running. If you don't want that to happen for some > other reason, you turn off resolvd(8). > Sounds like great information to put in current.html: https://www.openbsd.org/faq/current.html I think folks are surprised by the change and want to know how to handle the new daemons in certain situations. Your explanation above is very helpful and probably could be used in current.html I imagine the 7.0 "what's new" section will contain something similar. What do I need to do to have WireGuard start at boot when I want to use a hostname in my hostname.wg0 interface file? Currently, the interface doesn't come up as expected: ifconfig: no address associated with name Are these my options? a. use dhclient b. make a script to start the interface later c. use ip address > And that's it. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > Thanks! -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info
Re: DHCP non-issues
Peter J. Philipp: > Would OpenBSD be interested in a daemon that gets nameserver information from > pppoe0 and passes this nameserver information to resolvd(8)? Currently there > is no way to do that, so a userland daemon that uses a bpf device to spy on > pppoe(4) may be worthwhile to write? Is this overcomplicating things? Too complicated. Quoting from resolvd.8: resolvd also monitors the routing socket for proposals learned by dhclient(8), dhcpleased(8), slaacd(8), or network devices which natively learn DNS information such as umb(4). I think pppoe(4)--well, sppp(4) actually--needs to learn the nameserver information and send it to the routing socket. umb(4) should provide a template. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: DHCP non-issues
Christian Weisgerber wrote: > Peter J. Philipp: > > > Would OpenBSD be interested in a daemon that gets nameserver information > > from > > pppoe0 and passes this nameserver information to resolvd(8)? Currently > > there > > is no way to do that, so a userland daemon that uses a bpf device to spy on > > pppoe(4) may be worthwhile to write? Is this overcomplicating things? > > Too complicated. Quoting from resolvd.8: > resolvd also monitors the routing socket for proposals learned > by dhclient(8), dhcpleased(8), slaacd(8), or network devices which > natively learn DNS information such as umb(4). > > I think pppoe(4)--well, sppp(4) actually--needs to learn the > nameserver information and send it to the routing socket. umb(4) > should provide a template. Precisely. That's the whole idea -- that any new kind of DNS-aware network can submit routing socket proposals -- either from userland as slaacd/dhcpleased do, or from the kernel as umb(4) does now -- and resolved will using a sorting algorithm to place the DNS address into resolv.conf It is even better if the subsystem can submit offer withdraws when they go down, so that the resolv.conf file can get updated again. So if it wants to do withdraws, it must be integrated into the ppp code correctly.
Re: DHCP non-issues
On Mon, Jul 19, 2021 at 01:59:18PM +0200, Paul de Weerd wrote: | So far, I've found NFS and syslogd to need configuration changes or | /etc/hosts entries to ensure they start properly. As I was asked about this off-list, I went back and re-read my message. Apologies for not being more clear: syslog: If you configure a remote syslog server to receive messages from your OpenBSD machine, there are two separate issues. First, a hostname will not resolve to an IP address if the network is not up yet (because dhcpleased/slaacd are still waiting for a response from the local dhcpd(8) or rad(8)). This shows up as syslogd[73481]: bad hostname "@udp4://tuna" if your configuration has '@udp4://tuna' as a target. The solution is to create an entry in /etc/hosts. However, now when the system boots, syslog will have a target IP address to communicate with, but it still doesn't have an IP address for itself. So any traffic sent to the target is lost, until dhcpleased configures an address on the autoconf interface. This results in, for example, the dmesg from the freshly booting machine not ending up on the remote syslog host. nfs client: If your /etc/fstab contains NFS mounts to a remote host, the fact that dhcpleased doesn't wait for a lease will mean that NFS mounts cannot happen until a lease has been configured. This shows up as "NFS Portmap: RPC: Port mapper failure - RPC: Unable to send", and a delay during boot that's significantly longer than the timeout from dhclient. For the record, my clients here are all vmm(4) VMs running OpenBSD. The NFS server and syslog target also run OpenBSD. Cheers, Paul -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
