Re: How to troubleshoot DHCP issues?
Thanks a lot Stuart! Really appreciate your insights. I've been running some more tests and here are some new results: 1. Without MAC spoofing and a statically assigned IP address, axe lasted around twelve days on an AX88772B before throwing the following error: axe0: watchdog timeout axe0: usb error on tx: IN PROGRESS axe0: usb error on tx: TIMEOUT This time tcpdump shows only incoming packets but not outgoing packets. (which is opposite from last time...) Have not yet tested axen and ure without MAC spoofing yet, but I highly suspect that there will be similar errors. I start to have a feeling that the problems are specific to Raspberry Pi 4B because these USB adapters seem really common and someone else would definitely have discovered the issue before me should amd64 be affected. 2. I tried changing MAC address to a fixed value on bse with `lladdr XX:XX:XX:XX:XX:XX`, and it has been running without issue for four days so far... But frankly I don't know how much randomness there are in those issues. > I'm still pondering the fact that you don't see incoming packets even > when tcpdump is running, as (unless you used tcpdump -p) that > would set the nic in promiscuous mode.. I believe I did `tcpdump -n -i `, sometimes with '-vvv'. Best Regards On 8/6/21 3:46 AM, Stuart Henderson wrote: hopefully copying to bugs@ (if I remember how to do that correctly from slrn/gmane..) Please keep that in CC's when replying. Earlier misc@ mail copied in below to keep things together in one place. On 2021-08-06, beebeet...@posteo.de wrote: My first suggestion might be to stay with a single lladdr for a while to see if your setup works for more than a day and a half. Thanks for the suggestion! It seems that with `lladdr random` removed, the problem does not seem to disappear. On 2021-08-06, beebeet...@posteo.de wrote: Sorry, there was a typo: The problem *does disappear* with `lladdr random` removed . Good, so you have a workaround for now. lladdr random Why this line? I was wondering the same thing. What problem do you think you are solving by doing this? I try to make it harder for my ISP to gather information about the device I'm using, thus was using random MAC address. The "random" lladdr catches my eye. But I don't know how frequently that changes. Could it change every time the lease is renewed? Skimming through the code for dhcpleased, looks like there's no invocation of the SIOCSIFLLADDR ioctl, so I would assume that the lladdr stays the same unless the netstart script is re-run (thus invoking ifconfig to change lladdr), but I will to test that to make sure. It smells of a bug somewhere... I mean, as long as the lladdr does not change in the middle of the lease, then the router should have been able to successfully obtain a new IP address, right? It only changes when "ifconfig $_iface lladdr random" is actually called, i.e. normally just when the interface is configured at boot, unless you re-run netstart. I don't think it will be a problem of using a random lladdr in particular but more likely if the MAC address is changed at all. One area that might be implicated is the hardware address filters which need to be reprogrammed by the driver when the address is changed. Though the fact that it happens with at least ure, bse, axe makes me think that it might be some other issue. I'm still pondering the fact that you don't see incoming packets even when tcpdump is running, as (unless you used tcpdump -p) that would set the nic in promiscuous mode.. On 2021-08-03, beebeet...@posteo.de wrote: Can anyone offer some suggestions on what I can do to nail down the issue? Below are some of the observations I've made so far: - Doesn't matter whether I'm using dhclient of dhcpleased, same issue. - When it stops working, tcpdump still shows outgoing packets, checksums all OK, but no incoming packets. - `dhcpleasectl show interface ` shows that there is still one day before the lease expires. - When this first happens, `arp -a` shows that the link layer address of the gateway is still in the ARP table. But of course it will expire after some time, and the router won't be able to obtain the link layer address of the gateway again after that. - The `netstat -R` still shows the IP address of the gateway. - My ISP would offer a few short leases at first, and then offer a two day lease. This issue seems always to occur around half way of the two day lease period. - I tried several interface cards with drivers including axen, ure, axe, bse. axen dies every 10-20 min, outputing some watchdog timeout error; ure has the same issue described here, but throws some rx/tx error to dmesg in addition; bse and axe doesn't seem to output any errors, but both have the issue described here. - The issue doesn't occur when the IP address is statically assigned. - Didn't experience this problem when I was running Linux on the
Re: How to troubleshoot DHCP issues?
hopefully copying to bugs@ (if I remember how to do that correctly from slrn/gmane..) Please keep that in CC's when replying. Earlier misc@ mail copied in below to keep things together in one place. On 2021-08-06, beebeet...@posteo.de wrote: > > My first suggestion might be to stay with a single lladdr for a > > while to see if your setup works for more than a day and a half. > > Thanks for the suggestion! > It seems that with `lladdr random` removed, the problem does not > seem to disappear. On 2021-08-06, beebeet...@posteo.de wrote: > Sorry, there was a typo: The problem *does disappear* with > `lladdr random` removed . Good, so you have a workaround for now. lladdr random >>> >>> Why this line? >> >> I was wondering the same thing. What problem do you think you are >> solving by doing this? > > I try to make it harder for my ISP to gather information about the > device I'm using, thus was using random MAC address. > > > > The "random" lladdr catches my eye. But I don't know how > > frequently that changes. Could it change every time the lease > > is renewed? > > Skimming through the code for dhcpleased, looks like there's no > invocation of the SIOCSIFLLADDR ioctl, so I would assume that the > lladdr stays the same unless the netstart script is re-run (thus > invoking ifconfig to change lladdr), but I will to test that to > make sure. > > It smells of a bug somewhere... I mean, as long as the lladdr does > not change in the middle of the lease, then the router should have > been able to successfully obtain a new IP address, right? It only changes when "ifconfig $_iface lladdr random" is actually called, i.e. normally just when the interface is configured at boot, unless you re-run netstart. I don't think it will be a problem of using a random lladdr in particular but more likely if the MAC address is changed at all. One area that might be implicated is the hardware address filters which need to be reprogrammed by the driver when the address is changed. Though the fact that it happens with at least ure, bse, axe makes me think that it might be some other issue. I'm still pondering the fact that you don't see incoming packets even when tcpdump is running, as (unless you used tcpdump -p) that would set the nic in promiscuous mode.. On 2021-08-03, beebeet...@posteo.de wrote: > Can anyone offer some suggestions on what I can do to nail down > the issue? > > Below are some of the observations I've made so far: > > - Doesn't matter whether I'm using dhclient of dhcpleased, same >issue. > > - When it stops working, tcpdump still shows outgoing packets, >checksums all OK, but no incoming packets. > > - `dhcpleasectl show interface ` shows that there is still >one day before the lease expires. > > - When this first happens, `arp -a` shows that the link layer >address of the gateway is still in the ARP table. But of course >it will expire after some time, and the router won't be able to >obtain the link layer address of the gateway again after that. > > - The `netstat -R` still shows the IP address of the gateway. > > - My ISP would offer a few short leases at first, and then offer a >two day lease. This issue seems always to occur around half way >of the two day lease period. > > - I tried several interface cards with drivers including axen, ure, >axe, bse. axen dies every 10-20 min, outputing some watchdog >timeout error; ure has the same issue described here, but throws >some rx/tx error to dmesg in addition; bse and axe doesn't seem >to output any errors, but both have the issue described here. > > - The issue doesn't occur when the IP address is statically >assigned. > > - Didn't experience this problem when I was running Linux on the >same machine (raspberry pi 4B).
Re: How to troubleshoot DHCP issues?
Sorry, there was a typo: The problem *does disappear* with `lladdr random` removed . It seems that with `lladdr random` removed, the problem does not seem to disappear.
Re: How to troubleshoot DHCP issues?
> My first suggestion might be to stay with a single lladdr for a > while to see if your setup works for more than a day and a half. Thanks for the suggestion! It seems that with `lladdr random` removed, the problem does not seem to disappear. lladdr random Why this line? I was wondering the same thing. What problem do you think you are solving by doing this? I try to make it harder for my ISP to gather information about the device I'm using, thus was using random MAC address. > The "random" lladdr catches my eye. But I don't know how > frequently that changes. Could it change every time the lease > is renewed? Skimming through the code for dhcpleased, looks like there's no invocation of the SIOCSIFLLADDR ioctl, so I would assume that the lladdr stays the same unless the netstart script is re-run (thus invoking ifconfig to change lladdr), but I will to test that to make sure. It smells of a bug somewhere... I mean, as long as the lladdr does not change in the middle of the lease, then the router should have been able to successfully obtain a new IP address, right? Best Regards
Re: How to troubleshoot DHCP issues?
On Thu, Aug 5, 2021 at 6:29 AM Stuart Henderson wrote: > > On 2021-08-03, beebeet...@posteo.de wrote: > > Hi all, > > > > Me again on some DHCP-related issues... > > > > So I started using OpenBSD as my home router around two weeks ago, > > running openBSD 6.9. It obtains its IP address from the ISP via > > DHCP. The setup is pretty simple, just the following two lines in > > my hostname.if file: > > > > lladdr random > > Why this line? I was wondering the same thing. What problem do you think you are solving by doing this? Because by doing this the DHCP server thinks you are a new system so you will get a new IP address.
Re: How to troubleshoot DHCP issues?
On 2021-08-03, beebeet...@posteo.de wrote: > Hi all, > > Me again on some DHCP-related issues... > > So I started using OpenBSD as my home router around two weeks ago, > running openBSD 6.9. It obtains its IP address from the ISP via > DHCP. The setup is pretty simple, just the following two lines in > my hostname.if file: > > lladdr random Why this line?
Re: How to troubleshoot DHCP issues?
On 8/3/2021 11:57 AM, beebeet...@posteo.de wrote: > The router works fine most of the time -- except that it stops > working every one and a half day, and I have to reset the modem > for it to work again. In my experience with my ISP (Comcast in the US), I note the following: When the lladdr changes, the modem needs to be restarted in order for the new lladdr to be seen. If I don't restart the modem, I see the symptoms you document. My ISP gives out leases with a 3-day duration, so the leases renew every day and a half. The "random" lladdr catches my eye. But I don't know how frequently that changes. Could it change every time the lease is renewed? My first suggestion might be to stay with a single lladdr for a while to see if your setup works for more than a day and a half. Once (if) you have that working baseline, they start experimenting with random lladdrs.
How to troubleshoot DHCP issues?
Hi all, Me again on some DHCP-related issues... So I started using OpenBSD as my home router around two weeks ago, running openBSD 6.9. It obtains its IP address from the ISP via DHCP. The setup is pretty simple, just the following two lines in my hostname.if file: lladdr random inet autoconf The router works fine most of the time -- except that it stops working every one and a half day, and I have to reset the modem for it to work again. After doing what is in my knowledge to troubleshoot this issue, I'm still clueless as to what might be causing the problem, thus hoping to seek some help here. Can anyone offer some suggestions on what I can do to nail down the issue? Below are some of the observations I've made so far: - Doesn't matter whether I'm using dhclient of dhcpleased, same issue. - When it stops working, tcpdump still shows outgoing packets, checksums all OK, but no incoming packets. - `dhcpleasectl show interface ` shows that there is still one day before the lease expires. - When this first happens, `arp -a` shows that the link layer address of the gateway is still in the ARP table. But of course it will expire after some time, and the router won't be able to obtain the link layer address of the gateway again after that. - The `netstat -R` still shows the IP address of the gateway. - My ISP would offer a few short leases at first, and then offer a two day lease. This issue seems always to occur around half way of the two day lease period. - I tried several interface cards with drivers including axen, ure, axe, bse. axen dies every 10-20 min, outputing some watchdog timeout error; ure has the same issue described here, but throws some rx/tx error to dmesg in addition; bse and axe doesn't seem to output any errors, but both have the issue described here. - The issue doesn't occur when the IP address is statically assigned. - Didn't experience this problem when I was running Linux on the same machine (raspberry pi 4B). Best Regards
Re: dhcp issues
On 7/19/21 1:23 AM, Theo de Raadt wrote: gwes wrote: On 7/18/21 8:55 PM, Theo de Raadt wrote: Lots of excellent reasons. Is there any document available which describes your concept of how systems running OpenBSD are used? E.g. mobile laptop, home user desktop, office desktop, single local net server, multiple local servers, single gateway, multihomed gateway, server(s) to general world, etc, etc. If those aren't valid categories, could you mention what are valid ones. I'd like some idea of where your concept of the 99% vs 1% division lies. The usage case is irrelevant. We are the developers and we get to make the decisions without creating a 'document'. You overstate your position by demanding an explanation. We don't even need to be replying to these rude emails. Sorry if this came over as rude. I'm trying to get information to plan for the next couple of years. The situation is actually pretty simple: dhclient is not strongly priv-seperated, and pretty much the riskiest program people run on their machines. People have gotten addicted to it. Agreed. It's a fragile In 2016 we held a hackathon whiteboard session and come up with a rough design that would satisfy all the resolver-related security concerns. All the pieces have now been written, and we will continue the refinement in-tree. Thank you very much. That's what I needed to know. If you insist upon a document I am sure florian and I can come up with one, please contact us privately for Standard Rates. You've answered my question - thank you for taking the time. Four sentences are plenty.
Re: dhcp issues
gwes wrote: > On 7/18/21 8:55 PM, Theo de Raadt wrote: > > Lots of excellent reasons. > > > > > Is there any document available which describes your concept of how > systems running OpenBSD are used? > > E.g. mobile laptop, home user desktop, office desktop, single local > net server, multiple local servers, > single gateway, multihomed gateway, server(s) to general world, etc, etc. > If those aren't valid categories, could you mention what are valid ones. > I'd like some idea of where your concept of the 99% vs 1% division lies. The usage case is irrelevant. We are the developers and we get to make the decisions without creating a 'document'. You overstate your position by demanding an explanation. We don't even need to be replying to these rude emails. The situation is actually pretty simple: dhclient is not strongly priv-seperated, and pretty much the riskiest program people run on their machines. People have gotten addicted to it. In 2016 we held a hackathon whiteboard session and come up with a rough design that would satisfy all the resolver-related security concerns. All the pieces have now been written, and we will continue the refinement in-tree. If you insist upon a document I am sure florian and I can come up with one, please contact us privately for Standard Rates.
Re: dhcp issues
On 7/18/21 8:55 PM, Theo de Raadt wrote: Lots of excellent reasons. Is there any document available which describes your concept of how systems running OpenBSD are used? E.g. mobile laptop, home user desktop, office desktop, single local net server, multiple local servers, single gateway, multihomed gateway, server(s) to general world, etc, etc. If those aren't valid categories, could you mention what are valid ones. I'd like some idea of where your concept of the 99% vs 1% division lies. thanks very much
Re: dhcp issues
Sonic wrote:
> On Sun, Jul 18, 2021 at 3:55 PM Stuart Henderson wrote:
> >
> > The bits that can't be handled are the more per-interface things ("fetch
> > an address but ignore dns or the default route on interface X however do
> > fetch them from interface Y", or "my ISP won't give me a lease without
> > providing a client-id"). Sometimes people are just doing that because
> > they can and they could do things differently; other times it's because
> > they need to and in the current state dhcpleased isn't suitable for
> > them.
>
> I notice that dhcpleased and resolvd are started by default, is there
> any reason to run them on a system with only static interfaces?
Lots of excellent reasons.
Re: dhcp issues
On Sun, Jul 18, 2021 at 3:55 PM Stuart Henderson wrote:
>
> The bits that can't be handled are the more per-interface things ("fetch
> an address but ignore dns or the default route on interface X however do
> fetch them from interface Y", or "my ISP won't give me a lease without
> providing a client-id"). Sometimes people are just doing that because
> they can and they could do things differently; other times it's because
> they need to and in the current state dhcpleased isn't suitable for
> them.
I notice that dhcpleased and resolvd are started by default, is there
any reason to run them on a system with only static interfaces?
Re: dhcp issues
On 2021-07-17, Sonic wrote:
> On Sat, Jul 17, 2021 at 11:20 AM Theo de Raadt wrote:
>>
>> Instead, we are focusing on 99% of the use cases.
>
> I hardly think that wanting to override your ISP's name servers is
> outside of the 99% use cases. Of course it wouldn't be the first time
> I am wrong.
I agree but that can be handled either as you've done or with unwind.
(unwind might be more appealing if you think of it as an extension
to the system resolver that's in libc on OpenBSD, that can do things
requiring a bit of persistence - caching, DNSSEC, etc.
The bits that can't be handled are the more per-interface things ("fetch
an address but ignore dns or the default route on interface X however do
fetch them from interface Y", or "my ISP won't give me a lease without
providing a client-id"). Sometimes people are just doing that because
they can and they could do things differently; other times it's because
they need to and in the current state dhcpleased isn't suitable for
them.
Re: dhcp issues
On 2021-07-18, Martin wrote: > Hi, > > I confirm that dhclient don't read(apply) /etc/dhclient.conf configuration > beginning from 6.9am64 and set in /etc/resolv.conf ISP search domain and > nameserver(s) even without any complex setup in name resolution: Not sure what that's about, I don't think there's a general problem with dhclient reading dhclient.conf in 6.9, at least not one that's been reported before. The issues discussed recently are to do with resolvd+dhcpleased taking dhclient's role in -current.
Re: dhcp issues
Hi,
I confirm that dhclient don't read(apply) /etc/dhclient.conf configuration
beginning from 6.9am64 and set in /etc/resolv.conf ISP search domain and
nameserver(s) even without any complex setup in name resolution:
$ cat /etc/resolv.conf
search domain.name
nameserver ISP.nameserver
nameserver 127.0.0.1
lookup file bind
$ cat /etc/dhclient.conf
timeout 30;
retry 1;
reboot 3;
select-timeout 0;
backoff-cutoff 2;
initial-interval 1;
interface "re1" {
send dhcpd-lease-time 3600;
supersede dhcp-server-identifier 255.255.255.255;
supersede domain-name-servers 127.0.0.1;
request
subnet-mask,
broadcast-address,
routers;
require
routers,
subnet-mask;
ignore
host-name,
domain-name,
domain-search,
domain-name-servers,
interface-mtu,
ntp-servers,
time-offset;
}
/etc/dhclient.conf explicitly set to ignore "domain-search,
domain-name-servers" from ISP but actually they both in first place of
/etc/resolv.conf and update every time once IP address is assigned.
>From my observations, the behavior of ignoring /etc/dhclient.conf parameters
>by dhclient appeared since 6.8amd64 was upgraded to 6.9amd64.
Hope this helps to find the issue.
Martin
‐‐‐ Original Message ‐‐‐
On Saturday, July 17, 2021 1:57 AM, Sonic wrote:
> Having some issues after a sysupgrade to the latest snapshot (of this
> writing) - OpenBSD 6.9-current (GENERIC.MP) #131.
>
> Seems the base change to dhcpleased/resolvd has presented some issues.
> Pf does not start on boot as it claims my dhcp interface has no
> address, however after logging in I can load pf and almost resume
> normal operations. Apparently the interface does get an IP address,
> but the start of pf doesn't wait for it.
> Almost, because my supersedes, etc. in /etc/dhclient.conf are
> completely ignored.
> The only workaround I found was to disable resolvd so I could manually
> propagate /etc/resolv.conf without it being overwritten.
Re: dhcp issues
On Sat, Jul 17, 2021 at 11:20 AM Theo de Raadt wrote: > > Instead, we are focusing on 99% of the use cases. I hardly think that wanting to override your ISP's name servers is outside of the 99% use cases. Of course it wouldn't be the first time I am wrong. > You might want to look into using unwind(8) instead of unbound(8), > because resolv(8) treats it as highest priority. On Sat, Jul 17, 2021 at 5:13 PM Stuart Henderson wrote: > > The workaround I found is resolvd_flags=NO in rc.conf.local > > eliminating the prepending of the ISP nameservers. > > That's one workaround. Another is to run unwind with an explicit > configuration directing traffic to your local resolver. The more I read about unwind the more I like it but it just doesn't seem like the right option in this particular case (but sure for anything that's mobile), this being a stable firewall system and needing the features that unbound, which I've been using on many systems (both Linux and OpenBSD since before it was in base), provides. Although I don't have a static IP to the world, the DHCP assigned IP changes less than once a year, static enough for my use. The dhclient supersede worked well for years, hopefully the resolvd_flags=NO will as well. Yes, starting unwind also works, but using unwind to talk to unbound which is already running and can already be queried on it's own seems a bit overkill (a resolving DNS server to query another resolving DNS server on the same system?). Basically my unbound instance is the only DNS server useful for this firewall's tasks, so any kind of auto switching has no problem to solve. And I'm sure in the future I will need to eat these words :-) Thanks! Chris
Re: dhcp issues
On 2021-07-17, Sonic wrote: > Ah yes, my bad, had a line without the parens around the dhcp > interface reference. > This issue is resolved. > Oddly enough it never affected many previous snapshots which used > dhcpcd in place of dhcpleased. OpenBSD never had dhcpcd in base, if you had configured to use dhcpcd (which is in packages) this change wouldn't have affected you. > The issue with resolved is still a bit perplexing as if I allow it to > run it insists on prepending my ISP nameservers to the resolv.conf > file which breaks the system. > Before the change: > > # Generated by em0 dhclient > search example.com > nameserver 127.0.0.1 > lookup file bind > family inet4 > > # $OpenBSD: dhclient.conf,v 1.2 2017/10/16 23:43:41 krw Exp $ > supersede domain-name "example.com"; > supersede domain-name-servers 127.0.0.1; > request subnet-mask, broadcast-address, routers; > require subnet-mask, routers; > The only configuration option for dhcpleased is whether or not the interface has "inet autoconf" or not. It does not use dhclient.conf at all. The only configuration "option" for resolvd is that if unwind is running, it will write 127.0.0.1 to resolv.conf instead of the learned address. If you need something more than that then dhclient is still available (you will need to use e.g. "!/sbin/dhclient " in hostname.if because plain "dhcp" now enables dhcpleased instead). Or there are alternatives in packages, though if kernel ABIs change you may have no net until you can get packages updated, so I'd advise having out-of-band access if you do that on a remote machine. > After the change with dhcpleased and resolvd: > > nameserver 75.75.75.75 # resolvd: em0 > nameserver 75.75.76.76 # resolvd: em0 > # Generated by em0 dhclient > search example.com > nameserver 127.0.0.1 > lookup file bind > family inet4 > > > I run nsd and unbound on this system, unbound listens on the loopback > and on the internal interface to serve the network, it uses stub zones > to the local nsd and to a bunch of other internal network dns servers > connected via site-to-site vpn tunnels. > My ISP's nameservers have no clue about my internal systems or the > other vpn connected internal systems that I need to resolve and there > should be someway to prevent the ISP's nameservers from being force > prepended to resolv.conf as the supersedes in dhclient.conf are > apparently ignored. > The workaround I found is resolvd_flags=NO in rc.conf.local > eliminating the prepending of the ISP nameservers. That's one workaround. Another is to run unwind with an explicit configuration directing traffic to your local resolver. > If there's a more acceptable proper OpenBSD solution it would be > preferred but at this point I don't see what it is. > > Chris > >
Re: dhcp issues
Sonic wrote: > On Fri, Jul 16, 2021 at 10:35 PM Theo de Raadt wrote: > > We are moving from a model where dhclient on 1 interface believes it is > > MASTER of /etc/resolv.conf and a bunch of system aspects, and the > > userbase is familiar with a pile of hacky control knobs in > > dhclient.conf. > > > > Towards a model where multiple interfaces + unwind can advertise their > > DNS resolution abilities to resolvd, which then sorts the offers and > > maintains a configuration. > > On the surface this sounds good. > > > Anyways I'll let other people you didn't show your config to explain how > > you are probably using pf incorrectly on interfaces configured with > > dynamic addressing. > > Ah yes, my bad, had a line without the parens around the dhcp > interface reference. > This issue is resolved. > Oddly enough it never affected many previous snapshots which used > dhcpcd in place of dhcpleased. > > The issue with resolved is still a bit perplexing as if I allow it to > run it insists on prepending my ISP nameservers to the resolv.conf > file which breaks the system. It is not perplexing if you read the manual page. resolvd(8) explains what it is happening. > After the change with dhcpleased and resolvd: > > nameserver 75.75.75.75 # resolvd: em0 > nameserver 75.75.76.76 # resolvd: em0 > # Generated by em0 dhclient > search example.com > nameserver 127.0.0.1 > lookup file bind > family inet4 > > > I run nsd and unbound on this system, unbound listens on the loopback > and on the internal interface to serve the network, it uses stub zones > to the local nsd and to a bunch of other internal network dns servers > connected via site-to-site vpn tunnels. > My ISP's nameservers have no clue about my internal systems or the > other vpn connected internal systems that I need to resolve and there > should be someway to prevent the ISP's nameservers from being force > prepended to resolv.conf as the supersedes in dhclient.conf are > apparently ignored. > The workaround I found is resolvd_flags=NO in rc.conf.local > eliminating the prepending of the ISP nameservers. > If there's a more acceptable proper OpenBSD solution it would be > preferred but at this point I don't see what it is. We cannot build a mechanism which satisfies everyone's complicated setup. You've already made a pile of changes, and are not stopping you from making futher changes. Instead, we are focusing on 99% of the use cases. You might want to look into using unwind(8) instead of unbound(8), because resolv(8) treats it as highest priority.
Re: dhcp issues
On Fri, Jul 16, 2021 at 10:35 PM Theo de Raadt wrote: > We are moving from a model where dhclient on 1 interface believes it is > MASTER of /etc/resolv.conf and a bunch of system aspects, and the > userbase is familiar with a pile of hacky control knobs in > dhclient.conf. > > Towards a model where multiple interfaces + unwind can advertise their > DNS resolution abilities to resolvd, which then sorts the offers and > maintains a configuration. On the surface this sounds good. > Anyways I'll let other people you didn't show your config to explain how > you are probably using pf incorrectly on interfaces configured with > dynamic addressing. Ah yes, my bad, had a line without the parens around the dhcp interface reference. This issue is resolved. Oddly enough it never affected many previous snapshots which used dhcpcd in place of dhcpleased. The issue with resolved is still a bit perplexing as if I allow it to run it insists on prepending my ISP nameservers to the resolv.conf file which breaks the system. Before the change: # Generated by em0 dhclient search example.com nameserver 127.0.0.1 lookup file bind family inet4 # $OpenBSD: dhclient.conf,v 1.2 2017/10/16 23:43:41 krw Exp $ supersede domain-name "example.com"; supersede domain-name-servers 127.0.0.1; request subnet-mask, broadcast-address, routers; require subnet-mask, routers; After the change with dhcpleased and resolvd: nameserver 75.75.75.75 # resolvd: em0 nameserver 75.75.76.76 # resolvd: em0 # Generated by em0 dhclient search example.com nameserver 127.0.0.1 lookup file bind family inet4 I run nsd and unbound on this system, unbound listens on the loopback and on the internal interface to serve the network, it uses stub zones to the local nsd and to a bunch of other internal network dns servers connected via site-to-site vpn tunnels. My ISP's nameservers have no clue about my internal systems or the other vpn connected internal systems that I need to resolve and there should be someway to prevent the ISP's nameservers from being force prepended to resolv.conf as the supersedes in dhclient.conf are apparently ignored. The workaround I found is resolvd_flags=NO in rc.conf.local eliminating the prepending of the ISP nameservers. If there's a more acceptable proper OpenBSD solution it would be preferred but at this point I don't see what it is. Chris
Re: dhcp issues
Theo de Raadt writes: > Sonic wrote: > > > Having some issues after a sysupgrade to the latest snapshot (of this > > writing) - OpenBSD 6.9-current (GENERIC.MP) #131. > > > > Seems the base change to dhcpleased/resolvd has presented some issues. > > This is intentional. > > We are moving from a model ... > > Towards a model where ... > > dhclient will remain available ... > > Because the default configuration is changing. For what it's worth, this is why I find it helpful to subscribe to bugs@ and others even though I don't participate in the discussions there. I was trying to figure out why the dhcp/autoconf changes didn't surprise me since I couldn't see any reference to them in the upgrade/release notes. Then I remembered that I'd seen the chatter regarding it a few months back and, dhcp being a core component, researched around said chatter to see what changes I'd have to plan for. Remember OpenBSD is made by the OpenBSD developers [mostly] FOR the OpenBSD developers* and that it's given to the rest of us is largely an added bonus. It simply makes sense therefore to be privy to their discussions in order to stay most up-to-date regarding OpenBSD's progress. And sometimes, unfortunately, what the developers already know (or what's buried in documentation somewhere and thus "solved") and what the users want to be told are not the same thing. 6 months is longer than it looks. Matthew [*] This is not the whole story and I'm not speaking on OpenBSD's behalf, I'm trying to being concise.
Re: dhcp issues
On Fri, 2021-07-16 at 21:57 -0400, Sonic wrote: > Having some issues after a sysupgrade to the latest snapshot (of this > writing) - OpenBSD 6.9-current (GENERIC.MP) #131. > > Seems the base change to dhcpleased/resolvd has presented some issues. > Pf does not start on boot as it claims my dhcp interface has no > address, however after logging in I can load pf and almost resume > normal operations. Apparently the interface does get an IP address, > but the start of pf doesn't wait for it. > Almost, because my supersedes, etc. in /etc/dhclient.conf are > completely ignored. > The only workaround I found was to disable resolvd so I could manually > propagate /etc/resolv.conf without it being overwritten. > Like others said: Without enough context it can't be said with certainty. But my best guess with the current information would be that you have a domain name in one or more of your rules, which can't be resolved until you have full network connectivity. martijn@
Re: dhcp issues
On Fri, Jul 16, 2021 at 09:57:21PM -0400, Sonic wrote: > Having some issues after a sysupgrade to the latest snapshot (of this > writing) - OpenBSD 6.9-current (GENERIC.MP) #131. > > Seems the base change to dhcpleased/resolvd has presented some issues. > Pf does not start on boot as it claims my dhcp interface has no > address, however after logging in I can load pf and almost resume > normal operations. Apparently the interface does get an IP address, > but the start of pf doesn't wait for it. as deraadt@ said, without pf.conf it is hard to judge... could you share your pf.conf ? > Almost, because my supersedes, etc. in /etc/dhclient.conf are > completely ignored. which supersedes do you use ? sharing your dhclient.conf might help too. > The only workaround I found was to disable resolvd so I could manually > propagate /etc/resolv.conf without it being overwritten. resolvd doesn't override resolv.conf. it only prepends nameserver lines obtained from dhcpleased (via dhcpv4) or slaacd (via stateless ipv6). could you share your expected resolv.conf and the "overrided" one ? thanks. -- Sebastien Marie
Re: dhcp issues
Sonic wrote: > Having some issues after a sysupgrade to the latest snapshot (of this > writing) - OpenBSD 6.9-current (GENERIC.MP) #131. > > Seems the base change to dhcpleased/resolvd has presented some issues. This is intentional. We are moving from a model where dhclient on 1 interface believes it is MASTER of /etc/resolv.conf and a bunch of system aspects, and the userbase is familiar with a pile of hacky control knobs in dhclient.conf. Towards a model where multiple interfaces + unwind can advertise their DNS resolution abilities to resolvd, which then sorts the offers and maintains a configuration. dhclient will remain available for people who want that old model, but I suspect they will encounter increasing difficulty sticking to it. Because the default configuration is changing. > Pf does not start on boot as it claims my dhcp interface has no > address, however after logging in I can load pf and almost resume > normal operations. Apparently the interface does get an IP address, > but the start of pf doesn't wait for it. You didn't include any pieces of your pf.conf to show, so who can judge? Anyways I'll let other people you didn't show your config to explain how you are probably using pf incorrectly on interfaces configured with dynamic addressing. > Almost, because my supersedes, etc. in /etc/dhclient.conf are > completely ignored. Of course. > The only workaround I found was to disable resolvd so I could manually > propagate /etc/resolv.conf without it being overwritten. We take no position on what people do after they install openbsd...
dhcp issues
Having some issues after a sysupgrade to the latest snapshot (of this writing) - OpenBSD 6.9-current (GENERIC.MP) #131. Seems the base change to dhcpleased/resolvd has presented some issues. Pf does not start on boot as it claims my dhcp interface has no address, however after logging in I can load pf and almost resume normal operations. Apparently the interface does get an IP address, but the start of pf doesn't wait for it. Almost, because my supersedes, etc. in /etc/dhclient.conf are completely ignored. The only workaround I found was to disable resolvd so I could manually propagate /etc/resolv.conf without it being overwritten.
