net.pf.request_maxcount: UNDESIRABLE_OID
We've been developing an appliance/server based on FreeBSD && pf(4). We started some time ago, and have been using a very early version of 12. We're now collecting some 20,000,000 IP's /mos. So we're satisfied we're close to releasing. As such, we needed to bring the release up to a supported (freebsd) version (12-STABLE). We would have done so sooner. But we need a stable (unchanging) testbed to evaluate what we're working on. We built and deployed a copy of 12-STABLE @r363918 that contained our work with pf(4). Booting into it failed unexpectedly with: cannot define table nets: too many elements. Consider increasing net.pf.request_maxcount. pfctl: Syntax error in config file: pf rules not loaded OK this didn't happen on our testbed prior to the upgrade with a combined count of ~97,000,900 IPs. In fact the OID mentioned didn't exist. For reference; our testbed provides DNS, www, mail for ~60 domains/hosts, as well as our pf(4) testing. We can happily load our tables, and run these services w/8Gb RAM. This OID is more a problem than a savior. Why not simply return ENOMEM? Isn't that what it used to do? pf.conf(5) already facilitates thresholds, and they aren't _read only_. Is there any way to turn this OID off; like using a -1 value? Or will we need to simply back out the commit? Thanks in advance for any advice. --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: net.pf.request_maxcount: UNDESIRABLE_OID
Hi Chris, On 21 Aug 2020, at 2:40, Chris wrote: We've been developing an appliance/server based on FreeBSD && pf(4). We started some time ago, and have been using a very early version of 12. We're now collecting some 20,000,000 IP's /mos. So we're satisfied we're close to releasing. As such, we needed to bring the release up to a supported (freebsd) version (12-STABLE). We would have done so sooner. But we need a stable (unchanging) testbed to evaluate what we're working on. We built and deployed a copy of 12-STABLE @r363918 that contained our work with pf(4). Booting into it failed unexpectedly with: cannot define table nets: too many elements. Consider increasing net.pf.request_maxcount. pfctl: Syntax error in config file: pf rules not loaded OK this didn't happen on our testbed prior to the upgrade with a combined count of ~97,000,900 IPs. In fact the OID mentioned didn't exist. For reference; our testbed provides DNS, www, mail for ~60 domains/hosts, as well as our pf(4) testing. We can happily load our tables, and run these services w/8Gb RAM. This OID is more a problem than a savior. Why not simply return ENOMEM? To quote the commit message: pf ioctls frequently take a variable number of elements as argument. This can potentially allow users to request very large allocations. These will fail, but even a failing M_NOWAIT might tie up resources and result in concurrent M_WAITOK allocations entering vm_wait and inducing reclamation of caches. Limit these ioctls to what should be a reasonable value, but allow users to tune it should they need to. Now that pf can be used in vnet jails there’s a possibility of an attacker using pf to deny service to other jails (or the host) by exhausting memory. Imposing limits on pf request sizes mitigates this. Isn't that what it used to do? pf.conf(5) already facilitates thresholds, and they aren't _read only_. Is there any way to turn this OID off; like using a -1 value? Or will we need to simply back out the commit? You can functionally disable it by setting a very large value. Try setting 4294967295. Best regards, Kristof ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: net.pf.request_maxcount: UNDESIRABLE_OID
On Fri, 21 Aug 2020 08:33:16 +0200 Kristof Provost k...@freebsd.org said Hi Chris, Hello, Kristof. Thanks for the reply. Nice name BTW. ;-) On 21 Aug 2020, at 2:40, Chris wrote: > We've been developing an appliance/server based on FreeBSD && > pf(4). We started some time ago, and have been using a very > early version of 12. We're now collecting some 20,000,000 > IP's /mos. So we're satisfied we're close to releasing. As > such, we needed to bring the release up to a supported > (freebsd) version (12-STABLE). We would have done so sooner. > But we need a stable (unchanging) testbed to evaluate what > we're working on. > We built and deployed a copy of 12-STABLE @r363918 that > contained our work with pf(4). Booting into it failed > unexpectedly with: cannot define table nets: too many > elements. Consider increasing net.pf.request_maxcount. > pfctl: Syntax error in config file: pf rules not loaded > OK this didn't happen on our testbed prior to the upgrade > with a combined count of ~97,000,900 IPs. In fact the OID > mentioned didn't exist. > For reference; our testbed provides DNS, www, mail for > ~60 domains/hosts, as well as our pf(4) testing. We can > happily load our tables, and run these services w/8Gb > RAM. > This OID is more a problem than a savior. Why not simply > return ENOMEM? > To quote the commit message: pf ioctls frequently take a variable number of elements as argument. This can potentially allow users to request very large allocations. These will fail, but even a failing M_NOWAIT might tie up resources and result in concurrent M_WAITOK allocations entering vm_wait and inducing reclamation of caches. Limit these ioctls to what should be a reasonable value, but allow users to tune it should they need to. Now that pf can be used in vnet jails there’s a possibility of an attacker using pf to deny service to other jails (or the host) by exhausting memory. Imposing limits on pf request sizes mitigates this. Hadn't considered vnet. Thanks for mentioning it. But why must it be a read-only OID? > Isn't that what it used to do? pf.conf(5) > already facilitates thresholds, and they aren't _read > only_. Is there any way to turn this OID off; like using > a -1 value? Or will we need to simply back out the commit? > You can functionally disable it by setting a very large value. Try setting 4294967295. Thanks. When I was confronted with the message. I simply chose an arbitrarily high number of 8. Which allowed the tables to load. But I felt I should look closer into this for a better understanding. :-) Thank you very much for taking the time to reply! Best regards, Kristof --Chris ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: net.pf.request_maxcount: UNDESIRABLE_OID
On 21 Aug 2020, at 8:53, Chris wrote: On Fri, 21 Aug 2020 08:33:16 +0200 Kristof Provost k...@freebsd.org said Hi Chris, Hello, Kristof. Thanks for the reply. Nice name BTW. ;-) On 21 Aug 2020, at 2:40, Chris wrote: > We've been developing an appliance/server based on FreeBSD && > pf(4). We started some time ago, and have been using a very > early version of 12. We're now collecting some 20,000,000 > IP's /mos. So we're satisfied we're close to releasing. As > such, we needed to bring the release up to a supported > (freebsd) version (12-STABLE). We would have done so sooner. > But we need a stable (unchanging) testbed to evaluate what > we're working on. > We built and deployed a copy of 12-STABLE @r363918 that > contained our work with pf(4). Booting into it failed > unexpectedly with: cannot define table nets: too many > elements. Consider increasing net.pf.request_maxcount. > pfctl: Syntax error in config file: pf rules not loaded > OK this didn't happen on our testbed prior to the upgrade > with a combined count of ~97,000,900 IPs. In fact the OID > mentioned didn't exist. > For reference; our testbed provides DNS, www, mail for > ~60 domains/hosts, as well as our pf(4) testing. We can > happily load our tables, and run these services w/8Gb > RAM. > This OID is more a problem than a savior. Why not simply > return ENOMEM? > To quote the commit message: pf ioctls frequently take a variable number of elements as argument. This can potentially allow users to request very large allocations. These will fail, but even a failing M_NOWAIT might tie up resources and result in concurrent M_WAITOK allocations entering vm_wait and inducing reclamation of caches. Limit these ioctls to what should be a reasonable value, but allow users to tune it should they need to. Now that pf can be used in vnet jails there’s a possibility of an attacker using pf to deny service to other jails (or the host) by exhausting memory. Imposing limits on pf request sizes mitigates this. Hadn't considered vnet. Thanks for mentioning it. But why must it be a read-only OID? It doesn’t have to be, and in CURRENT it’s not: https://svnweb.freebsd.org/base?view=revision&revision=355744 That hasn’t been MFC’d for the excellent reason that I forgot. I’ll try to do that today, after I fix my dev-VM. Best regards, Kristof ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
