Re: stdio: fclose(3), fopen(3): intended locking hierarchy?

2020-11-27 Thread Philip Guenther
On Wed, Nov 25, 2020 at 4:23 PM Scott Cheloha 
wrote:

> In stdio, which lock are you supposed to take first?  The global
> sfp_mutex or the per-FILE lock?
>
> In __sfp() we hold sfp_mutex while iterating through the pool (unsure
> what else to call it) of FILEs.  No two threads can modify the pool at
> the same time:
>
...

> Note that we set _flags to 1 to reserve it for the current thread
> before leaving sfp_mutex.  Note also that we don't take the per-FILE
> lock before reading each FILE's _flags.
>
> Then look at fclose(3):
>
...

> We check if _flags is zero without any lock.  I'm unsure if this is
> safe.
>
> However, we then clean up under the FILE's lock and set _flags to zero
> without sfp_mutex.
>
> ... that can't be right.
>
> So, what to do?  My immediate thought was to export sfp_mutex and
> enter it before writing _flags (diff attached).  But then the global
> sfp_mutex is "higher" in the locking hierarchy than the per-FILE lock.
> That doesn't seem quite right to me.
>
> We also modify _flags all over stdio without sfp_mutex, so the rule is
> inconsistent.
>
> Another possibility is to take the per-FILE lock when examining each
> FILE's _flags during __sfp().  That would be costlier, but then the
> hierarchy would be reversed.
>
> Thoughts?
>

 Let's say that we're willing to presume that changing _flags from
one non-zero value to another non-zero value will never result in
a zero value being visible either on this CPU or another one.  If
that's not true, then there's more to fix, but let's start with
that assumption.

Given that, I think the only unsafe item in what you described above
is the setting of _flags to zero in various places without either
holding sfp_mutex or using some sort of membar (or atomic op) to
guarantee all previous changes to the FILE are visible before the
flags change is visible.

My reasoning would be that if the setting of _flags from non-zero
to zero was always the last thing visible, then the code scanning
the list could be sure that a non-zero flags means no one else has
any pending writes to the FILE and it can be allocated.  __sfp()'s
setting _flags to 1 to mark it as allocated is made visible to other
threads when it unlocks sfp_mutex.

...but we don't have those membars/atomic-ops, so it's not currently
guaranteed that __sfp() can't allocate a FILE which is still being
updated by a thread that's releasing it.  ;(

If strewing membars makes people twitchy (my eye twitches some),
then yeah, your proposal to take sfp_mutex when zeroing _file is
te alternative.  Regarding the hierarchy concern, see below.


None of this fixes _fwalk(), which can invoke the callback on
partially created FILEs, even if it were to grab sfp_mutex.  I can
imagine a couple directions for fixing that, from setting __SIGN
on not-yet-completed FILEs and clearing it at the end, to full-blown
having __sfp() return a locked FILE and making _fwalk() lock each
FILE before invoking the callback.  Note that of the three callbacks
passed to _fwalk(), two end up locking the FILE anyway, so maybe
this is the right direction anyway.

So, the lock hierarchy is then...interesting:
 * if you hold sfp_mutex, you can FLOCKFILE a FILE iff _flags == 0
 * if _flags != 0, you must lock sfp_mutex before zeroing it and
   FUNLOCKFILE and never touch the FILE again before unlocking
   sfp_mutex.
Given the assumption at top, I believe that's safe+correct.


The problem case for _fwalk() is _cleanup(), which currently and
explicitly 'cheats' by failing to lock FILE...but I suspect that's
a hold-over from when abort() called atexit() handlers, as it's
supposed to be async-signal-safe and therefore can't take locks.
abort() no longer does that: POSIX withdrew it because, well, it
can't be done safely with an async-signal-safe abort() without
making lots of stdio functions block all signals, which would lead
to torches and pitchforks.  This is presumably _also_ why _fwalk()
doesn't lock sfp_mutex when it 'obviously' should, so that's fixable
too!  Woot!

So yeah, maybe it does work to:
1) make __sfp() FLOCKFILE() the allocated FILE before unlocking sfp_mutex
2) update f{,d,mem,un}open() and open_*memstream() to match (1), unlocking
   in all paths when the FILE is safe to be accessed by _fwalk(), and
locking
   sfp_mutex around the zeroing of _flags.
3) make fclose() and freopen() also lock sfp_mutex around the zeroing of
_flags
   (should add an _frelease() to findfp.c that does this dance for (2) and
(3))
4) make _fwalk() take sfp_mutex, and maybe also a FILE* so the setting of
   __SIGN can be done under the lock?
5) decide how/whether to handle adjust the FLOCKFILE placement in the
_fwalk()
   tree: is the testing of the "is line-buffered" flag in lflush() safe
without
   a lock?  Mumble...

Now, back to that first assumption: if you're not willing to assume
it then the "is allocated" test needs to not use _flags but be some
other state change which can be relied on to not have false-positives,
but otherwise 

Re: sio_open.3: clarify what sio_start() does

2020-11-27 Thread √Črico Nogueira
On Fri Nov 27, 2020 at 3:05 PM -03, Alexandre Ratchov wrote:
> this wording is shorter and more precise and complete.
>
> ok?
>
> Index: sio_open.3
> ===
> RCS file: /cvs/src/lib/libsndio/sio_open.3,v
> retrieving revision 1.51
> diff -u -p -r1.51 sio_open.3
> --- sio_open.3 20 Nov 2020 12:09:45 - 1.51
> +++ sio_open.3 27 Nov 2020 18:02:16 -
> @@ -387,17 +387,17 @@ bitmasks should always be used.
> .Ss Starting and stopping the device
> The
> .Fn sio_start
> -function puts the device in a waiting state:
> -the device will wait for playback data to be provided
> -(using the
> -.Fn sio_write
> -function).
> -Once enough data is queued to ensure that play buffers
> -will not underrun, actual playback is started automatically.
> -If record mode only is selected, then recording starts
> -immediately.
> +function prepares the devices to start.

Using 'devices' instead of 'device' here is different from the current
version. Is that intentional?

> +Once the play buffer is full, i.e.
> +.Fa sio_par.bufsz
> +samples are queued with
> +.Fn sio_write ,
> +playback starts automatically.
> +If record mode only is selected, then
> +.Fn sio_start
> +starts recording immediately.
> In full-duplex mode, playback and recording will start
> -synchronously as soon as enough data to play is available.
> +synchronously as soon as the play buffer is full.
> .Pp
> The
> .Fn sio_stop

Thanks for looking into this, it's much clearer now.

√Črico



Re: lld for macppc kernel

2020-11-27 Thread Mark Kettenis
> Date: Mon, 23 Nov 2020 22:59:19 -0500
> From: George Koehler 
> 
> With this diff, lld can link macppc's kernel.
> 
> The first part of the diff adds R_PPC_ADDR24 to lld.  I didn't find
> code in upstream lld's git for R_PPC_ADDR24.  We need R_PPC_ADDR24 for
> "ba" and "bla" in locore.S.

I suppose llvm doesn't generate these relocations.

> The second part edits the kernel's Makefile.macppc.  I add gapdummy
> (like in Makefile.powerpc64) to avoid an lld error.  I also adapt a
> part of Makefile.i386, so my powerpc64 can build and link the macppc
> kernel.  (I didn't boot that kernel.)  My macppc can now build, link,
> and boot the GENERIC kernel with either ld.bfd or ld.lld.
> 
> ok to commit?

ok kettenis@

> Index: gnu/llvm/lld/ELF/Arch/PPC.cpp
> ===
> RCS file: /cvs/src/gnu/llvm/lld/ELF/Arch/PPC.cpp,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 PPC.cpp
> --- gnu/llvm/lld/ELF/Arch/PPC.cpp 3 Aug 2020 14:32:29 -   1.1.1.1
> +++ gnu/llvm/lld/ELF/Arch/PPC.cpp 23 Nov 2020 19:49:47 -
> @@ -220,6 +220,7 @@ RelExpr PPC::getRelExpr(RelType type, co
>case R_PPC_ADDR16_HA:
>case R_PPC_ADDR16_HI:
>case R_PPC_ADDR16_LO:
> +  case R_PPC_ADDR24:
>case R_PPC_ADDR32:
>  return R_ABS;
>case R_PPC_DTPREL16:
> @@ -344,6 +345,7 @@ void PPC::relocateOne(uint8_t *loc, RelT
>  break;
>}
>case R_PPC_REL24:
> +  case R_PPC_ADDR24:
>case R_PPC_LOCAL24PC:
>case R_PPC_PLTREL24: {
>  uint32_t mask = 0x03FC;
> Index: sys/arch/macppc/conf/Makefile.macppc
> ===
> RCS file: /cvs/src/sys/arch/macppc/conf/Makefile.macppc,v
> retrieving revision 1.99
> diff -u -p -r1.99 Makefile.macppc
> --- sys/arch/macppc/conf/Makefile.macppc  7 Nov 2019 20:42:28 -   
> 1.99
> +++ sys/arch/macppc/conf/Makefile.macppc  23 Nov 2020 19:49:49 -
> @@ -53,6 +53,13 @@ CFLAGS=${DEBUG} ${CWARNFLAGS} ${CMACHF
>  AFLAGS=  -D_LOCORE ${CMACHFLAGS}
>  LINKFLAGS=   -N -Ttext 100114 -e start --warn-common -nopie
>  
> +.if ${MACHINE} == "powerpc64"
> +CFLAGS+= -m32
> +AFLAGS+= -m32
> +LDFLAGS= -melf32ppc
> +LINKFLAGS+=  ${LDFLAGS}
> +.endif
> +
>  HOSTCC?= ${CC}
>  HOSTED_CPPFLAGS=${CPPFLAGS:S/^-nostdinc$//}
>  HOSTED_CFLAGS=   ${CFLAGS}
> @@ -123,12 +130,16 @@ ioconf.o: ioconf.c
>  ld.script: ${_machdir}/conf/ld.script
>   cp ${_machdir}/conf/ld.script $@
>  
> +gapdummy.o:
> + echo '__asm(".section .rodata,\"a\"");' > gapdummy.c
> + ${CC} -c ${CFLAGS} ${CPPFLAGS} gapdummy.c -o $@
> +
>  makegap.sh:
>   cp $S/conf/makegap.sh $@
>  
> -MAKE_GAP = LD="${LD}" sh makegap.sh 0x   # guaranteed illegal
> +MAKE_GAP = LD="${LD}" sh makegap.sh 0x gapdummy.o
>  
> -gap.o:   Makefile makegap.sh vers.o
> +gap.o:   Makefile makegap.sh gapdummy.o vers.o
>   ${MAKE_GAP}
>  
>  vers.o: ${SYSTEM_DEP:Ngap.o}
> @@ -137,7 +148,7 @@ vers.o: ${SYSTEM_DEP:Ngap.o}
>  
>  clean:
>   rm -f *bsd *bsd.gdb *.[dio] [a-z]*.s assym.* \
> - gap.link ld.script lorder makegap.sh param.c
> + gap.link gapdummy.c ld.script lorder makegap.sh param.c
>  
>  cleandir: clean
>   rm -f Makefile *.h ioconf.c options machine ${_mach} vers.c
> 
> 



Re: slaacd(8): unexpected FD

2020-11-27 Thread Theo Buehler
On Fri, Nov 27, 2020 at 09:41:21PM +0100, Florian Obser wrote:
> An interface might have disappeared or switched rdomains while we
> waited for a FD. It's not a fatal condition if it arrives late.

That makes sense.

> I can only get it to lose the race by introducing a sleep in the
> parent process, but the race is still there. Found while implementing
> rdomain support in rad(8) using the same pattern.

I did not manage to reproduce this in rdomain rad, but I didn't try very
hard. I understand the race now.

ok tb

> I'm now wondering if it would be better to listen on the route socket
> for interface arrivals / departure in the parent process instead of
> the frontend asking for a raw socket to be opened. But that's a diff
> for another time.
>
> OK?
> 
> diff --git frontend.c frontend.c
> index 4b3f575611e..7efbe50df20 100644
> --- frontend.c
> +++ frontend.c
> @@ -1164,9 +1164,14 @@ set_icmp6sock(int icmp6sock, int rdomain)
>   }
>   }
>  
> - if (icmp6sock != -1)
> - fatalx("received unneeded ICMPv6 socket for rdomain %d",
> - rdomain);
> + if (icmp6sock != -1) {
> + /*
> +  * The interface disappeared or changed rdomain while we were
> +  * waiting for the parent process to open the raw socket.
> +  */
> + close(icmp6sock);
> + return;
> + }
>  
>   LIST_FOREACH (iface, , entries) {
>   if (event_initialized(>icmp6ev->ev) &&
> 
> -- 
> I'm not entirely sure you are real.
> 



Re: lld for macppc kernel

2020-11-27 Thread George Koehler
On Mon, 23 Nov 2020 22:59:19 -0500
George Koehler  wrote:

> My macppc can now build, link,
> and boot the GENERIC kernel with either ld.bfd or ld.lld.

ld.lld with my diff can link macppc kernels GENERIC, GENERIC.MP, and
RAMDISK, and I can boot and run them, but all macppc kernels from lld
have  == 0x1034 which is far too high.

$ nm bsd|grep etext
1034 T etext

ofwboot with ld.lld doesn't work; I needed to relink ofwboot with
ld.bfd to boot any kernel.  ofwboot also had  == 0x1034,
but I don't know what caused ofwboot to fail.

I still ask if ld.lld diff for R_PPC_ADDR24 is ok.



Re: slaacd(8): changing rdomain

2020-11-27 Thread Theo Buehler
On Fri, Nov 27, 2020 at 09:34:59PM +0100, Florian Obser wrote:
> 
> Handle the case of an autoconf interface changing its rdomain.
> 
> To avoide code duplication have get_icmp6ev_by_rdomain() either return
> an existing icmp6ev in the correct rdomain or allocate one.
> 
> OK?

ok tb.

> 
> diff --git frontend.c frontend.c
> index 3bf418ba31e..624ff5562f3 100644
> --- frontend.c
> +++ frontend.c
> @@ -502,7 +502,6 @@ void
>  update_iface(uint32_t if_index, char* if_name)
>  {
>   struct iface*iface;
> - struct icmp6_ev *icmp6ev;
>   struct imsg_ifinfo   imsg_ifinfo;
>   int  flags, xflags, ifrdomain;
>  
> @@ -516,32 +515,29 @@ update_iface(uint32_t if_index, char* if_name)
>   if((ifrdomain = get_ifrdomain(if_name)) == -1)
>   return;
>  
> - if ((iface = get_iface_by_id(if_index)) == NULL) {
> + iface = get_iface_by_id(if_index);
> +
> + if (iface != NULL) {
> + if (iface->rdomain != ifrdomain) {
> + if (iface->icmp6ev != NULL) {
> + iface->icmp6ev->refcnt--;
> + if (iface->icmp6ev->refcnt == 0) {
> + event_del(>icmp6ev->ev);
> + close(EVENT_FD(>icmp6ev->ev));
> + free(iface->icmp6ev);
> + }
> + iface->icmp6ev = NULL;
> + }
> + iface->rdomain = ifrdomain;
> + iface->icmp6ev = get_icmp6ev_by_rdomain(ifrdomain);
> + }
> + } else {
>   if ((iface = calloc(1, sizeof(*iface))) == NULL)
>   fatal("calloc");
>   iface->if_index = if_index;
>   iface->rdomain = ifrdomain;
> + iface->icmp6ev = get_icmp6ev_by_rdomain(ifrdomain);
>  
> - if ((icmp6ev = get_icmp6ev_by_rdomain(ifrdomain)) == NULL) {
> - if ((icmp6ev = calloc(1, sizeof(*icmp6ev))) == NULL)
> - fatal("calloc");
> - icmp6ev->rcviov[0].iov_base = (caddr_t)icmp6ev->answer;
> - icmp6ev->rcviov[0].iov_len = sizeof(icmp6ev->answer);
> - icmp6ev->rcvmhdr.msg_name = (caddr_t)>from;
> - icmp6ev->rcvmhdr.msg_namelen = sizeof(icmp6ev->from);
> - icmp6ev->rcvmhdr.msg_iov = icmp6ev->rcviov;
> - icmp6ev->rcvmhdr.msg_iovlen = 1;
> - icmp6ev->rcvmhdr.msg_controllen =
> - CMSG_SPACE(sizeof(struct in6_pktinfo)) +
> - CMSG_SPACE(sizeof(int));
> - if ((icmp6ev->rcvmhdr.msg_control = malloc(icmp6ev->
> - rcvmhdr.msg_controllen)) == NULL)
> - fatal("malloc");
> - frontend_imsg_compose_main(IMSG_OPEN_ICMP6SOCK, 0,
> - , sizeof(ifrdomain));
> - }
> - iface->icmp6ev = icmp6ev;
> - iface->icmp6ev->refcnt++;
>   LIST_INSERT_HEAD(, iface, entries);
>   }
>  
> @@ -1121,13 +1117,35 @@ struct icmp6_ev*
>  get_icmp6ev_by_rdomain(int rdomain)
>  {
>   struct iface*iface;
> + struct icmp6_ev *icmp6ev = NULL;
>  
>   LIST_FOREACH (iface, , entries) {
> - if (iface->rdomain == rdomain)
> - return (iface->icmp6ev);
> + if (iface->rdomain == rdomain) {
> + icmp6ev = iface->icmp6ev;
> + break;
> + }
>   }
>  
> - return (NULL);
> + if (icmp6ev == NULL) {
> + if ((icmp6ev = calloc(1, sizeof(*icmp6ev))) == NULL)
> + fatal("calloc");
> + icmp6ev->rcviov[0].iov_base = (caddr_t)icmp6ev->answer;
> + icmp6ev->rcviov[0].iov_len = sizeof(icmp6ev->answer);
> + icmp6ev->rcvmhdr.msg_name = (caddr_t)>from;
> + icmp6ev->rcvmhdr.msg_namelen = sizeof(icmp6ev->from);
> + icmp6ev->rcvmhdr.msg_iov = icmp6ev->rcviov;
> + icmp6ev->rcvmhdr.msg_iovlen = 1;
> + icmp6ev->rcvmhdr.msg_controllen =
> + CMSG_SPACE(sizeof(struct in6_pktinfo)) +
> + CMSG_SPACE(sizeof(int));
> + if ((icmp6ev->rcvmhdr.msg_control = malloc(icmp6ev->
> + rcvmhdr.msg_controllen)) == NULL)
> + fatal("malloc");
> + frontend_imsg_compose_main(IMSG_OPEN_ICMP6SOCK, 0,
> + , sizeof(rdomain));
> + }
> + icmp6ev->refcnt++;
> + return (icmp6ev);
>  }
>  
>  void
> -- 
> 2.29.2
> 
> 
> 
> -- 
> I'm not entirely sure you are real.
> 



slaacd(8): unexpected FD

2020-11-27 Thread Florian Obser
An interface might have disappeared or switched rdomains while we
waited for a FD. It's not a fatal condition if it arrives late.

I can only get it to lose the race by introducing a sleep in the
parent process, but the race is still there. Found while implementing
rdomain support in rad(8) using the same pattern.

I'm now wondering if it would be better to listen on the route socket
for interface arrivals / departure in the parent process instead of
the frontend asking for a raw socket to be opened. But that's a diff
for another time.

OK?

diff --git frontend.c frontend.c
index 4b3f575611e..7efbe50df20 100644
--- frontend.c
+++ frontend.c
@@ -1164,9 +1164,14 @@ set_icmp6sock(int icmp6sock, int rdomain)
}
}
 
-   if (icmp6sock != -1)
-   fatalx("received unneeded ICMPv6 socket for rdomain %d",
-   rdomain);
+   if (icmp6sock != -1) {
+   /*
+* The interface disappeared or changed rdomain while we were
+* waiting for the parent process to open the raw socket.
+*/
+   close(icmp6sock);
+   return;
+   }
 
LIST_FOREACH (iface, , entries) {
if (event_initialized(>icmp6ev->ev) &&

-- 
I'm not entirely sure you are real.



slaacd(8): unref_icmp6ev()

2020-11-27 Thread Florian Obser
Reduce code duplication by introducing unref_icmp6ev()

OK?

diff --git frontend.c frontend.c
index 624ff5562f3..4b3f575611e 100644
--- frontend.c
+++ frontend.c
@@ -92,6 +92,7 @@ void   get_lladdr(char *, struct ether_addr *, struct 
sockaddr_in6 *);
 struct iface   *get_iface_by_id(uint32_t);
 voidremove_iface(uint32_t);
 struct icmp6_ev*get_icmp6ev_by_rdomain(int);
+voidunref_icmp6ev(struct iface *);
 voidset_icmp6sock(int, int);
 voidsend_solicitation(uint32_t);
 #ifndefSMALL
@@ -519,15 +520,7 @@ update_iface(uint32_t if_index, char* if_name)
 
if (iface != NULL) {
if (iface->rdomain != ifrdomain) {
-   if (iface->icmp6ev != NULL) {
-   iface->icmp6ev->refcnt--;
-   if (iface->icmp6ev->refcnt == 0) {
-   event_del(>icmp6ev->ev);
-   close(EVENT_FD(>icmp6ev->ev));
-   free(iface->icmp6ev);
-   }
-   iface->icmp6ev = NULL;
-   }
+   unref_icmp6ev(iface);
iface->rdomain = ifrdomain;
iface->icmp6ev = get_icmp6ev_by_rdomain(ifrdomain);
}
@@ -1102,14 +1095,7 @@ remove_iface(uint32_t if_index)
 
LIST_REMOVE(iface, entries);
 
-   if (iface->icmp6ev != NULL) {
-   iface->icmp6ev->refcnt--;
-   if (iface->icmp6ev->refcnt == 0) {
-   event_del(>icmp6ev->ev);
-   close(EVENT_FD(>icmp6ev->ev));
-   free(iface->icmp6ev);
-   }
-   }
+   unref_icmp6ev(iface);
free(iface);
 }
 
@@ -1148,6 +1134,20 @@ get_icmp6ev_by_rdomain(int rdomain)
return (icmp6ev);
 }
 
+void
+unref_icmp6ev(struct iface *iface)
+{
+   if (iface->icmp6ev != NULL) {
+   iface->icmp6ev->refcnt--;
+   if (iface->icmp6ev->refcnt == 0) {
+   event_del(>icmp6ev->ev);
+   close(EVENT_FD(>icmp6ev->ev));
+   free(iface->icmp6ev);
+   }
+   iface->icmp6ev = NULL;
+   }
+}
+
 void
 set_icmp6sock(int icmp6sock, int rdomain)
 {
-- 
2.29.2



-- 
I'm not entirely sure you are real.



slaacd(8): changing rdomain

2020-11-27 Thread Florian Obser


Handle the case of an autoconf interface changing its rdomain.

To avoide code duplication have get_icmp6ev_by_rdomain() either return
an existing icmp6ev in the correct rdomain or allocate one.

OK?

diff --git frontend.c frontend.c
index 3bf418ba31e..624ff5562f3 100644
--- frontend.c
+++ frontend.c
@@ -502,7 +502,6 @@ void
 update_iface(uint32_t if_index, char* if_name)
 {
struct iface*iface;
-   struct icmp6_ev *icmp6ev;
struct imsg_ifinfo   imsg_ifinfo;
int  flags, xflags, ifrdomain;
 
@@ -516,32 +515,29 @@ update_iface(uint32_t if_index, char* if_name)
if((ifrdomain = get_ifrdomain(if_name)) == -1)
return;
 
-   if ((iface = get_iface_by_id(if_index)) == NULL) {
+   iface = get_iface_by_id(if_index);
+
+   if (iface != NULL) {
+   if (iface->rdomain != ifrdomain) {
+   if (iface->icmp6ev != NULL) {
+   iface->icmp6ev->refcnt--;
+   if (iface->icmp6ev->refcnt == 0) {
+   event_del(>icmp6ev->ev);
+   close(EVENT_FD(>icmp6ev->ev));
+   free(iface->icmp6ev);
+   }
+   iface->icmp6ev = NULL;
+   }
+   iface->rdomain = ifrdomain;
+   iface->icmp6ev = get_icmp6ev_by_rdomain(ifrdomain);
+   }
+   } else {
if ((iface = calloc(1, sizeof(*iface))) == NULL)
fatal("calloc");
iface->if_index = if_index;
iface->rdomain = ifrdomain;
+   iface->icmp6ev = get_icmp6ev_by_rdomain(ifrdomain);
 
-   if ((icmp6ev = get_icmp6ev_by_rdomain(ifrdomain)) == NULL) {
-   if ((icmp6ev = calloc(1, sizeof(*icmp6ev))) == NULL)
-   fatal("calloc");
-   icmp6ev->rcviov[0].iov_base = (caddr_t)icmp6ev->answer;
-   icmp6ev->rcviov[0].iov_len = sizeof(icmp6ev->answer);
-   icmp6ev->rcvmhdr.msg_name = (caddr_t)>from;
-   icmp6ev->rcvmhdr.msg_namelen = sizeof(icmp6ev->from);
-   icmp6ev->rcvmhdr.msg_iov = icmp6ev->rcviov;
-   icmp6ev->rcvmhdr.msg_iovlen = 1;
-   icmp6ev->rcvmhdr.msg_controllen =
-   CMSG_SPACE(sizeof(struct in6_pktinfo)) +
-   CMSG_SPACE(sizeof(int));
-   if ((icmp6ev->rcvmhdr.msg_control = malloc(icmp6ev->
-   rcvmhdr.msg_controllen)) == NULL)
-   fatal("malloc");
-   frontend_imsg_compose_main(IMSG_OPEN_ICMP6SOCK, 0,
-   , sizeof(ifrdomain));
-   }
-   iface->icmp6ev = icmp6ev;
-   iface->icmp6ev->refcnt++;
LIST_INSERT_HEAD(, iface, entries);
}
 
@@ -1121,13 +1117,35 @@ struct icmp6_ev*
 get_icmp6ev_by_rdomain(int rdomain)
 {
struct iface*iface;
+   struct icmp6_ev *icmp6ev = NULL;
 
LIST_FOREACH (iface, , entries) {
-   if (iface->rdomain == rdomain)
-   return (iface->icmp6ev);
+   if (iface->rdomain == rdomain) {
+   icmp6ev = iface->icmp6ev;
+   break;
+   }
}
 
-   return (NULL);
+   if (icmp6ev == NULL) {
+   if ((icmp6ev = calloc(1, sizeof(*icmp6ev))) == NULL)
+   fatal("calloc");
+   icmp6ev->rcviov[0].iov_base = (caddr_t)icmp6ev->answer;
+   icmp6ev->rcviov[0].iov_len = sizeof(icmp6ev->answer);
+   icmp6ev->rcvmhdr.msg_name = (caddr_t)>from;
+   icmp6ev->rcvmhdr.msg_namelen = sizeof(icmp6ev->from);
+   icmp6ev->rcvmhdr.msg_iov = icmp6ev->rcviov;
+   icmp6ev->rcvmhdr.msg_iovlen = 1;
+   icmp6ev->rcvmhdr.msg_controllen =
+   CMSG_SPACE(sizeof(struct in6_pktinfo)) +
+   CMSG_SPACE(sizeof(int));
+   if ((icmp6ev->rcvmhdr.msg_control = malloc(icmp6ev->
+   rcvmhdr.msg_controllen)) == NULL)
+   fatal("malloc");
+   frontend_imsg_compose_main(IMSG_OPEN_ICMP6SOCK, 0,
+   , sizeof(rdomain));
+   }
+   icmp6ev->refcnt++;
+   return (icmp6ev);
 }
 
 void
-- 
2.29.2



-- 
I'm not entirely sure you are real.



sio_open.3: clarify what sio_start() does

2020-11-27 Thread Alexandre Ratchov
this wording is shorter and more precise and complete.

ok?

Index: sio_open.3
===
RCS file: /cvs/src/lib/libsndio/sio_open.3,v
retrieving revision 1.51
diff -u -p -r1.51 sio_open.3
--- sio_open.3  20 Nov 2020 12:09:45 -  1.51
+++ sio_open.3  27 Nov 2020 18:02:16 -
@@ -387,17 +387,17 @@ bitmasks should always be used.
 .Ss Starting and stopping the device
 The
 .Fn sio_start
-function puts the device in a waiting state:
-the device will wait for playback data to be provided
-(using the
-.Fn sio_write
-function).
-Once enough data is queued to ensure that play buffers
-will not underrun, actual playback is started automatically.
-If record mode only is selected, then recording starts
-immediately.
+function prepares the devices to start.
+Once the play buffer is full, i.e.
+.Fa sio_par.bufsz
+samples are queued with
+.Fn sio_write ,
+playback starts automatically.
+If record mode only is selected, then
+.Fn sio_start
+starts recording immediately.
 In full-duplex mode, playback and recording will start
-synchronously as soon as enough data to play is available.
+synchronously as soon as the play buffer is full.
 .Pp
 The
 .Fn sio_stop



Fan Management Framework

2020-11-27 Thread Marcus Glocker
Hi,

I recently decided to replace MacOSX on my iMac11,3 27" with OpenBSD.
During the MacOSX times I had to replace the broken HDD with a new SSD.
The new SSD didn't offer pins to attach the sensor cable back, which
was previously attached to the HDD, so I left it loose.  This caused
the HDD fan to spin up to maximum over time.  On MacOSX there are some
fan control programs with which I could control the fan speed.  I
almost forgot about that "fix" over time, but installing OpenBSD on
that machine remembered me of it - You can't overhear it :-)

That made me play around with asmc(4), where I noticed you can not
only read the fan properties, but also set them.  I initially was
thinking to make sysctl(8) able to set fan speeds, but what I could
see is that the fan framework there seems to be designed to read
only.  Instead of poking around further in sysctl(8), I had the idea
to create a small fan(4) framework layer, which can be controlled
through a device by using a fanctl(8) user-land program.

I don't know if there are other fan sensor controllers which would
allow fan properties control.  If yes, they potentially could attach
to the same fan framework.  If not, the fan framework probably doesn't
make much sense only to be used by asmc(4).

Some example:

...
asmc0 at acpi0: SMC_ (smc-piketon) addr 0x300/0x20: rev 1.59f559, 297
keys
fan0 at asmc0
...

bigmac# sysctl | grep fan
hw.sensors.asmc0.fan0=998 RPM (ODD, right mid rear)
hw.sensors.asmc0.fan1=3677 RPM (HDD, center mid rear)
hw.sensors.asmc0.fan2=939 RPM (CPU, left lower rear)

bigmac# ./fanctl
driver=asmc0
fan0.id=ODD, right mid rear
fan0.act=999 RPM
fan0.min=1000 RPM
fan0.max=3800 RPM
fan0.saf=0 RPM
fan0.tgt=1000 RPM
fan1.id=HDD, center mid rear
fan1.act=3693 RPM
fan1.min=1100 RPM
fan1.max=5500 RPM
fan1.saf=0 RPM
fan1.tgt=3700 RPM
fan2.id=CPU, left lower rear
fan2.act=939 RPM
fan2.min=940 RPM
fan2.max=2100 RPM
fan2.saf=0 RPM
fan2.tgt=940 RPM

bigmac# ./fanctl fan1.act
fan1.act=3729
bigmac# ./fanctl fan1.max 
fan1.max=5500

bigmac# ./fanctl fan1.max=1000
fan1.max: 5500 -> 1000

*silence* :-)

bigmac# ./fanctl fan1.act 
fan1.act=1002

Attached a very initial coding, but basically works for me.

Maybe the idea is totally stupid, and the use cases are very
rare.  I don't know.  Therefore I would appreciate some feedback.

Thanks,
Marcus


Index: etc/MAKEDEV.common
===
RCS file: /cvs/src/etc/MAKEDEV.common,v
retrieving revision 1.111
diff -u -p -u -p -r1.111 MAKEDEV.common
--- etc/MAKEDEV.common  6 Jul 2020 06:11:26 -   1.111
+++ etc/MAKEDEV.common  27 Nov 2020 16:13:39 -
@@ -170,6 +170,7 @@ target(all, bpf)dnl
 target(all, kcov)dnl
 target(all, dt)dnl
 target(all, kstat)dnl
+target(all, fan, 0)dnl
 dnl
 _mkdev(all, {-all-}, {-dnl
 show_target(all)dnl
@@ -535,3 +536,6 @@ __devitem(dt, dt, Dynamic Tracer)dnl
 _mkdev(dt, dt, {-M dt c major_dt_c 0 600-})dnl
 __devitem(kstat, kstat, Kernel Statistics)dnl
 _mkdev(kstat, kstat, {-M kstat c major_kstat_c 0 640-})dnl
+__devitem(fan, fan*, Fan Management Framework)dnl
+_mkdev(fan, fan*, {-M fan$U c major_fan_c $U 600
+   MKlist[${#MKlist[*]}]=";[ -e fan ] || ln -s fan$U fan"-})dnl
Index: etc/etc.amd64/MAKEDEV.md
===
RCS file: /cvs/src/etc/etc.amd64/MAKEDEV.md,v
retrieving revision 1.76
diff -u -p -u -p -r1.76 MAKEDEV.md
--- etc/etc.amd64/MAKEDEV.md6 Jul 2020 06:11:26 -   1.76
+++ etc/etc.amd64/MAKEDEV.md27 Nov 2020 16:13:39 -
@@ -98,6 +98,7 @@ _DEV(vscsi, 89)
 _DEV(pvbus, 95)
 _DEV(switch, 97)
 _DEV(kstat, 51)
+_DEV(fan, 48)
 dnl
 divert(__mddivert)dnl
 dnl
Index: sys/arch/amd64/amd64/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/conf.c,v
retrieving revision 1.72
diff -u -p -u -p -r1.72 conf.c
--- sys/arch/amd64/amd64/conf.c 7 Oct 2020 13:37:33 -   1.72
+++ sys/arch/amd64/amd64/conf.c 27 Nov 2020 16:13:53 -
@@ -173,6 +173,7 @@ cdev_decl(pci);
 #include "pvbus.h"
 #include "ipmi.h"
 #include "switch.h"
+#include "fan.h"
 
 struct cdevsw  cdevsw[] =
 {
@@ -229,7 +230,7 @@ struct cdevsw   cdevsw[] =
cdev_random_init(1,random), /* 45: random data source */
cdev_ocis_init(NPCTR,pctr), /* 46: performance counters */
cdev_disk_init(NRD,rd), /* 47: ram disk driver */
-   cdev_notdef(),  /* 48 */
+   cdev_fan_init(NFAN,fan),/* 48: Fan Management */
cdev_bktr_init(NBKTR,bktr), /* 49: Bt848 video capture device */
cdev_ksyms_init(NKSYMS,ksyms),  /* 50: Kernel symbols device */

Re: wg(4) manpage tweaks

2020-11-27 Thread Renaud Allard



On 11/27/20 1:29 PM, Stuart Henderson wrote:

It's not very clear how to fetch the pubkey. OK to add this to wg(4)?

Index: wg.4
===
RCS file: /cvs/src/share/man/man4/wg.4,v
retrieving revision 1.6
diff -u -p -r1.6 wg.4
--- wg.424 Nov 2020 16:33:05 -  1.6
+++ wg.427 Nov 2020 12:28:32 -
@@ -64,6 +64,9 @@ interface may be configured to recognise
  .It Key
  Each peer uses its private key and corresponding public key to
  identify itself to others.
+The public key may be displayed by running
+.Xr ifconfig 8
+as root after configuring the private key.
  A peer configures a
  .Nm wg
  interface with its own private key and with the public keys of its peers.
@@ -138,9 +141,11 @@ but demonstrates two interfaces on the s
  .Bd -literal
  #!/bin/sh
  
+# create interfaces, set random private keys

  ifconfig wg1 create wgport 7111 wgkey `openssl rand -base64 32` rdomain 1
  ifconfig wg2 create wgport 7222 wgkey `openssl rand -base64 32` rdomain 2
  
+# retrieve the public keys associated with the private keys

  PUB1="`ifconfig wg1 | grep 'wgpubkey' | cut -d ' ' -f 2`"
  PUB2="`ifconfig wg2 | grep 'wgpubkey' | cut -d ' ' -f 2`"
  



I have no powers over the OK, but I completely agree it wasn't really clear.



smime.p7s
Description: S/MIME Cryptographic Signature


Re: wg(4) manpage tweaks

2020-11-27 Thread Jason McIntyre
On Fri, Nov 27, 2020 at 02:28:42PM +, Stuart Henderson wrote:
> On 2020/11/27 14:17, Jason McIntyre wrote:
> > On Fri, Nov 27, 2020 at 02:09:57PM +, Stuart Henderson wrote:
> > > On 2020/11/27 13:41, Jason McIntyre wrote:
> > > > > +++ wg.4  27 Nov 2020 12:28:32 -
> > > > > @@ -64,6 +64,9 @@ interface may be configured to recognise
> > > > >  .It Key
> > > > >  Each peer uses its private key and corresponding public key to
> > > > >  identify itself to others.
> > > > > +The public key may be displayed by running
> > > > > +.Xr ifconfig 8
> > > > > +as root after configuring the private key.
> > > > >  A peer configures a
> > > > >  .Nm wg
> > > > >  interface with its own private key and with the public keys of its 
> > > > > peers.
> > > > 
> > > > i'm not sure about this text. wouldn;t the "Keys" section make more
> > > > sense? the "Keys" section itself says:
> > > > 
> > > >  When an interface has a private key set with wgkey, the
> > > >  corresponding public key is shown in the status output of
> > > >  the interface, like so:
> > > > 
> > > >wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=
> > > > 
> > > > maybe we should just elaborate here?
> > > 
> > > Ah yes, that does seem a better place, maybe this helps, though
> > > perhaps the addition to the example script is enough to give the
> > > hint anyway.
> > > 
> > > Index: man4/wg.4
> > > ===
> > > RCS file: /cvs/src/share/man/man4/wg.4,v
> > > retrieving revision 1.7
> > > diff -u -p -r1.7 wg.4
> > > --- man4/wg.4 27 Nov 2020 14:04:49 -  1.7
> > > +++ man4/wg.4 27 Nov 2020 14:08:56 -
> > > @@ -124,7 +124,10 @@ will accept any random 32-byte base64 st
> > >  When an interface has a private key set with
> > >  .Nm wgkey ,
> > >  the corresponding
> > > -public key is shown in the status output of the interface, like so:
> > > +public key is shown in the status output of the interface
> > > +displayed by
> > > +.Xr ifconfig 8
> > > +when run as root, like so:
> > >  .Bd -literal -offset indent
> > >  wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=
> > >  .Ed
> > > 
> > > 
> > 
> > fine by me. i tried to think if we had any precedent in the man pages
> > for this, where output is exposed by root, but couldn't. i thought our
> > wireless interfaces did sth like that.
> > 
> > i also tried to shorten your text but couldn;t come up with anything
> > better.
> > so ok.
> > jmc
> > 
> 
> Alternatively:
> 
> Index: wg.4
> ===
> RCS file: /cvs/src/share/man/man4/wg.4,v
> retrieving revision 1.7
> diff -u -p -r1.7 wg.4
> --- wg.4  27 Nov 2020 14:04:49 -  1.7
> +++ wg.4  27 Nov 2020 14:28:03 -
> @@ -125,8 +125,9 @@ When an interface has a private key set 
>  .Nm wgkey ,
>  the corresponding
>  public key is shown in the status output of the interface, like so:
> -.Bd -literal -offset indent
> -wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=
> +.Bd -literal
> +# ifconfig wg1 | grep wgpubkey
> + wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=
>  .Ed
>  .Sh EXAMPLES
>  Create two
> 

this is shorter (good), but less explicit about the need for root (less good).
i guess it's a trade off.

i think on balance i like the way you've done it here, but i'm fine
either way. i'd remove ", like so" though. also i don;t think you should
remove the indent - it would make the openssl example above it look
wonky.

jmc



Re: wg(4) manpage tweaks

2020-11-27 Thread Stuart Henderson
On 2020/11/27 14:17, Jason McIntyre wrote:
> On Fri, Nov 27, 2020 at 02:09:57PM +, Stuart Henderson wrote:
> > On 2020/11/27 13:41, Jason McIntyre wrote:
> > > > +++ wg.427 Nov 2020 12:28:32 -
> > > > @@ -64,6 +64,9 @@ interface may be configured to recognise
> > > >  .It Key
> > > >  Each peer uses its private key and corresponding public key to
> > > >  identify itself to others.
> > > > +The public key may be displayed by running
> > > > +.Xr ifconfig 8
> > > > +as root after configuring the private key.
> > > >  A peer configures a
> > > >  .Nm wg
> > > >  interface with its own private key and with the public keys of its 
> > > > peers.
> > > 
> > > i'm not sure about this text. wouldn;t the "Keys" section make more
> > > sense? the "Keys" section itself says:
> > > 
> > >When an interface has a private key set with wgkey, the
> > >corresponding public key is shown in the status output of
> > >the interface, like so:
> > > 
> > >  wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=
> > > 
> > > maybe we should just elaborate here?
> > 
> > Ah yes, that does seem a better place, maybe this helps, though
> > perhaps the addition to the example script is enough to give the
> > hint anyway.
> > 
> > Index: man4/wg.4
> > ===
> > RCS file: /cvs/src/share/man/man4/wg.4,v
> > retrieving revision 1.7
> > diff -u -p -r1.7 wg.4
> > --- man4/wg.4   27 Nov 2020 14:04:49 -  1.7
> > +++ man4/wg.4   27 Nov 2020 14:08:56 -
> > @@ -124,7 +124,10 @@ will accept any random 32-byte base64 st
> >  When an interface has a private key set with
> >  .Nm wgkey ,
> >  the corresponding
> > -public key is shown in the status output of the interface, like so:
> > +public key is shown in the status output of the interface
> > +displayed by
> > +.Xr ifconfig 8
> > +when run as root, like so:
> >  .Bd -literal -offset indent
> >  wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=
> >  .Ed
> > 
> > 
> 
> fine by me. i tried to think if we had any precedent in the man pages
> for this, where output is exposed by root, but couldn't. i thought our
> wireless interfaces did sth like that.
> 
> i also tried to shorten your text but couldn;t come up with anything
> better.
> so ok.
> jmc
> 

Alternatively:

Index: wg.4
===
RCS file: /cvs/src/share/man/man4/wg.4,v
retrieving revision 1.7
diff -u -p -r1.7 wg.4
--- wg.427 Nov 2020 14:04:49 -  1.7
+++ wg.427 Nov 2020 14:28:03 -
@@ -125,8 +125,9 @@ When an interface has a private key set 
 .Nm wgkey ,
 the corresponding
 public key is shown in the status output of the interface, like so:
-.Bd -literal -offset indent
-wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=
+.Bd -literal
+# ifconfig wg1 | grep wgpubkey
+   wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=
 .Ed
 .Sh EXAMPLES
 Create two



Re: wg(4) manpage tweaks

2020-11-27 Thread Jason McIntyre
On Fri, Nov 27, 2020 at 02:09:57PM +, Stuart Henderson wrote:
> On 2020/11/27 13:41, Jason McIntyre wrote:
> > > +++ wg.4  27 Nov 2020 12:28:32 -
> > > @@ -64,6 +64,9 @@ interface may be configured to recognise
> > >  .It Key
> > >  Each peer uses its private key and corresponding public key to
> > >  identify itself to others.
> > > +The public key may be displayed by running
> > > +.Xr ifconfig 8
> > > +as root after configuring the private key.
> > >  A peer configures a
> > >  .Nm wg
> > >  interface with its own private key and with the public keys of its peers.
> > 
> > i'm not sure about this text. wouldn;t the "Keys" section make more
> > sense? the "Keys" section itself says:
> > 
> >  When an interface has a private key set with wgkey, the
> >  corresponding public key is shown in the status output of
> >  the interface, like so:
> > 
> >wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=
> > 
> > maybe we should just elaborate here?
> 
> Ah yes, that does seem a better place, maybe this helps, though
> perhaps the addition to the example script is enough to give the
> hint anyway.
> 
> Index: man4/wg.4
> ===
> RCS file: /cvs/src/share/man/man4/wg.4,v
> retrieving revision 1.7
> diff -u -p -r1.7 wg.4
> --- man4/wg.4 27 Nov 2020 14:04:49 -  1.7
> +++ man4/wg.4 27 Nov 2020 14:08:56 -
> @@ -124,7 +124,10 @@ will accept any random 32-byte base64 st
>  When an interface has a private key set with
>  .Nm wgkey ,
>  the corresponding
> -public key is shown in the status output of the interface, like so:
> +public key is shown in the status output of the interface
> +displayed by
> +.Xr ifconfig 8
> +when run as root, like so:
>  .Bd -literal -offset indent
>  wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=
>  .Ed
> 
> 

fine by me. i tried to think if we had any precedent in the man pages
for this, where output is exposed by root, but couldn't. i thought our
wireless interfaces did sth like that.

i also tried to shorten your text but couldn;t come up with anything
better.

so ok.
jmc



Re: wg(4) manpage tweaks

2020-11-27 Thread Stuart Henderson
On 2020/11/27 13:41, Jason McIntyre wrote:
> > +++ wg.427 Nov 2020 12:28:32 -
> > @@ -64,6 +64,9 @@ interface may be configured to recognise
> >  .It Key
> >  Each peer uses its private key and corresponding public key to
> >  identify itself to others.
> > +The public key may be displayed by running
> > +.Xr ifconfig 8
> > +as root after configuring the private key.
> >  A peer configures a
> >  .Nm wg
> >  interface with its own private key and with the public keys of its peers.
> 
> i'm not sure about this text. wouldn;t the "Keys" section make more
> sense? the "Keys" section itself says:
> 
>When an interface has a private key set with wgkey, the
>corresponding public key is shown in the status output of
>the interface, like so:
> 
>  wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=
> 
> maybe we should just elaborate here?

Ah yes, that does seem a better place, maybe this helps, though
perhaps the addition to the example script is enough to give the
hint anyway.

Index: man4/wg.4
===
RCS file: /cvs/src/share/man/man4/wg.4,v
retrieving revision 1.7
diff -u -p -r1.7 wg.4
--- man4/wg.4   27 Nov 2020 14:04:49 -  1.7
+++ man4/wg.4   27 Nov 2020 14:08:56 -
@@ -124,7 +124,10 @@ will accept any random 32-byte base64 st
 When an interface has a private key set with
 .Nm wgkey ,
 the corresponding
-public key is shown in the status output of the interface, like so:
+public key is shown in the status output of the interface
+displayed by
+.Xr ifconfig 8
+when run as root, like so:
 .Bd -literal -offset indent
 wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=
 .Ed


> i agree a bit of explanation makes sense here. saying that, you should
> really join "create interfaces" and "set random private keys" with a
> semicolon or "and" or somesuch, not a comma.

I've committed that with a semicolon.



Re: wg(4) manpage tweaks

2020-11-27 Thread Jason McIntyre
On Fri, Nov 27, 2020 at 12:29:01PM +, Stuart Henderson wrote:
> It's not very clear how to fetch the pubkey. OK to add this to wg(4)?
> 

hi.

> Index: wg.4
> ===
> RCS file: /cvs/src/share/man/man4/wg.4,v
> retrieving revision 1.6
> diff -u -p -r1.6 wg.4
> --- wg.4  24 Nov 2020 16:33:05 -  1.6
> +++ wg.4  27 Nov 2020 12:28:32 -
> @@ -64,6 +64,9 @@ interface may be configured to recognise
>  .It Key
>  Each peer uses its private key and corresponding public key to
>  identify itself to others.
> +The public key may be displayed by running
> +.Xr ifconfig 8
> +as root after configuring the private key.
>  A peer configures a
>  .Nm wg
>  interface with its own private key and with the public keys of its peers.

i'm not sure about this text. wouldn;t the "Keys" section make more
sense? the "Keys" section itself says:

 When an interface has a private key set with wgkey, the
 corresponding public key is shown in the status output of
 the interface, like so:

   wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps=

maybe we should just elaborate here?

> @@ -138,9 +141,11 @@ but demonstrates two interfaces on the s
>  .Bd -literal
>  #!/bin/sh
>  
> +# create interfaces, set random private keys

i agree a bit of explanation makes sense here. saying that, you should
really join "create interfaces" and "set random private keys" with a
semicolon or "and" or somesuch, not a comma.

jmc

>  ifconfig wg1 create wgport 7111 wgkey `openssl rand -base64 32` rdomain 1
>  ifconfig wg2 create wgport 7222 wgkey `openssl rand -base64 32` rdomain 2
>  
> +# retrieve the public keys associated with the private keys
>  PUB1="`ifconfig wg1 | grep 'wgpubkey' | cut -d ' ' -f 2`"
>  PUB2="`ifconfig wg2 | grep 'wgpubkey' | cut -d ' ' -f 2`"
>  




wg(4) manpage tweaks

2020-11-27 Thread Stuart Henderson
It's not very clear how to fetch the pubkey. OK to add this to wg(4)?

Index: wg.4
===
RCS file: /cvs/src/share/man/man4/wg.4,v
retrieving revision 1.6
diff -u -p -r1.6 wg.4
--- wg.424 Nov 2020 16:33:05 -  1.6
+++ wg.427 Nov 2020 12:28:32 -
@@ -64,6 +64,9 @@ interface may be configured to recognise
 .It Key
 Each peer uses its private key and corresponding public key to
 identify itself to others.
+The public key may be displayed by running
+.Xr ifconfig 8
+as root after configuring the private key.
 A peer configures a
 .Nm wg
 interface with its own private key and with the public keys of its peers.
@@ -138,9 +141,11 @@ but demonstrates two interfaces on the s
 .Bd -literal
 #!/bin/sh
 
+# create interfaces, set random private keys
 ifconfig wg1 create wgport 7111 wgkey `openssl rand -base64 32` rdomain 1
 ifconfig wg2 create wgport 7222 wgkey `openssl rand -base64 32` rdomain 2
 
+# retrieve the public keys associated with the private keys
 PUB1="`ifconfig wg1 | grep 'wgpubkey' | cut -d ' ' -f 2`"
 PUB2="`ifconfig wg2 | grep 'wgpubkey' | cut -d ' ' -f 2`"
 



Re: Typo fix in nsd.conf.5.in

2020-11-27 Thread Eddie Thieda
On Fri, Nov 27, 2020 at 6:29 AM Florian Obser  wrote:
>
> Could you please submit this upstream at
> https://github.com/NLnetLabs/nsd
>
> Thanks,
> Florian
>

Done.

https://github.com/NLnetLabs/nsd/commit/800ff7cd44b8bf0eb5586bc538444006751e90a1

> On Fri, Nov 27, 2020 at 05:44:11AM -0500, Eddie Thieda wrote:
> > Hello,
> >
> > Here's a small typo fix, url included if text gets mangled.
> >
> > http://ix.io/2FEF
> >
> > --- nsd.conf.5.in Tue Oct 13 06:06:08 2020
> > +++ nsd.conf.5.in2 Fri Nov 27 05:35:17 2020
> > @@ -161,7 +161,7 @@ anycast instances.  Use ip-transparent to be able to l
> >  turn on later (typical for certain load-balancing).
> >  .TP
> >  .B interface:\fR [@port] [servers] [bindtodevice] [setfib]
> > -Same as ip\-address (for easy of compatibility with unbound.conf).
> > +Same as ip\-address (for easy compatibility with unbound.conf).
> >  .TP
> >  .B ip\-transparent:\fR 
> >  Allows NSD to bind to non local addresses. This is useful to have NSD
> >
>
> --
> I'm not entirely sure you are real.



Re: Typo fix in nsd.conf.5.in

2020-11-27 Thread Florian Obser
Could you please submit this upstream at
https://github.com/NLnetLabs/nsd

Thanks,
Florian

On Fri, Nov 27, 2020 at 05:44:11AM -0500, Eddie Thieda wrote:
> Hello,
> 
> Here's a small typo fix, url included if text gets mangled.
> 
> http://ix.io/2FEF
> 
> --- nsd.conf.5.in Tue Oct 13 06:06:08 2020
> +++ nsd.conf.5.in2 Fri Nov 27 05:35:17 2020
> @@ -161,7 +161,7 @@ anycast instances.  Use ip-transparent to be able to l
>  turn on later (typical for certain load-balancing).
>  .TP
>  .B interface:\fR [@port] [servers] [bindtodevice] [setfib]
> -Same as ip\-address (for easy of compatibility with unbound.conf).
> +Same as ip\-address (for easy compatibility with unbound.conf).
>  .TP
>  .B ip\-transparent:\fR 
>  Allows NSD to bind to non local addresses. This is useful to have NSD
> 

-- 
I'm not entirely sure you are real.



Re: Typo fix in nsd.conf.5.in

2020-11-27 Thread Emil Engler
I think "ease of compatibility" was meant I personally would keep it 
that way but thanks for the nice catch!


Cheers,
Emil

On 11/27/20 11:44 AM, Eddie Thieda wrote:

Hello,

Here's a small typo fix, url included if text gets mangled.

http://ix.io/2FEF

--- nsd.conf.5.in Tue Oct 13 06:06:08 2020
+++ nsd.conf.5.in2 Fri Nov 27 05:35:17 2020
@@ -161,7 +161,7 @@ anycast instances.  Use ip-transparent to be able to l
  turn on later (typical for certain load-balancing).
  .TP
  .B interface:\fR [@port] [servers] [bindtodevice] [setfib]
-Same as ip\-address (for easy of compatibility with unbound.conf).
+Same as ip\-address (for easy compatibility with unbound.conf).
  .TP
  .B ip\-transparent:\fR 
  Allows NSD to bind to non local addresses. This is useful to have NSD





Typo fix in nsd.conf.5.in

2020-11-27 Thread Eddie Thieda
Hello,

Here's a small typo fix, url included if text gets mangled.

http://ix.io/2FEF

--- nsd.conf.5.in Tue Oct 13 06:06:08 2020
+++ nsd.conf.5.in2 Fri Nov 27 05:35:17 2020
@@ -161,7 +161,7 @@ anycast instances.  Use ip-transparent to be able to l
 turn on later (typical for certain load-balancing).
 .TP
 .B interface:\fR [@port] [servers] [bindtodevice] [setfib]
-Same as ip\-address (for easy of compatibility with unbound.conf).
+Same as ip\-address (for easy compatibility with unbound.conf).
 .TP
 .B ip\-transparent:\fR 
 Allows NSD to bind to non local addresses. This is useful to have NSD