Re: Intel 10Gb card (82598AF) on 6.9 release
Jonathan, just wanted to report the patch worked. The card is up and running. Many thanks.
Re: Intel 10Gb card (82598AF) on 6.9 release
On Fri, Jul 16, 2021 at 10:03:47PM -0400, Adam Stouffer wrote:
> On Fri, Jul 16, 2021 at 6:47 PM Jonathan Matthew wrote:
> >
> >
> > I think the problem here is that we don't check if msi is enabled
> > before deciding we can use msix. Can you try this diff out?
> > I wrote this after seeing a similar report somewhere, but I can't find
> > it now.
> >
> > Index: pci.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/pci.c,v
> > retrieving revision 1.119
> > diff -u -p -r1.119 pci.c
> > --- pci.c 8 Sep 2020 20:13:52 - 1.119
> > +++ pci.c 22 Jun 2021 02:55:50 -
> > @@ -410,16 +410,48 @@ pcisubmatch(struct device *parent, void
> > }
> >
> > int
> > +pci_device_msi_enabled(pci_chipset_tag_t pc, pcitag_t tag)
> > +{
> > + int off;
> > + pcireg_t cap;
> > + uint64_t addr;
> > +
> > + if (pci_get_ht_capability(pc, tag, PCI_HT_CAP_MSI, , )) {
> > + /*
> > +* XXX Should we enable MSI mapping ourselves on
> > +* systems that have it disabled?
> > +*/
> > + if (cap & PCI_HT_MSI_ENABLED) {
> > + if ((cap & PCI_HT_MSI_FIXED) == 0) {
> > + addr = pci_conf_read(pc, tag,
> > + off + PCI_HT_MSI_ADDR);
> > + addr |= (uint64_t)pci_conf_read(pc, tag,
> > + off + PCI_HT_MSI_ADDR_HI32) << 32;
> > + } else
> > + addr = PCI_HT_MSI_FIXED_ADDR;
> > +
> > + /*
> > +* XXX This will fail to enable MSI on systems
> > +* that don't use the canonical address.
> > +*/
> > + if (addr == PCI_HT_MSI_FIXED_ADDR)
> > + return (1);
> > + }
> > + }
> > +
> > + return (0);
> > +}
> > +
> > +int
> > pci_probe_device(struct pci_softc *sc, pcitag_t tag,
> > int (*match)(struct pci_attach_args *), struct pci_attach_args *pap)
> > {
> > pci_chipset_tag_t pc = sc->sc_pc;
> > struct pci_attach_args pa;
> > struct pci_dev *pd;
> > - pcireg_t id, class, intr, bhlcr, cap;
> > + pcireg_t id, class, intr, bhlcr;
> > int pin, bus, device, function;
> > - int off, ret = 0;
> > - uint64_t addr;
> > + int ret = 0;
> >
> > pci_decompose_tag(pc, tag, , , );
> >
> > @@ -486,28 +518,8 @@ pci_probe_device(struct pci_softc *sc, p
> > }
> > pa.pa_intrline = PCI_INTERRUPT_LINE(intr);
> >
> > - if (pci_get_ht_capability(pc, tag, PCI_HT_CAP_MSI, , )) {
> > - /*
> > -* XXX Should we enable MSI mapping ourselves on
> > -* systems that have it disabled?
> > -*/
> > - if (cap & PCI_HT_MSI_ENABLED) {
> > - if ((cap & PCI_HT_MSI_FIXED) == 0) {
> > - addr = pci_conf_read(pc, tag,
> > - off + PCI_HT_MSI_ADDR);
> > - addr |= (uint64_t)pci_conf_read(pc, tag,
> > - off + PCI_HT_MSI_ADDR_HI32) << 32;
> > - } else
> > - addr = PCI_HT_MSI_FIXED_ADDR;
> > -
> > - /*
> > -* XXX This will fail to enable MSI on systems
> > -* that don't use the canonical address.
> > -*/
> > - if (addr == PCI_HT_MSI_FIXED_ADDR)
> > - pa.pa_flags |= PCI_FLAGS_MSI_ENABLED;
> > - }
> > - }
> > + if (pci_device_msi_enabled(pc, tag))
> > + pa.pa_flags |= PCI_FLAGS_MSI_ENABLED;
> >
> > /*
> > * Give the MD code a chance to alter pci_attach_args and/or
> > @@ -1697,6 +1709,9 @@ int
> > pci_intr_msix_count(pci_chipset_tag_t pc, pcitag_t tag)
> > {
> > pcireg_t reg;
> > +
> > + if (pci_device_msi_enabled(pc, tag) == 0)
> > + return (0);
> >
> > if (pci_get_capability(pc, tag, PCI_CAP_MSIX, NULL, ) == 0)
> > return (0);
>
> Jonathan, thanks for the quick reply. I've never applied a patch
> before but don't mind giving it a shot if you'll bear with me. This
> patch would be for the -current tree, correct? So the process would be
> to get the -current source, apply the patch, then follow the steps to
> compile a new kernel?
It will also apply to 6.9, since the file it touches hasn't changed
since 6.9 was tagged.
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: /var/log/failedlogin is a binary file with a lot of null bytes?!
Philip Guenther schrieb am Samstag, 17. Juli 2021 um 11:09: > On Fri, Jul 16, 2021 at 11:49 PM podolica wrote: > >> On my OpenBSD installation (6.9) one of the log files created by login(1) >> seems to be a binary file: >> $ less /var/log/failedlogin >> "failedlogin" may be a binary file. See it anyway? > > ... > >> What can I learn from this logfile? >> A lot of repeating null bytes and "ttyC2" and "ttyC3" does not seems >> to be very informative. >> >> Is this an error? > > No, it's not an error. That file is specific to the 'login' command, > specifically the source file /usr/src/usr.bin/login/failedlogin.c and > consists of an array of the 'badlogin' structure specified there. If you want > to dump its contents in a more readable format then you should write a small > program to do so in C or some other language which can easily handle binary > files. > > Philip Guenther Thank you, that seems to be an explanation. Lerning never stops :-)
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: /var/log/failedlogin is a binary file with a lot of null bytes?!
Hi, podolica wrote on Sat, Jul 17, 2021 at 12:36:05PM +: > Philip Guenther schrieb am 17. Juli 2021 um 11:09: >> That file is specific to the 'login' command, specifically the >> source file /usr/src/usr.bin/login/failedlogin.c and consists of >> an array of the 'badlogin' structure specified there. If you want >> to dump its contents in a more readable format then you should write >> a small program to do so in C or some other language which can >> easily handle binary files. > Thank you, that seems to be an explanation. Lerning never stops :-) By the way, to help learning even more, part of what Philip explained can be guessed from the manual, even though it isn't fully spelled out. What one might do to find out is this: $ man failedlogin man: No entry for failedlogin in the manual. Hmm, that file does not have its own manual page in section 5. That means it is likely used by one single program only. But which one? $ man -k any=failedlogin login(1) - log into the computer Ah, bingo, so let's read that page! $ man login [...] If the file /var/log/failedlogin exists, login will record failed login attempts in this file. Immediately after logging a user in, login displays the system copyright notice, the date and time the user last logged in, the date and time of the last unsuccessful login (if the file /var/log/failedlogin exists), the message of the day as well as other information. [...] FILES [...] /var/log/failedlogin failed login account records Admittedly, that's the end of the documentation as far as i can see. If you wanted to know even more, you would then go read the source code of the program in question: $ which login /usr/bin/login Consequently, it likely lives in /usr/src/usr.bin/login/. Yours, Ingo
Re: Intel 10Gb card (82598AF) on 6.9 release
On Fri, Jul 16, 2021 at 6:47 PM Jonathan Matthew wrote:
>
>
> I think the problem here is that we don't check if msi is enabled
> before deciding we can use msix. Can you try this diff out?
> I wrote this after seeing a similar report somewhere, but I can't find
> it now.
>
> Index: pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/pci.c,v
> retrieving revision 1.119
> diff -u -p -r1.119 pci.c
> --- pci.c 8 Sep 2020 20:13:52 - 1.119
> +++ pci.c 22 Jun 2021 02:55:50 -
> @@ -410,16 +410,48 @@ pcisubmatch(struct device *parent, void
> }
>
> int
> +pci_device_msi_enabled(pci_chipset_tag_t pc, pcitag_t tag)
> +{
> + int off;
> + pcireg_t cap;
> + uint64_t addr;
> +
> + if (pci_get_ht_capability(pc, tag, PCI_HT_CAP_MSI, , )) {
> + /*
> +* XXX Should we enable MSI mapping ourselves on
> +* systems that have it disabled?
> +*/
> + if (cap & PCI_HT_MSI_ENABLED) {
> + if ((cap & PCI_HT_MSI_FIXED) == 0) {
> + addr = pci_conf_read(pc, tag,
> + off + PCI_HT_MSI_ADDR);
> + addr |= (uint64_t)pci_conf_read(pc, tag,
> + off + PCI_HT_MSI_ADDR_HI32) << 32;
> + } else
> + addr = PCI_HT_MSI_FIXED_ADDR;
> +
> + /*
> +* XXX This will fail to enable MSI on systems
> +* that don't use the canonical address.
> +*/
> + if (addr == PCI_HT_MSI_FIXED_ADDR)
> + return (1);
> + }
> + }
> +
> + return (0);
> +}
> +
> +int
> pci_probe_device(struct pci_softc *sc, pcitag_t tag,
> int (*match)(struct pci_attach_args *), struct pci_attach_args *pap)
> {
> pci_chipset_tag_t pc = sc->sc_pc;
> struct pci_attach_args pa;
> struct pci_dev *pd;
> - pcireg_t id, class, intr, bhlcr, cap;
> + pcireg_t id, class, intr, bhlcr;
> int pin, bus, device, function;
> - int off, ret = 0;
> - uint64_t addr;
> + int ret = 0;
>
> pci_decompose_tag(pc, tag, , , );
>
> @@ -486,28 +518,8 @@ pci_probe_device(struct pci_softc *sc, p
> }
> pa.pa_intrline = PCI_INTERRUPT_LINE(intr);
>
> - if (pci_get_ht_capability(pc, tag, PCI_HT_CAP_MSI, , )) {
> - /*
> -* XXX Should we enable MSI mapping ourselves on
> -* systems that have it disabled?
> -*/
> - if (cap & PCI_HT_MSI_ENABLED) {
> - if ((cap & PCI_HT_MSI_FIXED) == 0) {
> - addr = pci_conf_read(pc, tag,
> - off + PCI_HT_MSI_ADDR);
> - addr |= (uint64_t)pci_conf_read(pc, tag,
> - off + PCI_HT_MSI_ADDR_HI32) << 32;
> - } else
> - addr = PCI_HT_MSI_FIXED_ADDR;
> -
> - /*
> -* XXX This will fail to enable MSI on systems
> -* that don't use the canonical address.
> -*/
> - if (addr == PCI_HT_MSI_FIXED_ADDR)
> - pa.pa_flags |= PCI_FLAGS_MSI_ENABLED;
> - }
> - }
> + if (pci_device_msi_enabled(pc, tag))
> + pa.pa_flags |= PCI_FLAGS_MSI_ENABLED;
>
> /*
> * Give the MD code a chance to alter pci_attach_args and/or
> @@ -1697,6 +1709,9 @@ int
> pci_intr_msix_count(pci_chipset_tag_t pc, pcitag_t tag)
> {
> pcireg_t reg;
> +
> + if (pci_device_msi_enabled(pc, tag) == 0)
> + return (0);
>
> if (pci_get_capability(pc, tag, PCI_CAP_MSIX, NULL, ) == 0)
> return (0);
Jonathan, thanks for the quick reply. I've never applied a patch
before but don't mind giving it a shot if you'll bear with me. This
patch would be for the -current tree, correct? So the process would be
to get the -current source, apply the patch, then follow the steps to
compile a new kernel?
/var/log/failedlogin is a binary file with a lot of null bytes?!
Hi all, On my OpenBSD installation (6.9) one of the log files created by login(1) seems to be a binary file: $ less /var/log/failedlogin "failedlogin" may be a binary file. See it anyway? The hexdump of it is: openbsd# hexdump -C failedlogin 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0004c2c0 74 74 79 43 32 00 00 00 00 00 00 00 00 00 00 00 |ttyC2...| 0004c2d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0004c3e0 00 00 00 00 00 00 00 00 b2 f6 ef 60 00 00 00 00 |...`| 0004c3f0 00 00 00 00 00 00 00 00 74 74 79 43 33 00 00 00 |ttyC3...| 0004c400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0004c520 89 97 d0 60 00 00 00 00 00 00 00 00 00 00 00 00 |...`| 0004c530 What can I learn from this logfile? A lot of repeating null bytes and "ttyC2" and "ttyC3" does not seems to be very informative. Is this an error?
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: /var/log/failedlogin is a binary file with a lot of null bytes?!
On Fri, Jul 16, 2021 at 11:49 PM podolica wrote: > On my OpenBSD installation (6.9) one of the log files created by login(1) > seems to be a binary file: > $ less /var/log/failedlogin > "failedlogin" may be a binary file. See it anyway? > ... > What can I learn from this logfile? > A lot of repeating null bytes and "ttyC2" and "ttyC3" does not seems > to be very informative. > > Is this an error? > No, it's not an error. That file is specific to the 'login' command, specifically the source file /usr/src/usr.bin/login/failedlogin.c and consists of an array of the 'badlogin' structure specified there. If you want to dump its contents in a more readable format then you should write a small program to do so in C or some other language which can easily handle binary files. Philip Guenther
Re: `jq` won't chroot?
On 2021-07-17, Kent Watsen wrote: > Thanks Theo! > > >> It seems you copied libjq and libonig into usr/local/lib in the chroot. >> By default, ld.so only looks for shared objects in /usr/lib, so it can't >> find them. >> >> # env LD_LIBRARY_PATH=/usr/lib:/usr/local/lib chroot /var/www >> /usr/local/bin/jq --version >> >> should work. > > Indeed it did. Shorter: > > env LD_LIBRARY_PATH='/usr/local/lib:$LD_LIBRARY_PATH' /usr/local/bin/jq > --version > > >> Chrooting to / works because rc(8) runs ldconfig(8) to add >> /usr/local/lib and /usr/X11R6/lib if they're present. >> >> You can copy all the libraries into /var/www/usr/lib, you can set >> LD_LIBRARY_PATH=/usr/local/lib:/usr/, or you can run ldconfig in the >> chroot. >> >> Read ld.so(1) and ldconfig(8)for more details. > > Yes, setting `ldconfig -n /usr/local/lib` is a more sticky option. > > The `env` approach seems best when just one `jq` command, whereas the > `ldconfig` approach seems better when there is more than one `jq` command... Copying the various libraries to /var/www/usr/lib is pretty straightforward. Remember they might need updating, I copy them from rc.local so I don't forget.
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@
