Re: explain priority codepoints and their mapping in vlan.4
Christopher Zimmermann wrote: > We are not doing it different. But in my mind especially the mapping > of PCP / prio 0 / 1 is not intuitive and may be confusing (but is > correct!). That's why I think this should be documented in detail. Right. > >> The 802.1Q and 802.1ad protocols include a 3-bit priority code point > >> (PCP): > >>PCP 1 is defined as the lowest priority (“background”) > >>PCP 0 is the default (“best effort”) - second lowest priority. > >>PCPs 2-7 are increasing priority above best effort. > >> The priority may be altered via pf.conf(5); see the prio option for > >> more > >> information. > >>“prio 0” is mapped to PCP 1. > >>“prio 1” is mapped to PCP 0. > >>“prio 2-7” are mapped to PCP 2-7. > >> Alternatively, the txprio property of an interface can set a specific > >> priority for transmitted packets. You say it twice. But my eyes still glazed over it, not seeing what was going on the first two times. Maybe something more like prio 0 and 1 are mapped out of order to PCP 1 and 0, but prio 2 to 7 are mapped directly to PCP 2 to 7. No that still doesn't quite capture it in a visible way. How about prio 2 to 7 are mapped directly to PCP 2 to 7, but prio 0 and 1 are mapped backwards, to PCP 1 and 0, because <...> Something which will draw the eye+brain to 'something is different here'. The table alone doesn't do that.
Bioctl -c at securelevel 2
When running with kern.securelevel=2, trying to add an existing softraid volume with bioctl -c fails with: softraid0: invalid metadata format This occurs as the call to VOP_OPEN in sr_meta_probe requests read/write access, which is obviously disallowed at securelevel 2. Considering that regular partitions can be mounted and umounted at securelevel 2, is this inability to add a softraid volume by design, or an undesired side effect? It's not mentioned in securelevel(7), although the bugs section does note that the list of effects may not be complete. Should we test for securelevel 2, and return a more specific error message than, 'invalid metadata format', in this case? The current error seems somewhat misleading, as the on-disk metadata is obviously fine.
Re: explain priority codepoints and their mapping in vlan.4
On Tue, Dec 21, 2021 at 07:12:31AM +1000, David Gwynne wrote: are you able to find a reference for this in any of the current specs? or in documentation from other vendors? https://en.wikipedia.org/wiki/IEEE_P802.1p i've faithfully maintained this behaviour, but the only place i've seen in with my own eyes is in our code. if we're doing it different to literally everyone else, then maybe we shouldnt? We are not doing it different. But in my mind especially the mapping of PCP / prio 0 / 1 is not intuitive and may be confusing (but is correct!). That's why I think this should be documented in detail. On 21 Dec 2021, at 00:54, Christopher Zimmermann wrote: Hi, it might be helpful for others to understand the meaning of codepoints 0 and 1 of the vlan priority field. OK? Christopher Here is the formatted content: The 802.1Q and 802.1ad protocols include a 3-bit priority code point (PCP): PCP 1 is defined as the lowest priority (“background”) PCP 0 is the default (“best effort”) - second lowest priority. PCPs 2-7 are increasing priority above best effort. The priority may be altered via pf.conf(5); see the prio option for more information. “prio 0” is mapped to PCP 1. “prio 1” is mapped to PCP 0. “prio 2-7” are mapped to PCP 2-7. Alternatively, the txprio property of an interface can set a specific priority for transmitted packets. And here's the diff: Index: vlan.4 === RCS file: /cvs/src/share/man/man4/vlan.4,v retrieving revision 1.51 diff -u -p -r1.51 vlan.4 --- vlan.4 4 Oct 2020 12:44:49 - 1.51 +++ vlan.4 20 Dec 2021 14:51:31 - @@ -83,16 +83,38 @@ interfaces by their respective protocol identifiers, and decapsulated for reception on the associated virtual interfaces. .Pp -The 802.1Q and 802.1ad protocols include a priority field. -By default, the 802.1p priority in a transmitted packet is based on the -priority of packets sent over the interface, which may -be altered via +The 802.1Q and 802.1ad protocols include a 3-bit priority code point +(PCP): +.Bl -item -compact -offset MMM +.It +PCP 1 is defined as the lowest priority +.Pq Dq background +.It +PCP 0 is the default +.Pq Dq best effort +- second lowest priority. +.It +PCPs 2-7 are increasing priority above best effort. +.El +The priority may be altered via .Xr pf.conf 5 ; see the .Cm prio option for more information. -Alternatively, +.Bl -item -compact -offset MMM +.It +.Dq prio 0 +is mapped to PCP 1. +.It +.Dq prio 1 +is mapped to PCP 0. +.It +.Dq prio 2-7 +are mapped to PCP 2-7. +.El +Alternatively, the .Cm txprio +property of an interface can set a specific priority for transmitted packets. .Pp .Nm vlan -- http://gmerlin.de OpenPGP: http://gmerlin.de/christopher.pub CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
Re: explain priority codepoints and their mapping in vlan.4
are you able to find a reference for this in any of the current specs? or in documentation from other vendors? i've faithfully maintained this behaviour, but the only place i've seen in with my own eyes is in our code. if we're doing it different to literally everyone else, then maybe we shouldnt? > On 21 Dec 2021, at 00:54, Christopher Zimmermann wrote: > > Hi, > > it might be helpful for others to understand the meaning of codepoints 0 and > 1 of the vlan priority field. OK? > > Christopher > > Here is the formatted content: > > The 802.1Q and 802.1ad protocols include a 3-bit priority code point > (PCP): >PCP 1 is defined as the lowest priority (“background”) >PCP 0 is the default (“best effort”) - second lowest priority. >PCPs 2-7 are increasing priority above best effort. > The priority may be altered via pf.conf(5); see the prio option for more > information. >“prio 0” is mapped to PCP 1. >“prio 1” is mapped to PCP 0. >“prio 2-7” are mapped to PCP 2-7. > Alternatively, the txprio property of an interface can set a specific > priority for transmitted packets. > > > And here's the diff: > > Index: vlan.4 > === > RCS file: /cvs/src/share/man/man4/vlan.4,v > retrieving revision 1.51 > diff -u -p -r1.51 vlan.4 > --- vlan.44 Oct 2020 12:44:49 - 1.51 > +++ vlan.420 Dec 2021 14:51:31 - > @@ -83,16 +83,38 @@ interfaces by their respective protocol identifiers, and > decapsulated for reception on the associated virtual > interfaces. > .Pp > -The 802.1Q and 802.1ad protocols include a priority field. > -By default, the 802.1p priority in a transmitted packet is based on the > -priority of packets sent over the interface, which may > -be altered via > +The 802.1Q and 802.1ad protocols include a 3-bit priority code point > +(PCP): > +.Bl -item -compact -offset MMM > +.It > +PCP 1 is defined as the lowest priority > +.Pq Dq background > +.It > +PCP 0 is the default > +.Pq Dq best effort > +- second lowest priority. > +.It > +PCPs 2-7 are increasing priority above best effort. > +.El > +The priority may be altered via > .Xr pf.conf 5 ; > see the > .Cm prio > option for more information. > -Alternatively, > +.Bl -item -compact -offset MMM > +.It > +.Dq prio 0 > +is mapped to PCP 1. > +.It > +.Dq prio 1 > +is mapped to PCP 0. > +.It > +.Dq prio 2-7 > +are mapped to PCP 2-7. > +.El > +Alternatively, the > .Cm txprio > +property of an interface > can set a specific priority for transmitted packets. > .Pp > .Nm vlan >
Update www/surf to 2.1
Surf 2.1 was released seven months ago, but we still have 2.0 in ports.
The attached files update us to 2.1.
COMMENT = simple webbrowser based on webkit/gtk+
DISTNAME = surf-2.1
CATEGORIES =www
HOMEPAGE = http://surf.suckless.org/
REVISION = 0
MAINTAINER= Joerg Jung
# MIT
PERMIT_PACKAGE =Yes
WANTLIB += X11 atk-1.0 c cairo cairo-gobject gdk-3 gdk_pixbuf-2.0
WANTLIB += gio-2.0 glib-2.0 gobject-2.0 gtk-3 javascriptcoregtk-4.0
WANTLIB += pango-1.0 pangocairo-1.0 soup-2.4 webkit2gtk-4.0 intl
MASTER_SITES = http://dl.suckless.org/surf/
LIB_DEPENDS = devel/gettext,-runtime \
www/webkitgtk4
RUN_DEPENDS = x11/dmenu \
net/curl
# webkit browsing
RUN_DEPENDS += multimedia/gstreamer1/plugins-libav
MAKE_FLAGS= CC="${CC}"
MAKE_ENV= LDFLAGS="${LDFLAGS}"
FAKE_FLAGS= DESTDIR=""
NO_TEST = Yes
.include
SHA256 (surf-2.1.tar.gz) = cuWCkguiWmRiA+k8LSMx2H8DA3ooiU1sfpmvAO4EMlc=
SIZE (surf-2.1.tar.gz) = 22555
--- Makefile.dist Sun May 9 19:34:33 2021
+++ MakefileMon Dec 20 14:26:26 2021
@@ -53,17 +53,12 @@
rm -rf surf-$(VERSION)
install: all
- mkdir -p $(DESTDIR)$(PREFIX)/bin
- cp -f surf $(DESTDIR)$(PREFIX)/bin
- chmod 755 $(DESTDIR)$(PREFIX)/bin/surf
- mkdir -p $(DESTDIR)$(LIBDIR)
- cp -f $(WLIB) $(DESTDIR)$(LIBDIR)
- for wlib in $(WLIB); do \
- chmod 644 $(DESTDIR)$(LIBDIR)/$$wlib; \
- done
- mkdir -p $(DESTDIR)$(MANPREFIX)/man1
- sed "s/VERSION/$(VERSION)/g" < surf.1 >
$(DESTDIR)$(MANPREFIX)/man1/surf.1
- chmod 644 $(DESTDIR)$(MANPREFIX)/man1/surf.1
+ ${BSD_INSTALL_PROGRAM_DIR} ${DESTDIR}${PREFIX}/bin
+ ${BSD_INSTALL_PROGRAM} surf ${DESTDIR}${PREFIX}/bin
+ ${BSD_INSTALL_MAN_DIR} ${DESTDIR}${MANPREFIX}/man1
+ sed "s/VERSION/${VERSION}/g" < surf.1 > surf.1.tmp
+ mv surf.1.tmp surf.1
+ ${BSD_INSTALL_MAN} surf.1 ${DESTDIR}${MANPREFIX}/man1
uninstall:
rm -f $(DESTDIR)$(PREFIX)/bin/surf
--- config.def.h.dist Sun May 9 19:34:33 2021
+++ config.def.hMon Dec 20 14:30:08 2021
@@ -76,7 +76,7 @@
/* DOWNLOAD(URI, referer) */
#define DOWNLOAD(u, r) { \
-.v = (const char *[]){ "st", "-e", "/bin/sh", "-c",\
+.v = (const char *[]){ "xterm", "-e", "/bin/sh", "-c",\
"curl -g -L -J -O -A \"$1\" -b \"$2\" -c \"$2\"" \
" -e \"$3\" \"$4\"; read", \
"surf-download", useragent, cookiefile, r, u, NULL \
--- config.mk.dist Sun May 9 19:34:33 2021
+++ config.mk Mon Dec 20 14:59:23 2021
@@ -4,29 +4,29 @@
# Customize below to fit your system
# paths
-PREFIX = /usr/local
-MANPREFIX = $(PREFIX)/share/man
+PREFIX ?= /usr/local
+MANPREFIX = $(PREFIX)/man
LIBPREFIX = $(PREFIX)/lib
LIBDIR = $(LIBPREFIX)/surf
-X11INC = `pkg-config --cflags x11`
-X11LIB = `pkg-config --libs x11`
+X11INC != pkg-config --cflags x11
+X11LIB != pkg-config --libs x11
-GTKINC = `pkg-config --cflags gtk+-3.0 gcr-3 webkit2gtk-4.0`
-GTKLIB = `pkg-config --libs gtk+-3.0 gcr-3 webkit2gtk-4.0`
-WEBEXTINC = `pkg-config --cflags webkit2gtk-4.0 webkit2gtk-web-extension-4.0
gio-2.0`
-WEBEXTLIBS = `pkg-config --libs webkit2gtk-4.0 webkit2gtk-web-extension-4.0
gio-2.0`
+GTKINC != pkg-config --cflags gtk+-3.0 gcr-3 webkit2gtk-4.0
+GTKLIB != pkg-config --libs gtk+-3.0 gcr-3 webkit2gtk-4.0
+WEBEXTINC != pkg-config --cflags webkit2gtk-4.0 webkit2gtk-web-extension-4.0
gio-2.0
+WEBEXTLIBS != pkg-config --libs webkit2gtk-4.0 webkit2gtk-web-extension-4.0
gio-2.0
# includes and libs
INCS = $(X11INC) $(GTKINC)
-LIBS = $(X11LIB) $(GTKLIB) -lgthread-2.0
+LIBS = $(X11LIB) $(GTKLIB) -lgthread-2.0 -lX11
# flags
-CPPFLAGS = -DVERSION=\"$(VERSION)\" -DGCR_API_SUBJECT_TO_CHANGE \
+CPPFLAGS += -DVERSION=\"$(VERSION)\" -DGCR_API_SUBJECT_TO_CHANGE \
-DLIBPREFIX=\"$(LIBPREFIX)\" -DWEBEXTDIR=\"$(LIBDIR)\" \
-D_DEFAULT_SOURCE
-SURFCFLAGS = -fPIC $(INCS) $(CPPFLAGS)
-WEBEXTCFLAGS = -fPIC $(WEBEXTINC)
+SURFCFLAGS += -fPIC $(INCS) $(CPPFLAGS)
+WEBEXTCFLAGS += -fPIC $(WEBEXTINC)
# compiler
#CC = c99
syzkaller dt close
Hi,
syzkaller has found a crash in dtclose().
panic: kernel diagnostic assertion "suser(curproc) == 0" failed: file
"/syzkaller/managers/main/kernel/sys/dev/dt/dt_dev.c", line 431
https://syzkaller.appspot.com/bug?id=5d0d657ba9f3a16981aad2a6c50667918de4c955
Basically it does an open, setuid and close with /dev/dt .
dt_ioctl_record_stop() can be reached from dtclose().
The other asserts are useless, suser is checked in dtioctl().
ok?
bluhm
Index: dev/dt/dt_dev.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/dev/dt/dt_dev.c,v
retrieving revision 1.16
diff -u -p -r1.16 dt_dev.c
--- dev/dt/dt_dev.c 25 Oct 2021 19:51:12 - 1.16
+++ dev/dt/dt_dev.c 20 Dec 2021 17:40:59 -
@@ -428,8 +428,6 @@ dt_ioctl_record_stop(struct dt_softc *sc
{
struct dt_pcb *dp;
- KASSERT(suser(curproc) == 0);
-
if (!sc->ds_recording)
return;
@@ -459,8 +457,6 @@ dt_ioctl_probe_enable(struct dt_softc *s
struct dt_probe *dtp;
int error;
- KASSERT(suser(curproc) == 0);
-
if (!dtioc_req_isvalid(dtrq))
return EINVAL;
@@ -491,7 +487,6 @@ dt_ioctl_probe_disable(struct dt_softc *
struct dt_probe *dtp;
int error;
- KASSERT(suser(curproc) == 0);
if (!dtioc_req_isvalid(dtrq))
return EINVAL;
nsd 4.3.9
Trivial update to 4.3.9.
The only change is to configparser.y, the rest is fluff.
OK?
diff --git configparser.y configparser.y
index 6642a6f544c..70e54cf21f3 100644
--- configparser.y
+++ configparser.y
@@ -542,9 +542,9 @@ cpus:
/* Users may specify "0 1", "0" "1", 0 1 or a combination thereof. */
for(str = $2; (tok = strtok_r(str, " \t", )); str = NULL) {
struct cpu_option *opt =
- region_alloc(cfg_parser->opt->region, sizeof(*opt));
+ region_alloc_zero(cfg_parser->opt->region, sizeof(*opt));
cpu = 0;
-if(!parse_number(tok, ) || opt->cpu < 0) {
+if(!parse_number(tok, ) || cpu < 0) {
yyerror("expected a positive number");
YYABORT;
}
diff --git configure configure
index 4f8d1ccaddd..ca313c85794 100644
--- configure
+++ configure
@@ -1,6 +1,6 @@
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for NSD 4.3.8.
+# Generated by GNU Autoconf 2.69 for NSD 4.3.9.
#
# Report bugs to .
#
@@ -580,8 +580,8 @@ MAKEFLAGS=
# Identity of this package.
PACKAGE_NAME='NSD'
PACKAGE_TARNAME='nsd'
-PACKAGE_VERSION='4.3.8'
-PACKAGE_STRING='NSD 4.3.8'
+PACKAGE_VERSION='4.3.9'
+PACKAGE_STRING='NSD 4.3.9'
PACKAGE_BUGREPORT='nsd-b...@nlnetlabs.nl'
PACKAGE_URL=''
@@ -1328,7 +1328,7 @@ if test "$ac_init_help" = "long"; then
# Omit some internal or obsolete options to make the list less imposing.
# This message is too long to be a string in the A/UX 3.1 sh.
cat <<_ACEOF
-\`configure' configures NSD 4.3.8 to adapt to many kinds of systems.
+\`configure' configures NSD 4.3.9 to adapt to many kinds of systems.
Usage: $0 [OPTION]... [VAR=VALUE]...
@@ -1390,7 +1390,7 @@ fi
if test -n "$ac_init_help"; then
case $ac_init_help in
- short | recursive ) echo "Configuration of NSD 4.3.8:";;
+ short | recursive ) echo "Configuration of NSD 4.3.9:";;
esac
cat <<\_ACEOF
@@ -1563,7 +1563,7 @@ fi
test -n "$ac_init_help" && exit $ac_status
if $ac_init_version; then
cat <<\_ACEOF
-NSD configure 4.3.8
+NSD configure 4.3.9
generated by GNU Autoconf 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2272,7 +2272,7 @@ cat >config.log <<_ACEOF
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
-It was created by NSD $as_me 4.3.8, which was
+It was created by NSD $as_me 4.3.9, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ $0 $@
@@ -11155,7 +11155,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
# report actual input values of CONFIG_FILES etc. instead of their
# values after options handling.
ac_log="
-This file was extended by NSD $as_me 4.3.8, which was
+This file was extended by NSD $as_me 4.3.9, which was
generated by GNU Autoconf 2.69. Invocation command line was
CONFIG_FILES= $CONFIG_FILES
@@ -11217,7 +11217,7 @@ _ACEOF
cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //;
s/[\\""\`\$]/&/g'`"
ac_cs_version="\\
-NSD config.status 4.3.8
+NSD config.status 4.3.9
configured by $0, generated by GNU Autoconf 2.69,
with options \\"\$ac_cs_config\\"
diff --git configure.ac configure.ac
index 4c09bb363b9..94a2e1ee38d 100644
--- configure.ac
+++ configure.ac
@@ -5,7 +5,7 @@ dnl
sinclude(acx_nlnetlabs.m4)
sinclude(dnstap/dnstap.m4)
-AC_INIT([NSD],[4.3.8],[nsd-b...@nlnetlabs.nl])
+AC_INIT([NSD],[4.3.9],[nsd-b...@nlnetlabs.nl])
AC_CONFIG_HEADERS([config.h])
#
diff --git doc/ChangeLog doc/ChangeLog
index 43c3b7bfd72..0075ef70e2a 100644
--- doc/ChangeLog
+++ doc/ChangeLog
@@ -1,3 +1,21 @@
+2 December 2021: Wouter
+ - Fix socket_partitioning unit test for FreeBSD.
+ - Fix SVCB test to work around older dig with drill.
+
+1 December 2021: Wouter
+ - Set up for branch for 4.3.9 release.
+ - Fix unit tests for new answer-cookie default.
+
+30 November 2021: Wouter
+ - Fix to remove git tracking and ci information from release tarballs.
+
+3 November 2021: Wouter
+ - Fix #198: nsd-control reconfig core dump.
+
+12 October 2021: Wouter
+ - Tag for 4.3.8 release, from 4.3.8rc2. The main branch continues
+ with version 4.3.9 in development.
+
7 October 2021: Wouter
- Set default for answer-cookie to no. Because in server deployments
with mixed server software, a default of yes causes issues.
diff --git doc/RELNOTES doc/RELNOTES
index b7157bbc0a6..176d762de21 100644
--- doc/RELNOTES
+++ doc/RELNOTES
@@ -1,5 +1,14 @@
NSD RELEASE NOTES
+4.3.9
+
+BUG FIXES:
+ - Fix #198: nsd-control reconfig core dump.
+ - Fix to remove git tracking and ci information from release tarballs.
+ - Fix unit tests for new answer-cookie default.
+ - Fix socket_partitioning unit test for FreeBSD.
+ - Fix SVCB test to work around older dig with drill.
+
Re: document patch(1) not supporting binary diffs
Ingo Schwarze wrote: > The patch(1) manual talks about "lines" throughout, > and for binary files, a concept of "lines" does not even exist. That is a bit strong. Some utilities designed for "text files" have no problem being both 8-bit clean and very-long-line capable. For example, you can use emacs to edit a /bsd. Add a space at the start of the file, save it. re-edit the file, delete the space, and you get the same result. I changed the internals of mg decades ago to also be 8-bit clean + very-long-line capable. I think in POSIX this concept of "text file" is very weakly defined -- there are a variety of line-length issues, weird issues relating to \n and \r translation, obvious inability to handle embeded NUL etc, etc etc, and even end-of-file newline termination. It is a bit of a copout to say "text file", when the truth really is is "imperfect content handling". OTOH, adding perfect handling in many unix programs would be basically impossible, the complexity would be pretty high. It may even be that the patch inputfile format cannot handle arbitrary data. It certainly has newline followed by '+', '-', or ' ' and ending with '\n' as context tracking, so it might be impossible. > The problem arises from the manual failing to mention that patch(1) > operates on text files. Yes, I am OK with it saying so. > Many standard utilities operate on text files > only, the concept of a text-file is both well-known and defined by > POSIX, so there is no need to re-explain what that means in individual > pages. Nope, I think POSIX fails to create a good definition. Look at the recent commit to uniq.c, you even commented on it. patch can handle files without trailing \n, right? If the POSIX definition was real, patch would probably need to fail upon those files, creating other problems.
Re: document patch(1) not supporting binary diffs
On Mon, Dec 20, 2021 at 04:45:58PM +0100, Ingo Schwarze wrote: > Hi Christopher, > > Christopher Zimmermann wrote on Mon, Dec 20, 2021 at 04:01:49PM +0100: > > > base patch cannot work with diffs of binary files. It might help to say > > so in the manpage since other implementations do support this (ab)use of > > patch. OK? > > I agree you are pointing out a slight problem with the manual page, > but i dislike your patch for two reasons: > > This is not a bug, but a fundamental design decision. > The patch(1) manual talks about "lines" throughout, > and for binary files, a concept of "lines" does not even exist. > > And the basic idea of a tool ought to be described in the first > sentence of the description, not as an afterthought at the very end. > > The problem arises from the manual failing to mention that patch(1) > operates on text files. Many standard utilities operate on text files > only, the concept of a text-file is both well-known and defined by > POSIX, so there is no need to re-explain what that means in individual > pages. > > Consequently, i think something like the following would be better. > > Yours, > Ingo > > > Index: patch.1 > === > RCS file: /cvs/src/usr.bin/patch/patch.1,v > retrieving revision 1.33 > diff -u -r1.33 patch.1 > --- patch.1 9 Nov 2021 16:13:40 - 1.33 > +++ patch.1 20 Dec 2021 15:42:10 - > @@ -47,10 +47,12 @@ > .Pf \*(Lt Ar patchfile > .Sh DESCRIPTION > .Nm > -will take a patch file containing any of the four forms of difference > +takes the text file > +.Ar patchfile > +containing any of the four forms of difference > listing produced by the > .Xr diff 1 > -program and apply those differences to an original file, > +program and applies those differences to an original text file, > producing a patched version. > If > .Ar patchfile > hi ingo. i'm ok with your diff but it is slightly misleading in context of reading from stdin. i suppose that is no biggie. it would be simpler to just s/patch file/text file/ maybe? if not, i'm still ok with your version. jmc
Re: document patch(1) not supporting binary diffs
Hi Christopher, Christopher Zimmermann wrote on Mon, Dec 20, 2021 at 04:01:49PM +0100: > base patch cannot work with diffs of binary files. It might help to say > so in the manpage since other implementations do support this (ab)use of > patch. OK? I agree you are pointing out a slight problem with the manual page, but i dislike your patch for two reasons: This is not a bug, but a fundamental design decision. The patch(1) manual talks about "lines" throughout, and for binary files, a concept of "lines" does not even exist. And the basic idea of a tool ought to be described in the first sentence of the description, not as an afterthought at the very end. The problem arises from the manual failing to mention that patch(1) operates on text files. Many standard utilities operate on text files only, the concept of a text-file is both well-known and defined by POSIX, so there is no need to re-explain what that means in individual pages. Consequently, i think something like the following would be better. Yours, Ingo Index: patch.1 === RCS file: /cvs/src/usr.bin/patch/patch.1,v retrieving revision 1.33 diff -u -r1.33 patch.1 --- patch.1 9 Nov 2021 16:13:40 - 1.33 +++ patch.1 20 Dec 2021 15:42:10 - @@ -47,10 +47,12 @@ .Pf \*(Lt Ar patchfile .Sh DESCRIPTION .Nm -will take a patch file containing any of the four forms of difference +takes the text file +.Ar patchfile +containing any of the four forms of difference listing produced by the .Xr diff 1 -program and apply those differences to an original file, +program and applies those differences to an original text file, producing a patched version. If .Ar patchfile
document patch(1) not supporting binary diffs
Hi, base patch cannot work with diffs of binary files. It might help to say so in the manpage since other implementations do support this (ab)use of patch. OK? Christopher Index: patch.1 === RCS file: /cvs/src/usr.bin/patch/patch.1,v retrieving revision 1.33 diff -u -p -r1.33 patch.1 --- patch.1 9 Nov 2021 16:13:40 - 1.33 +++ patch.1 20 Dec 2021 15:00:52 - @@ -655,6 +655,8 @@ However, the results are guaranteed to b applied to exactly the same version of the file that the patch was generated from. .Sh BUGS +No support for patching binary files. +.Pp Could be smarter about partial matches, excessively deviant offsets and swapped code, but that would take an extra pass. .Pp
explain priority codepoints and their mapping in vlan.4
Hi, it might be helpful for others to understand the meaning of codepoints 0 and 1 of the vlan priority field. OK? Christopher Here is the formatted content: The 802.1Q and 802.1ad protocols include a 3-bit priority code point (PCP): PCP 1 is defined as the lowest priority (“background”) PCP 0 is the default (“best effort”) - second lowest priority. PCPs 2-7 are increasing priority above best effort. The priority may be altered via pf.conf(5); see the prio option for more information. “prio 0” is mapped to PCP 1. “prio 1” is mapped to PCP 0. “prio 2-7” are mapped to PCP 2-7. Alternatively, the txprio property of an interface can set a specific priority for transmitted packets. And here's the diff: Index: vlan.4 === RCS file: /cvs/src/share/man/man4/vlan.4,v retrieving revision 1.51 diff -u -p -r1.51 vlan.4 --- vlan.4 4 Oct 2020 12:44:49 - 1.51 +++ vlan.4 20 Dec 2021 14:51:31 - @@ -83,16 +83,38 @@ interfaces by their respective protocol identifiers, and decapsulated for reception on the associated virtual interfaces. .Pp -The 802.1Q and 802.1ad protocols include a priority field. -By default, the 802.1p priority in a transmitted packet is based on the -priority of packets sent over the interface, which may -be altered via +The 802.1Q and 802.1ad protocols include a 3-bit priority code point +(PCP): +.Bl -item -compact -offset MMM +.It +PCP 1 is defined as the lowest priority +.Pq Dq background +.It +PCP 0 is the default +.Pq Dq best effort +- second lowest priority. +.It +PCPs 2-7 are increasing priority above best effort. +.El +The priority may be altered via .Xr pf.conf 5 ; see the .Cm prio option for more information. -Alternatively, +.Bl -item -compact -offset MMM +.It +.Dq prio 0 +is mapped to PCP 1. +.It +.Dq prio 1 +is mapped to PCP 0. +.It +.Dq prio 2-7 +are mapped to PCP 2-7. +.El +Alternatively, the .Cm txprio +property of an interface can set a specific priority for transmitted packets. .Pp .Nm vlan
Re: Fix ipsp_spd_lookup() for transport mode
On Tue, Dec 14, 2021 at 06:25:20PM +0900, YASUOKA Masahiko wrote:
> Yes, if there is another better idea, it will be welcome.
> For this moment, the diff is the best idea for me.
Sorry, no better idea. I have no experiance with l2pt. Codewise
the diff looks fine, but I don't understand the consequences.
> + if (tdbflow != NULL)
> + rn = rn_lookup((caddr_t)>tdb_filter,
> + (caddr_t)>tdb_filtermask, rnh);
Does rn_lookup() modify the radix tree? I looks like rn_lookup ->
rn_addmask -> rn_insert() does that. This will make it impossible
to make IPsec MP capable. The radix tree is not MP safe, art has
been implemented as an alternative. An ipsp_spd_lookup() should
not modify the flows. It is stange that a function named rn_lookup()
does modifications. Did I miss something?
Why do you call rn_lookup() here? Could we add the masks earlier
when the flows are added?
> + else if (tdbp != NULL)
> + rn = rn_lookup((caddr_t)>tdb_filter,
> + (caddr_t)>tdb_filtermask, rnh);
What are the consequences of this chunk for regular IPsec?
> /* Match source/dest IDs. */
> - if (ipo->ipo_ids)
> - if (tdbp->tdb_ids == NULL ||
> - !ipsp_ids_match(ipo->ipo_ids,
> tdbp->tdb_ids))
> + if (ipo->ipo_ids != NULL) {
> + if ((tdbp->tdb_flags & TDBF_TUNNELING) == 0 &&
> + (tdbp->tdb_flags & TDBF_UDPENCAP) != 0) {
> + /*
> + * Skip IDs check for transport mode
> + * with NAT-T. Multiple clients (IDs)
> + * can use a same policy.
> + */
> + } else if (tdbp->tdb_ids == NULL &&
> + !ipsp_ids_match(ipo->ipo_ids,
> + tdbp->tdb_ids))
> goto nomatchin;
> + }
This was added to make IPsec/l2tp work in rev 1.85. And now you
change it to make it work. I wish markus@ or mikeb@ could give a
clue.
bluhm
Re: [PATCH] relayd client certificate validation again
Hi, we've got the patch ready for client certificate validation, cc'ing
related people.
The patch adds two features:
1. client certificate validation itself
2. passing on certificate and select fields in HTTP headers
## Brief description of client certificates (for whoever else is reading)
Client certificates, also known as mutual authentication, are the reverse
to TLS server certificates (like letsencrypt) where the server
authenticates the user instead of the other way around.
In principle client certificates work as follows:
- the server has keypair and a CA certificate created from this keypair
- the user has a keypair and submits their public key for certification (to
being signed by the CA)
- the server (relayd) has the CA certificate configured as 'client ca
"/path/to/ca.pem"'
- the user provides their certificate when connecting, the provided
certificate is validated against the CA certificate.
How this is set up in practice is up to whoever implements the
infrastructure. Client certificates can be installed to operating systems'
certificate stores (Windows, macOS) where browsers can use them, or into
browsers own certificate stores (Firefox has its own), or specified on the
command line (curl, wget) etc.
## Configuration
To turn on client certificate validation add
tls { client ca "/path/to/ca-cert.pem" }
to relayd.conf.
Add "optional" flag to make the certificate not required:
tls { client ca "/path/to/cert.pem" optional }
With "optional" relayd will succeed in the TLS handshake when no client
certificate is provided. But if a certificate *is* provided then it *must*
validate with the configured CA, otherwise the TLS handshake fails.
## Pass certificate on in HTTP header
To pass on the certificate in an url-encoded PEM:
match header set "ANY_HEADER_NAME" value "$CLIENT_CERT_CHAIN"
With this configuration the downstream can inspect the known-to-be-valid
certificate further (e.g extract identity or other info from x509
extensions).
There was discussion privately on is there any standard for putting
certificates in HTTP headers, repeating the reply here as well:
There appears to be no standard, but this is how other HTTP servers do it:
- nginx urlencodes the PEM file with $ssl_client_escaped_cert[1] (this is
what is done in this patch too). There is also the $ssl_client_cert
variable which adds a tab to each next new line, but this way of doing
multiline HTTP headers is deprecated[2]. There is also
$ssl_client_raw_cert, but the raw multiline PEM is invalid HTTP header;
- envoy also urlencodes the PEM[3];
- haproxy has only the binary DER, but base64 encoding it like
%[ssl_c_der,base64]) should result in PEM with no newlines and no headers;
- apache has the %{SSL_CLIENT_CERT} with raw (multiline) PEM[4], which is
invalid in HTTP headers, but this can be processed with the escape
function[5], something like "expr= %{escape:SSL_CLIENT_CERT}"
[1]
https://nginx.org/en/docs/http/ngx_http_ssl_module.html#var_ssl_client_escaped_cert
[2] https://tools.ietf.org/html/rfc7230#section-3.2.4
[3]
https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-client-cert
[4] https://httpd.apache.org/docs/current/mod/mod_ssl.html#envvars
[5] https://httpd.apache.org/docs/current/expr.html#functions
In addition to extracting the entire certificate, subject and issuer can be
put to HTTP headers too for convenience:
match header set "CS_SUBJECT" value "$CLIENT_CERT_SUBJECT"
match header set "CS_ISSUER" value "$CLIENT_CERT_ISSUER"
--
Markus Läll
On Thu, Dec 16, 2021 at 11:23 PM rivo nurges wrote:
> Hi!
>
> Here comes the support for relayd client certificate validation.
> Full certificate chain, subject and issuer can be passed over in http
> headers.
> It supports mandatory validation and optional validation(if client chooses
> to
> provide certificate it will be validated).
>
> Part of my sample config.
>
> http protocol test {
>match header set "CS_SUBJECT" value "$CLIENT_CERT_SUBJECT"
>match header set "CS_ISSUER" value "$CLIENT_CERT_ISSUER"
>match header set "CS_CERT" value "$CLIENT_CERT_CHAIN"
>pass
>tls {client ca "/tmp/easyrsa3/pki/ca.crt" optional }
> }
>
> This uses code from the patches submitted by Ashe Connor.
>
> Rivo
>
> diff refs/heads/master refs/heads/relay-clc3
> blob - a2f1c130d6b45e3082048218c11537dca485998a
> blob + 5070a7d48f58403f53d818231e1676db749aa9d7
> --- usr.sbin/relayd/config.c
> +++ usr.sbin/relayd/config.c
> @@ -954,6 +954,15 @@ config_setrelay(struct relayd *env, struct relay *rlay
> rlay->rl_conf.name);
> return (-1);
> }
> + if (rlay->rl_tls_client_ca_fd != -1 &&
> + config_setrelayfd(ps, id, n, 0,
> + rlay->rl_conf.id,
> RELAY_FD_CLIENTCACERT,
> +
Re: dev/videomode/vesagtf.c: -Werror,-Wunused-but-set-variable fix
Hi, > clang kernels are built with -Wno-unused-but-set-variable > try running 'make config' again oops, I forget 'make config'. Build process works good after that. Thank you! -- SASANO Takayoshi (JG1UAA)
Re: sndiod: -F does not switch back to preferred device
On Fri, Dec 17, 2021 at 07:11:41PM +, Klemens Nanni wrote: > > So we've concluded that the hotplpugging framework needs work, fine. > > I'd still like to improve sndiod(8) regarding its own behaviour. > > How about the same diff modulo hotplug referencing/examples? > This helps me understand `-f' and `-F' usage better. > > Feedback? Objections? OK? > > Index: sndiod.8 > === > RCS file: /cvs/src/usr.bin/sndiod/sndiod.8,v > retrieving revision 1.11 > diff -u -p -r1.11 sndiod.8 > --- sndiod.8 16 Jul 2021 15:05:58 - 1.11 > +++ sndiod.8 17 Dec 2021 19:02:21 - > @@ -185,7 +185,7 @@ Only the signedness and the precision ar > Examples: > .Va u8 , s16le , s24le3 , s24le4lsb . > .It Fl F Ar device > -Specify an alternate device to use. > +Specify a preferred device to use on startup. > If it doesn't work, the one given with the last > .Fl f > or Recently we dropped the "alternate device name" hack and now -F and -f are the same, except that -f may fail, while -F tries the next device. AFAICS, -F will disappear completely soon. What about just saying it's the same as -f? (BTW, the paragraph about USB may be moved to the new "HOT PLUGGING" section, if we go this way) > @@ -528,6 +528,24 @@ behave normally, while streams connected > wait for the MMC start signal and start synchronously. > Regardless of which device a stream is connected to, > its playback volume knob is exposed. > +.Sh HOT PLUGGING > +.Nm > +If preferred devices specified with > +.Fl F > +are unavailable at startup or detach at runtime, > +.Nm > +will attempt to seamlessly fall back to the last device specified. > +.Pp > +.Nm > +will not automatically switch to specified devices that attach at runtime. > +Instead, > +.Xr sndioctl 1 > +must be used to change the > +.Va server.device > +control. > +.Pp > +.Xr hotplugd 8 > +can be used to implement seamless switching at runtime. > .Sh EXAMPLES > Start server using default parameters, creating an > additional sub-device for output to channels 2:3 only (rear speakers > > "At startup" suggests this is when the daemon starts, imho "When a device is needed" is more accurate (devices are kept closed when not used, so when a device is needed again, iteration over -Ff restarts). With these tweaks, I end-up with the diff below. As this is a the "hot plugging" section, would it make sense to use plugged/unplugged instead of attach/detach words? diff --git a/sndiod/sndiod.8 b/sndiod/sndiod.8 index 910ce12..7dd72e5 100644 --- a/sndiod/sndiod.8 +++ b/sndiod/sndiod.8 @@ -185,8 +185,10 @@ Only the signedness and the precision are mandatory. Examples: .Va u8 , s16le , s24le3 , s24le4lsb . .It Fl F Ar device -Specify an alternate device to use. -If it doesn't work, the one given with the previous +Same as +.Fl f +except that if the device is disconnected, +the one given with the previous .Fl f or .Fl F @@ -196,11 +198,6 @@ PCI device allows .Nm to use the USB one preferably when it's connected and to fall back to the PCI one when it's disconnected. -Alternate devices may be switched with the -.Va server.device -control of the -.Xr sndioctl 1 -utility. .It Fl f Ar device Add this .Xr sndio 7 @@ -528,6 +525,23 @@ behave normally, while streams connected to wait for the MMC start signal and start synchronously. Regardless of which device a stream is connected to, its playback volume knob is exposed. +.Sh HOT PLUGGING +If devices specified with +.Fl F +are unavailable when needed or detach at runtime, +.Nm +will attempt to seamlessly fall back to the last device specified. +.Pp +.Nm +will not automatically switch to specified devices that attach at runtime. +Instead, +.Xr sndioctl 1 +must be used to change the +.Va server.device +control. +.Pp +.Xr hotplugd 8 +can be used to implement seamless switching at runtime. .Sh EXAMPLES Start server using default parameters, creating an additional sub-device for output to channels 2:3 only (rear speakers
