nsd 4.7.0
tests, OKs?
diff --git Makefile.bsd-wrapper Makefile.bsd-wrapper
index f5042fc31b4..72ad47b382f 100644
--- Makefile.bsd-wrapper
+++ Makefile.bsd-wrapper
@@ -21,8 +21,7 @@ CONFIGURE_OPTS= --prefix=/usr \
--with-xfrdir=${CHROOTDIR}/run/xfr \
--with-xfrdfile=${CHROOTDIR}/run/xfrd.state \
--with-libevent=/usr \
- --enable-ratelimit \
- --enable-root-server
+ --enable-ratelimit
PROG= nsd nsd-checkconf nsd-checkzone nsd-control
diff --git Makefile.in Makefile.in
index 96d0784f610..9b6c8b593a7 100644
--- Makefile.in
+++ Makefile.in
@@ -356,6 +356,15 @@ configlexer.c: $(srcdir)/configlexer.lex
configparser.c configparser.h: $(srcdir)/configparser.y
$(YACC) -d -p c_ -o configparser.c $(srcdir)/configparser.y
+# for build to run flex and bison before compiling code that needs the headers
+configlexer.o: configlexer.c config.h configparser.h
+configparser.o: configparser.c config.h configparser.h
+options.o: $(srcdir)/options.c config.h configparser.h
+zlexer.o: zlexer.c config.h zparser.h
+zparser.o: zparser.c config.h zparser.h
+dns.o: $(srcdir)/dns.c config.h zparser.h
+zonec.o: $(srcdir)/zonec.c config.h zparser.h
+
# dnstap
dnstap.o: $(srcdir)/dnstap/dnstap.c config.h dnstap/dnstap_config.h \
dnstap/dnstap.pb-c.c dnstap/dnstap.pb-c.h $(srcdir)/dnstap/dnstap.h \
@@ -367,7 +376,7 @@ dnstap_collector.o: $(srcdir)/dnstap/dnstap_collector.c
config.h \
$(srcdir)/util.h $(srcdir)/nsd.h $(srcdir)/region-allocator.h \
$(srcdir)/buffer.h $(srcdir)/namedb.h $(srcdir)/dname.h \
$(srcdir)/dns.h $(srcdir)/radtree.h $(srcdir)/rbtree.h \
- $(srcdir)/options.h
+ $(srcdir)/options.h $(srcdir)/remote.h
dnstap/dnstap.pb-c.c dnstap/dnstap.pb-c.h: $(srcdir)/dnstap/dnstap.proto
@-if test ! -d dnstap; then $(INSTALL) -d dnstap; fi
$(PROTOC_C) --c_out=. --proto_path=$(srcdir)
$(srcdir)/dnstap/dnstap.proto
@@ -414,134 +423,159 @@ depend:
rm -f $(DEPEND_TMP) $(DEPEND_TMP2)
# Dependencies
-answer.o: $(srcdir)/answer.c config.h $(srcdir)/answer.h $(srcdir)/dns.h
$(srcdir)/namedb.h $(srcdir)/dname.h $(srcdir)/buffer.h \
- $(srcdir)/region-allocator.h $(srcdir)/util.h $(srcdir)/radtree.h
$(srcdir)/rbtree.h $(srcdir)/packet.h $(srcdir)/query.h $(srcdir)/nsd.h \
- $(srcdir)/edns.h $(srcdir)/tsig.h
-ixfr.o: $(srcdir)/ixfr.c config.h $(srcdir)/ixfr.h $(srcdir)/query.h
$(srcdir)/packet.h $(srcdir)/rdata.h $(srcdir)/axfr.h $(srcdir)/options.h
$(srcdir)/rbtree.h $(srcdir)/zonec.h $(srcdir)/namedb.h $(srcdir)/nsd.h
$(srcdir)/tsig.h $(srcdir)/dns.h $(srcdir)/region-allocator.h $(srcdir)/dname.h
$(srcdir)/radtree.h $(srcdir)/edns.h $(srcdir)/bitset.h $(srcdir)/buffer.h
$(srcdir)/util.h
-ixfrcreate.o: $(srcdir)/ixfrcreate.c config.h $(srcdir)/ixfrcreate.h
$(srcdir)/namedb.h $(srcdir)/ixfr.h $(srcdir)/options.h $(srcdir)/dname.h
$(srcdir)/dns.h $(srcdir)/radtree.h $(srcdir)/rbtree.h
$(srcdir)/region-allocator.h $(srcdir)/buffer.h $(srcdir)/util.h
-axfr.o: $(srcdir)/axfr.c config.h $(srcdir)/axfr.h $(srcdir)/nsd.h
$(srcdir)/dns.h $(srcdir)/edns.h $(srcdir)/buffer.h \
- $(srcdir)/region-allocator.h $(srcdir)/util.h $(srcdir)/query.h
$(srcdir)/namedb.h $(srcdir)/dname.h $(srcdir)/radtree.h $(srcdir)/rbtree.h \
- $(srcdir)/packet.h $(srcdir)/tsig.h $(srcdir)/options.h $(srcdir)/ixfr.h
-buffer.o: $(srcdir)/buffer.c config.h $(srcdir)/buffer.h
$(srcdir)/region-allocator.h $(srcdir)/util.h
+answer.o: $(srcdir)/answer.c config.h $(srcdir)/answer.h $(srcdir)/dns.h
$(srcdir)/namedb.h \
+ $(srcdir)/dname.h $(srcdir)/buffer.h $(srcdir)/region-allocator.h
$(srcdir)/util.h $(srcdir)/radtree.h $(srcdir)/rbtree.h $(srcdir)/packet.h \
+ $(srcdir)/query.h $(srcdir)/nsd.h $(srcdir)/edns.h $(srcdir)/bitset.h
$(srcdir)/tsig.h
+axfr.o: $(srcdir)/axfr.c config.h $(srcdir)/axfr.h $(srcdir)/nsd.h
$(srcdir)/dns.h $(srcdir)/edns.h \
+ $(srcdir)/buffer.h $(srcdir)/region-allocator.h $(srcdir)/util.h
$(srcdir)/bitset.h $(srcdir)/query.h $(srcdir)/namedb.h $(srcdir)/dname.h \
+ $(srcdir)/radtree.h $(srcdir)/rbtree.h $(srcdir)/packet.h $(srcdir)/tsig.h
$(srcdir)/options.h $(srcdir)/ixfr.h
+bitset.o: $(srcdir)/bitset.c config.h $(srcdir)/bitset.h
+buffer.o: $(srcdir)/buffer.c config.h $(srcdir)/buffer.h
$(srcdir)/region-allocator.h \
+ $(srcdir)/util.h
configlexer.o: configlexer.c config.h $(srcdir)/options.h \
$(srcdir)/region-allocator.h $(srcdir)/rbtree.h configparser.h
-configparser.o: configparser.c config.h $(srcdir)/options.h
$(srcdir)/region-allocator.h \
- $(srcdir)/rbtree.h $(srcdir)/util.h $(srcdir)/dname.h $(srcdir)/buffer.h
$(srcdir)/tsig.h $(srcdir)/rrl.h $(srcdir)/query.h $(srcdir)/namedb.h
$(srcdir)/dns.h \
- $(srcdir)/radtree.h $(srcdir)/nsd.h $(srcdir)/edns.h $(srcdir)/packet.h
-dbaccess.o: $(srcdir)/dbaccess.c config.h $(srcdir)/dns.h $(srcdir)/namedb.h
$(srcdir)/dname.h $(srcdir)/buffer.h \
- $(srcdir)/region-allocator.h $(srcdir)/util.h
rpki-client: make ASPA AFI-agnostic
Dear all,
To simplify the concept of RPKI ASPAs, the sidrops@ group came to
consensus on removing the notion of 'afiLimit'. This means that going
forward, ASPA will be AFI-agnostic.
Advantages to operators are that by creating just one ASPA they'll be
prepared for a IPv4+IPv6 dual-stack future (no need to update the ASPA
when IPv6 BGP sessions are added at a later point in time), and for BGP
implementers the cachability of the AS_PATH attribute is restored to its
former glory.
New ASPA profile definition is pending review here:
https://github.com/QratorLabs/ASPA/pull/15/files
A test object reachable via RIPE NCC TAL is available here:
rsync://chloe.sobornost.net/rpki/RIPE-nljobsnijders/5m80fwYws_3FiFD7JiQjAqZ1RYQ.asa
Feedback?
Kind regards,
Job
Index: aspa.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/aspa.c,v
retrieving revision 1.18
diff -u -p -r1.18 aspa.c
--- aspa.c 7 Jun 2023 10:46:34 - 1.18
+++ aspa.c 7 Jun 2023 12:15:08 -
@@ -47,32 +47,15 @@ extern ASN1_OBJECT *aspa_oid;
*/
typedef struct {
- ASN1_INTEGER*providerASID;
- ASN1_OCTET_STRING *afiLimit;
-} ProviderAS;
-
-DECLARE_STACK_OF(ProviderAS);
-
-#ifndef DEFINE_STACK_OF
-#define sk_ProviderAS_num(sk) SKM_sk_num(ProviderAS, (sk))
-#define sk_ProviderAS_value(sk, i) SKM_sk_value(ProviderAS, (sk), (i))
-#endif
-
-ASN1_SEQUENCE(ProviderAS) = {
- ASN1_SIMPLE(ProviderAS, providerASID, ASN1_INTEGER),
- ASN1_OPT(ProviderAS, afiLimit, ASN1_OCTET_STRING),
-} ASN1_SEQUENCE_END(ProviderAS);
-
-typedef struct {
ASN1_INTEGER*version;
ASN1_INTEGER*customerASID;
- STACK_OF(ProviderAS)*providers;
+ STACK_OF(ASN1_INTEGER) *providers;
} ASProviderAttestation;
ASN1_SEQUENCE(ASProviderAttestation) = {
ASN1_EXP_OPT(ASProviderAttestation, version, ASN1_INTEGER, 0),
ASN1_SIMPLE(ASProviderAttestation, customerASID, ASN1_INTEGER),
- ASN1_SEQUENCE_OF(ASProviderAttestation, providers, ProviderAS),
+ ASN1_SEQUENCE_OF(ASProviderAttestation, providers, ASN1_INTEGER),
} ASN1_SEQUENCE_END(ASProviderAttestation);
DECLARE_ASN1_FUNCTIONS(ASProviderAttestation);
@@ -83,13 +66,13 @@ IMPLEMENT_ASN1_FUNCTIONS(ASProviderAttes
* Return zero on failure, non-zero on success.
*/
static int
-aspa_parse_providers(struct parse *p, const STACK_OF(ProviderAS) *providers)
+aspa_parse_providers(struct parse *p, const STACK_OF(ASN1_INTEGER) *providers)
{
- ProviderAS *pa;
- struct aspa_provider provider;
+ const ASN1_INTEGER *pa;
+ uint32_t provider;
size_t providersz, i;
- if ((providersz = sk_ProviderAS_num(providers)) == 0) {
+ if ((providersz = sk_ASN1_INTEGER_num(providers)) == 0) {
warnx("%s: ASPA: ProviderASSet needs at least one entry",
p->fn);
return 0;
@@ -106,39 +89,33 @@ aspa_parse_providers(struct parse *p, co
err(1, NULL);
for (i = 0; i < providersz; i++) {
- pa = sk_ProviderAS_value(providers, i);
+ pa = sk_ASN1_INTEGER_value(providers, i);
memset(, 0, sizeof(provider));
- if (!as_id_parse(pa->providerASID, )) {
+ if (!as_id_parse(pa, )) {
warnx("%s: ASPA: malformed ProviderAS", p->fn);
return 0;
}
- if (p->res->custasid == provider.as) {
+ if (p->res->custasid == provider) {
warnx("%s: ASPA: CustomerASID can't also be Provider",
p->fn);
return 0;
}
if (i > 0) {
- if (p->res->providers[i - 1].as > provider.as) {
+ if (p->res->providers[i - 1] > provider) {
warnx("%s: ASPA: invalid ProviderASSet order",
p->fn);
return 0;
}
- if (p->res->providers[i - 1].as == provider.as) {
+ if (p->res->providers[i - 1] == provider) {
warnx("%s: ASPA: duplicate ProviderAS", p->fn);
return 0;
}
}
- if (pa->afiLimit != NULL && !ip_addr_afi_parse(p->fn,
- pa->afiLimit, )) {
- warnx("%s: ASPA: invalid afiLimit", p->fn);
- return 0;
- }
-
p->res->providers[p->res->providersz++] = provider;
}
@@ -161,7 +138,7 @@ aspa_parse_econtent(const unsigned char
goto out;
}
- if (!valid_econtent_version(p->fn, aspa->version, 0))
+ if
Re: ifconfig rename tcplro
On Wed, Jun 07, 2023 at 02:49:07PM +0300, Vitaliy Makkoveev wrote: > On Wed, Jun 07, 2023 at 01:29:09PM +0200, Alexander Bluhm wrote: > > On Wed, Jun 07, 2023 at 12:59:11PM +0300, Vitaliy Makkoveev wrote: > > > On Wed, Jun 07, 2023 at 10:19:32AM +1000, David Gwynne wrote: > > > > > > > > > > > > > On 7 Jun 2023, at 06:33, Vitaliy Makkoveev wrote: > > > > > > > > > >> On 6 Jun 2023, at 20:29, Alexander Bluhm > > > > >> wrote: > > > > >> > > > > >> On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote: > > > > >>> On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote: > > > > Hi, > > > > > > > > I would suggest to rename ifconfig tcprecvoffload to tcplro. Maybe > > > > it's just because I had to type that long name too often. > > > > > > > > With that we have consistent naming: > > > > # ifconfig ix0 tcplro > > > > # sysctl net.inet.tcp.tso=1 > > > > > > > > Also the coresponding flag are named LRO. > > > > # ifconfig ix1 hwfeatures > > > > ix1: flags=2008843 mtu > > > > 1500 > > > > > > > > hwfeatures=71b7 > > > > hardmtu 9198 > > > > > > > > The feature is quite new, so I have no backward compatiblity > > > > concerns. > > > > > > > > ok? > > > > > > > > >>> > > > > >>> Could you name it "lro" like FreeBSD uses? > > > > >> > > > > >> When I started with this, LRO and TSO were unknown to me. So with > > > > >> TCP prefix it may be clearer to users where the feature belongs. > > > > >> > > > > >> Naming is hard. > > > > > > > > > > Yeah, naming is definitely hard. I propose to use lro because it is > > > > > already used for the same purpose by FreeBSD, so the same name helps > > > > > to avoid confusion. > > > > > > > > > >lro If the driver supports tcp(4) large receive offloading, > > > > >enable LRO on the interface. > > > > > > > > > > Also, we have used "tso" keyword for tcp segmentation offloading for > > > > > the same reason, until it became global net.inet.tcp.tso. > > > > > > > > Is it going to be used to enable lro for udp and other protocols as > > > > well? > > > > > > Why not? We have tso feature system wide, so why don't have receive > > > offloading feature global for all supported protocols? Especially since > > > I suspect this control will be moved from ifconfig to global > > > net.inet.tcp.lro like net.inet.tcp.tso. > > > > Maybe we can make lro the default, and then move it to net.inet.tcp.lro. > > But I like to see another driver to implement it first. > > > > > However, I'm not the fan of original "tcprecvoffload" and like shorter > > > naming. > > > > Can we use ifconfig tcplro for now? > > + it only affects TCP > > + user see that it is related to TCP > > + it is not a 3 letter abrevation claudio does not like > > + it is shorter than tcprecvoffload > > > > cons > > - FreeBSD calls it lro > > > > Feel free to use tcplro. Do so. OK jan@
Re: ifconfig rename tcplro
On Wed, Jun 07, 2023 at 01:29:09PM +0200, Alexander Bluhm wrote: > On Wed, Jun 07, 2023 at 12:59:11PM +0300, Vitaliy Makkoveev wrote: > > On Wed, Jun 07, 2023 at 10:19:32AM +1000, David Gwynne wrote: > > > > > > > > > > On 7 Jun 2023, at 06:33, Vitaliy Makkoveev wrote: > > > > > > > >> On 6 Jun 2023, at 20:29, Alexander Bluhm > > > >> wrote: > > > >> > > > >> On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote: > > > >>> On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote: > > > Hi, > > > > > > I would suggest to rename ifconfig tcprecvoffload to tcplro. Maybe > > > it's just because I had to type that long name too often. > > > > > > With that we have consistent naming: > > > # ifconfig ix0 tcplro > > > # sysctl net.inet.tcp.tso=1 > > > > > > Also the coresponding flag are named LRO. > > > # ifconfig ix1 hwfeatures > > > ix1: flags=2008843 mtu > > > 1500 > > > > > > hwfeatures=71b7 > > > hardmtu 9198 > > > > > > The feature is quite new, so I have no backward compatiblity > > > concerns. > > > > > > ok? > > > > > > >>> > > > >>> Could you name it "lro" like FreeBSD uses? > > > >> > > > >> When I started with this, LRO and TSO were unknown to me. So with > > > >> TCP prefix it may be clearer to users where the feature belongs. > > > >> > > > >> Naming is hard. > > > > > > > > Yeah, naming is definitely hard. I propose to use lro because it is > > > > already used for the same purpose by FreeBSD, so the same name helps > > > > to avoid confusion. > > > > > > > >lro If the driver supports tcp(4) large receive offloading, > > > >enable LRO on the interface. > > > > > > > > Also, we have used "tso" keyword for tcp segmentation offloading for > > > > the same reason, until it became global net.inet.tcp.tso. > > > > > > Is it going to be used to enable lro for udp and other protocols as well? > > > > Why not? We have tso feature system wide, so why don't have receive > > offloading feature global for all supported protocols? Especially since > > I suspect this control will be moved from ifconfig to global > > net.inet.tcp.lro like net.inet.tcp.tso. > > Maybe we can make lro the default, and then move it to net.inet.tcp.lro. > But I like to see another driver to implement it first. > > > However, I'm not the fan of original "tcprecvoffload" and like shorter > > naming. > > Can we use ifconfig tcplro for now? > + it only affects TCP > + user see that it is related to TCP > + it is not a 3 letter abrevation claudio does not like > + it is shorter than tcprecvoffload > > cons > - FreeBSD calls it lro > Feel free to use tcplro.
Re: ifconfig rename tcplro
On Wed, Jun 07, 2023 at 12:59:11PM +0300, Vitaliy Makkoveev wrote: > On Wed, Jun 07, 2023 at 10:19:32AM +1000, David Gwynne wrote: > > > > > > > On 7 Jun 2023, at 06:33, Vitaliy Makkoveev wrote: > > > > > >> On 6 Jun 2023, at 20:29, Alexander Bluhm wrote: > > >> > > >> On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote: > > >>> On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote: > > Hi, > > > > I would suggest to rename ifconfig tcprecvoffload to tcplro. Maybe > > it's just because I had to type that long name too often. > > > > With that we have consistent naming: > > # ifconfig ix0 tcplro > > # sysctl net.inet.tcp.tso=1 > > > > Also the coresponding flag are named LRO. > > # ifconfig ix1 hwfeatures > > ix1: flags=2008843 mtu 1500 > > > > hwfeatures=71b7 > > hardmtu 9198 > > > > The feature is quite new, so I have no backward compatiblity concerns. > > > > ok? > > > > >>> > > >>> Could you name it "lro" like FreeBSD uses? > > >> > > >> When I started with this, LRO and TSO were unknown to me. So with > > >> TCP prefix it may be clearer to users where the feature belongs. > > >> > > >> Naming is hard. > > > > > > Yeah, naming is definitely hard. I propose to use lro because it is > > > already used for the same purpose by FreeBSD, so the same name helps > > > to avoid confusion. > > > > > >lro If the driver supports tcp(4) large receive offloading, > > >enable LRO on the interface. > > > > > > Also, we have used "tso" keyword for tcp segmentation offloading for > > > the same reason, until it became global net.inet.tcp.tso. > > > > Is it going to be used to enable lro for udp and other protocols as well? > > Why not? We have tso feature system wide, so why don't have receive > offloading feature global for all supported protocols? Especially since > I suspect this control will be moved from ifconfig to global > net.inet.tcp.lro like net.inet.tcp.tso. Maybe we can make lro the default, and then move it to net.inet.tcp.lro. But I like to see another driver to implement it first. > However, I'm not the fan of original "tcprecvoffload" and like shorter > naming. Can we use ifconfig tcplro for now? + it only affects TCP + user see that it is related to TCP + it is not a 3 letter abrevation claudio does not like + it is shorter than tcprecvoffload cons - FreeBSD calls it lro bluhm
Re: rpki-client: adjust eContent version handling
On Wed, Jun 07, 2023 at 10:10:10AM +, Job Snijders wrote: > In anticipation of a bump of the ASPA eContent profile version, update > valid_econtent_version() to allow for non-zero versions. Given that you want to make a hard break without grace period this looks like the way to go. We can add more complex^Wflexibility when needed. ok tb Maybe the error could say "unexpected version" instead of "invalid version" but that's just bikeshedding.
Kill if_detached_ioctl()
In this point the interface is already removed from the list of all
interfaces and from the interface index map and all possible
concurrent ioctl() threads finished. Remove this dead code.
Index: sys/net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.699
diff -u -p -r1.699 if.c
--- sys/net/if.c5 Jun 2023 11:35:46 - 1.699
+++ sys/net/if.c7 Jun 2023 10:22:36 -
@@ -145,7 +145,6 @@ int if_setrdomain(struct ifnet *, int);
void if_slowtimo(void *);
void if_detached_qstart(struct ifqueue *);
-intif_detached_ioctl(struct ifnet *, u_long, caddr_t);
intifioctl_get(u_long, caddr_t);
intifconf(caddr_t);
@@ -1128,7 +1127,6 @@ if_detach(struct ifnet *ifp)
NET_LOCK();
s = splnet();
- ifp->if_ioctl = if_detached_ioctl;
ifp->if_watchdog = NULL;
/* Remove the watchdog timeout & task */
@@ -2761,19 +2759,13 @@ if_getdata(struct ifnet *ifp, struct if_
}
/*
- * Dummy functions replaced in ifnet during detach (if protocols decide to
+ * Dummy function replaced in ifnet during detach (if protocols decide to
* fiddle with the if during detach.
*/
void
if_detached_qstart(struct ifqueue *ifq)
{
ifq_purge(ifq);
-}
-
-int
-if_detached_ioctl(struct ifnet *ifp, u_long a, caddr_t b)
-{
- return ENODEV;
}
/*
if_detach(): move nd6_ifdetach() out of netlock
In this point, the interface is disconnected from everywhere. No need to hold netlock for dummy 'nd_ifinfo' release. Netlock is also not needed for TAILQ_EMPTY(>if_*hooks) assertions. Index: sys/net/if.c === RCS file: /cvs/src/sys/net/if.c,v retrieving revision 1.699 diff -u -p -r1.699 if.c --- sys/net/if.c5 Jun 2023 11:35:46 - 1.699 +++ sys/net/if.c7 Jun 2023 10:15:12 - @@ -1170,6 +1170,8 @@ if_detach(struct ifnet *ifp) ifafree(ifa); } } + splx(s); + NET_UNLOCK(); KASSERT(TAILQ_EMPTY(>if_addrhooks)); KASSERT(TAILQ_EMPTY(>if_linkstatehooks)); @@ -1178,8 +1180,6 @@ if_detach(struct ifnet *ifp) #ifdef INET6 nd6_ifdetach(ifp); #endif - splx(s); - NET_UNLOCK(); /* Announce that the interface is gone. */ rtm_ifannounce(ifp, IFAN_DEPARTURE);
rpki-client: adjust eContent version handling
In anticipation of a bump of the ASPA eContent profile version, update
valid_econtent_version() to allow for non-zero versions.
OK?
Kind regards,
Job
Index: aspa.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/aspa.c,v
retrieving revision 1.17
diff -u -p -r1.17 aspa.c
--- aspa.c 26 Apr 2023 16:32:41 - 1.17
+++ aspa.c 7 Jun 2023 10:08:13 -
@@ -161,7 +161,7 @@ aspa_parse_econtent(const unsigned char
goto out;
}
- if (!valid_econtent_version(p->fn, aspa->version))
+ if (!valid_econtent_version(p->fn, aspa->version, 0))
goto out;
if (!as_id_parse(aspa->customerASID, >res->custasid)) {
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.183
diff -u -p -r1.183 extern.h
--- extern.h30 May 2023 16:02:28 - 1.183
+++ extern.h7 Jun 2023 10:08:13 -
@@ -690,7 +690,8 @@ int valid_origin(const char *, const c
int valid_x509(char *, X509_STORE_CTX *, X509 *, struct auth *,
struct crl *, const char **);
int valid_rsc(const char *, struct cert *, struct rsc *);
-int valid_econtent_version(const char *, const ASN1_INTEGER *);
+int valid_econtent_version(const char *, const ASN1_INTEGER *,
+ uint64_t);
int valid_aspa(const char *, struct cert *, struct aspa *);
int valid_geofeed(const char *, struct cert *, struct geofeed *);
int valid_uuid(const char *);
Index: mft.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/mft.c,v
retrieving revision 1.93
diff -u -p -r1.93 mft.c
--- mft.c 22 May 2023 15:15:25 - 1.93
+++ mft.c 7 Jun 2023 10:08:13 -
@@ -286,7 +286,7 @@ mft_parse_econtent(const unsigned char *
goto out;
}
- if (!valid_econtent_version(p->fn, mft->version))
+ if (!valid_econtent_version(p->fn, mft->version, 0))
goto out;
p->res->seqnum = x509_convert_seqnum(p->fn, mft->manifestNumber);
Index: roa.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/roa.c,v
retrieving revision 1.67
diff -u -p -r1.67 roa.c
--- roa.c 23 May 2023 06:42:08 - 1.67
+++ roa.c 7 Jun 2023 10:08:13 -
@@ -119,7 +119,7 @@ roa_parse_econtent(const unsigned char *
goto out;
}
- if (!valid_econtent_version(p->fn, roa->version))
+ if (!valid_econtent_version(p->fn, roa->version, 0))
goto out;
if (!as_id_parse(roa->asid, >res->asid)) {
Index: rsc.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/rsc.c,v
retrieving revision 1.25
diff -u -p -r1.25 rsc.c
--- rsc.c 12 Mar 2023 13:31:39 - 1.25
+++ rsc.c 7 Jun 2023 10:08:13 -
@@ -339,7 +339,7 @@ rsc_parse_econtent(const unsigned char *
goto out;
}
- if (!valid_econtent_version(p->fn, rsc->version))
+ if (!valid_econtent_version(p->fn, rsc->version, 0))
goto out;
resources = rsc->resources;
Index: tak.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/tak.c,v
retrieving revision 1.8
diff -u -p -r1.8 tak.c
--- tak.c 12 Mar 2023 11:46:35 - 1.8
+++ tak.c 7 Jun 2023 10:08:13 -
@@ -195,7 +195,7 @@ tak_parse_econtent(const unsigned char *
goto out;
}
- if (!valid_econtent_version(fn, tak->version))
+ if (!valid_econtent_version(fn, tak->version, 0))
goto out;
p->res->current = parse_takey(fn, tak->current);
Index: validate.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/validate.c,v
retrieving revision 1.63
diff -u -p -r1.63 validate.c
--- validate.c 30 May 2023 12:14:48 - 1.63
+++ validate.c 7 Jun 2023 10:08:13 -
@@ -514,11 +514,12 @@ valid_rsc(const char *fn, struct cert *c
}
int
-valid_econtent_version(const char *fn, const ASN1_INTEGER *aint)
+valid_econtent_version(const char *fn, const ASN1_INTEGER *aint,
+uint64_t expected)
{
uint64_t version;
- if (aint == NULL)
+ if (expected == 0 && aint == NULL)
return 1;
if (!ASN1_INTEGER_get_uint64(, aint)) {
@@ -526,15 +527,18 @@ valid_econtent_version(const char *fn, c
return 0;
}
- switch (version) {
- case 0:
+ if (version == 0) {
warnx("%s: incorrect encoding for version 0", fn);
return 0;
- default:
- warnx("%s: version %llu not supported (yet)", fn,
Re: ifconfig rename tcplro
On Wed, Jun 07, 2023 at 10:19:32AM +1000, David Gwynne wrote: > > > > On 7 Jun 2023, at 06:33, Vitaliy Makkoveev wrote: > > > >> On 6 Jun 2023, at 20:29, Alexander Bluhm wrote: > >> > >> On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote: > >>> On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote: > Hi, > > I would suggest to rename ifconfig tcprecvoffload to tcplro. Maybe > it's just because I had to type that long name too often. > > With that we have consistent naming: > # ifconfig ix0 tcplro > # sysctl net.inet.tcp.tso=1 > > Also the coresponding flag are named LRO. > # ifconfig ix1 hwfeatures > ix1: flags=2008843 mtu 1500 > > hwfeatures=71b7 > hardmtu 9198 > > The feature is quite new, so I have no backward compatiblity concerns. > > ok? > > >>> > >>> Could you name it "lro" like FreeBSD uses? > >> > >> When I started with this, LRO and TSO were unknown to me. So with > >> TCP prefix it may be clearer to users where the feature belongs. > >> > >> Naming is hard. > > > > Yeah, naming is definitely hard. I propose to use lro because it is > > already used for the same purpose by FreeBSD, so the same name helps > > to avoid confusion. > > > >lro If the driver supports tcp(4) large receive offloading, > >enable LRO on the interface. > > > > Also, we have used "tso" keyword for tcp segmentation offloading for > > the same reason, until it became global net.inet.tcp.tso. > > Is it going to be used to enable lro for udp and other protocols as well? Why not? We have tso feature system wide, so why don't have receive offloading feature global for all supported protocols? Especially since I suspect this control will be moved from ifconfig to global net.inet.tcp.lro like net.inet.tcp.tso. However, I'm not the fan of original "tcprecvoffload" and like shorter naming.
fix for /etc/daily dump report
Hello, I'm trying to find, why I'm getting notice from daily to backup filesystems, which I just dumped. Before getting to source of "dump w", I realised, that in daily, the grep removing of "Dump these file systems:" not work, so there are two these two lines in daily output: Filesystems which need to be dumped: Dump these file systems: This patch will remove the second line: cvs diff -uNp daily Index: daily === RCS file: /cvs/src/etc/daily,v retrieving revision 1.97 diff -u -p -u -p -r1.97 daily --- daily 3 Mar 2023 16:22:57 - 1.97 +++ daily 7 Jun 2023 07:03:04 - @@ -137,7 +137,7 @@ next_part "Services that should be runni rcctl ls failed next_part "Filesystems which need to be dumped:" -dump w | grep -vB1 ^Dump +dump w | grep -v ^Dump next_part "Running calendar in the background:" if [ "X$CALENDAR" != X0 -a \ BR, Jiri
Re: ifconfig rename tcplro
On Tue, Jun 06, 2023 at 11:40:58PM +0200, Alexander Bluhm wrote: > On Tue, Jun 06, 2023 at 11:33:36PM +0300, Vitaliy Makkoveev wrote: > > > On 6 Jun 2023, at 20:29, Alexander Bluhm wrote: > > > > > > On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote: > > >> On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote: > > >>> Hi, > > >>> > > >>> I would suggest to rename ifconfig tcprecvoffload to tcplro. Maybe > > >>> it's just because I had to type that long name too often. > > >>> > > >>> With that we have consistent naming: > > >>> # ifconfig ix0 tcplro > > >>> # sysctl net.inet.tcp.tso=1 > > >>> > > >>> Also the coresponding flag are named LRO. > > >>> # ifconfig ix1 hwfeatures > > >>> ix1: flags=2008843 mtu 1500 > > >>> > > >>> hwfeatures=71b7 > > >>> hardmtu 9198 > > >>> > > >>> The feature is quite new, so I have no backward compatiblity concerns. > > >>> > > >>> ok? > > >>> > > >> > > >> Could you name it "lro" like FreeBSD uses? > > > > > > When I started with this, LRO and TSO were unknown to me. So with > > > TCP prefix it may be clearer to users where the feature belongs. > > > > > > Naming is hard. > > > > Yeah, naming is definitely hard. I propose to use lro because it is > > already used for the same purpose by FreeBSD, so the same name helps > > to avoid confusion. > > > > lro If the driver supports tcp(4) large receive offloading, > > enable LRO on the interface. > > > > Also, we have used "tso" keyword for tcp segmentation offloading for > > the same reason, until it became global net.inet.tcp.tso. > > In sysctl we have tso in tcp namespace. That's why I wanted tcplro. > And claudio@ asked for a longer name. Let's see if he has an > opinion. I'm fine with whatever is chosen. I don't like the three letter acronyms used mainly since there are so many. There is LRO, TSO, GSO, UFO, GRO, and many more. I prefer to have an option for HW assisted receive offloading and (if necessary) another for HW assisted send offloading. Send offloading should be implemented in an interface agnostic way like we did for TSO by adding the tcp_chopper. It will benefit also interfaces that don't really support this in HW. Having a button for each and every option does not really fit OpenBSD's philosophy but there is a need to control recieve offload features because they don't work in some network scenarios (e.g. bridging). -- :wq Claudio
