Re: DHCP non-issues
On Wed, 21 Jul 2021 at 07:56, Stuart Henderson wrote: > > > Maybe the patch above fixes other problems for other people's machines. > > > The use case the diff helps is where you need working network when > another daemon is started. (the order of netstart vs dhcpleased needs > changing in /etc/rc too, otherwise it will always timeout on a v4-only > network, because dhcpleased doesn't run until later). > Thank you and Theo for the reply. Very helpful!
Re: DHCP non-issues
On 2021/07/21 07:24, jungle Boogie wrote: > On Tue, 20 Jul 2021 at 13:00, Theo de Raadt wrote: > > > > The following diff will help the most common cases. netstart will pause > > a little bit until at least one (v4 or v6) default route is installed. > > In the most common cases, this is immediate. In the dynamic cases, the > > delay is probably enough. We don't need to solve all potential problems.. > > > > > > In my test, on one machine, this did not pause long enough to bring up > the hostname.wg0 interface. > > I see this in dmesg: > pf enabled > starting network > ifconfig: no address associated with name > > running: > kern.version=OpenBSD 6.9-current (GENERIC.MP) #138: Wed Jul 21 00:57:06 MDT > 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Maybe the patch above fixes other problems for other people's machines. This diff pauses at the end of netstart, after hostname.* are all configured. It won't help when you want to resolve a name from one of the hostname.* files (e.g. in your case I guess it's wgendpoint ). If you can use an IP address instead, that's simplest. If the name is unavoidable (for example if the other side of the wg tunnel uses dynamic dns), I'd suggest configuring wg from rc.local instead. The use case the diff helps is where you need working network when another daemon is started. (the order of netstart vs dhcpleased needs changing in /etc/rc too, otherwise it will always timeout on a v4-only network, because dhcpleased doesn't run until later).
Re: DHCP non-issues
jungle Boogie wrote: > On Tue, 20 Jul 2021 at 13:00, Theo de Raadt wrote: > > > > The following diff will help the most common cases. netstart will pause > > a little bit until at least one (v4 or v6) default route is installed. > > In the most common cases, this is immediate. In the dynamic cases, the > > delay is probably enough. We don't need to solve all potential problems.. > > > > > > In my test, on one machine, this did not pause long enough to bring up > the hostname.wg0 interface. > > I see this in dmesg: > pf enabled > starting network > ifconfig: no address associated with name You appear to be putting a hostname into a hostname.* file? That is not what this fixes. And you should not be doing that.
Re: DHCP non-issues
On Tue, 20 Jul 2021 at 13:00, Theo de Raadt wrote: > > The following diff will help the most common cases. netstart will pause > a little bit until at least one (v4 or v6) default route is installed. > In the most common cases, this is immediate. In the dynamic cases, the > delay is probably enough. We don't need to solve all potential problems.. > > In my test, on one machine, this did not pause long enough to bring up the hostname.wg0 interface. I see this in dmesg: pf enabled starting network ifconfig: no address associated with name running: kern.version=OpenBSD 6.9-current (GENERIC.MP) #138: Wed Jul 21 00:57:06 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Maybe the patch above fixes other problems for other people's machines.
Re: DHCP non-issues
Claudio Jeker wrote: > On Tue, Jul 20, 2021 at 08:53:03AM -, Stuart Henderson wrote: > > On 2021-07-19, jungle Boogie wrote: > > > 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 > > > > or d. add an entry to /etc/hosts > > > > Some people are also running into problems with hostnames in pf.conf; > > a c and d apply in that case too. > > > > Some of this could be fixed by having a way to ask dhcpleased to wait > > (with timeout) for an address during boot. For your example with wg, > > as well as that, netstart would need to be split i.e. start standard > > interfaces, then dhcpleased/unwind/resolvd, then tunnel interfaces. > > > > I was going to say the same would apply for hostnames used in fstab > > if /usr and /var are NFS-mounted; but actually /usr and /var can't > > be NFS-mounted if you rely on addresses from dhcpleased to reach the > > NFS server anyway (these daemons need access to /var so they need > > to be started after /usr and /var are mounted). > > > > Actually this needs to be fixed in /etc/netstart, dhcpleasd / slaacd. Until > now systems with dynamic ips had the 10sec wait of dhclient to make sure > the interfaces are up and configured. This no longer and because of this > stuff breaks left and right. > > Up until now the system relied on the fact that after /etc/netstart ran > the interfaces where up and configured (static or dynamic) and all > following services relied on this fact. Honestly adding host entires is > not a solution because it will not work in all cases. e.g. pf rules using > interface names as addresses will not work correctly. > > There must be a way to wait at the end of netstart to ensure that network > configuration settled or timed out. IIRC dlg@ hat a diff that allowed > something along these lines. > > We already hit this issue with slaacd on IPv6-only setups and ignored it. > Now it affects everyone, lets not ignore it again. The following diff will help the most common cases. netstart will pause a little bit until at least one (v4 or v6) default route is installed. In the most common cases, this is immediate. In the dynamic cases, the delay is probably enough. We don't need to solve all potential problems.. Index: etc/netstart === RCS file: /cvs/src/etc/netstart,v retrieving revision 1.213 diff -u -p -u -r1.213 netstart --- etc/netstart16 Jul 2021 15:21:41 - 1.213 +++ etc/netstart20 Jul 2021 16:20:15 - @@ -335,3 +335,9 @@ if [[ $ip6kernel == YES ]]; then sleep 1 done fi + +# Pause a little so at least one dynamic (slaacd or dhcpleased) config completes +count=0 +while ((count++ < 20 && $(route -n show | grep '^default ' | wc -l) == 0)); do + sleep .5 +done
Re: DHCP non-issues
Is it still possible to reject dhcp replies from certain servers? Here in the Netherlands ISPs provide you with a random pick of black box routers with their plans. Last year I had a VodafoneZiggo plan, offering 8 variants, and currently I have a KPN plan which has 12. Both times I received their most recent hardware model. The default connection method is to have your ISP router function as a gateway through which your connections pass via a (usually very poor) NAT engine. Luckily I was able to put these devices in "bridge" mode through their respective front-end menus. The goal was to avoid as much software layers as possible, receive the external IP on my OpenBSD gateway box, as well as all unfiltered traffic. However, whenever the VodafoneZiggo router had a reboot cycle (e.g. when the ISP pushed a software update) it would first go into its default state - providing local dhcp et al. - before it would go into bridge mode shortly after. This consistently broke my setup. My current KPN router does things differently: the local dhcpd cannot be disabled even in this "bridge" mode. Meaning it will be the response that wins discovery every time. Again, breaking my setup. I solved these issues by putting the following in my dhclient.conf, resp.: reject 192.168.1.254; reject 192.168.100.1;
Re: DHCP non-issues
On 2021-07-20, Kevin Chadwick wrote: > On July 20, 2021 10:35:55 AM UTC, Kevin Chadwick wrote: >>On Mon, 19 Jul 2021, 12:47 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. >>> >> > > Is it possible to try inet autoconf and then also inet6 autoconf > opportunistically maybe even with inet preferred, for deployment in > foreign networks? > > Yes and that was possible with dhclient too.
Re: DHCP non-issues
On July 20, 2021 10:35:55 AM UTC, Kevin Chadwick wrote: >On Mon, 19 Jul 2021, 12:47 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. >> > Is it possible to try inet autoconf and then also inet6 autoconf opportunistically maybe even with inet preferred, for deployment in foreign networks?
Re: DHCP non-issues
Paul de Weerd(we...@weirdnet.nl) on 2021.07.19 20:04:35 +0200: > 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: Thanks for the details. The details are important here. They can be worked around by doing what dhclient did - wait. But they can also be fixed in the programs that have the actual problem, i.e. in syslogd and the NFS setup. Which is, i hope what we will do.
Re: DHCP non-issues
On Tue, Jul 20, 2021 at 08:53:03AM -, Stuart Henderson wrote: > On 2021-07-19, jungle Boogie wrote: > > 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 > > or d. add an entry to /etc/hosts > > Some people are also running into problems with hostnames in pf.conf; > a c and d apply in that case too. > > Some of this could be fixed by having a way to ask dhcpleased to wait > (with timeout) for an address during boot. For your example with wg, > as well as that, netstart would need to be split i.e. start standard > interfaces, then dhcpleased/unwind/resolvd, then tunnel interfaces. > > I was going to say the same would apply for hostnames used in fstab > if /usr and /var are NFS-mounted; but actually /usr and /var can't > be NFS-mounted if you rely on addresses from dhcpleased to reach the > NFS server anyway (these daemons need access to /var so they need > to be started after /usr and /var are mounted). > Actually this needs to be fixed in /etc/netstart, dhcpleasd / slaacd. Until now systems with dynamic ips had the 10sec wait of dhclient to make sure the interfaces are up and configured. This no longer and because of this stuff breaks left and right. Up until now the system relied on the fact that after /etc/netstart ran the interfaces where up and configured (static or dynamic) and all following services relied on this fact. Honestly adding host entires is not a solution because it will not work in all cases. e.g. pf rules using interface names as addresses will not work correctly. There must be a way to wait at the end of netstart to ensure that network configuration settled or timed out. IIRC dlg@ hat a diff that allowed something along these lines. We already hit this issue with slaacd on IPv6-only setups and ignored it. Now it affects everyone, lets not ignore it again. -- :wq Claudio
Re: DHCP non-issues
On 2021-07-19, jungle Boogie wrote: > 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 or d. add an entry to /etc/hosts Some people are also running into problems with hostnames in pf.conf; a c and d apply in that case too. Some of this could be fixed by having a way to ask dhcpleased to wait (with timeout) for an address during boot. For your example with wg, as well as that, netstart would need to be split i.e. start standard interfaces, then dhcpleased/unwind/resolvd, then tunnel interfaces. I was going to say the same would apply for hostnames used in fstab if /usr and /var are NFS-mounted; but actually /usr and /var can't be NFS-mounted if you rely on addresses from dhcpleased to reach the NFS server anyway (these daemons need access to /var so they need to be started after /usr and /var are mounted).
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/
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
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
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
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, 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 >
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
