Re: ospfd: Apply netmask to stub prefixes before adding the route to the route table

2019-04-01 Thread Remi Locherer
Hi Mitchell On Sat, Mar 30, 2019 at 04:10:09PM +1000, Mitchell Krome wrote: > I kept finding I had a lingering /30 route when I turned off one of my > test boxes. I tracked it down to ospfd sending RTM_ADD for a stub > network with the non-masked prefix. The RTM_ADD path applies the mask > inside

Re: print msi/x details in pcidump

2019-04-01 Thread Mark Kettenis
> Date: Tue, 2 Apr 2019 11:45:00 +0800 > From: Jonathan Matthew > > This makes pcidump -v show whether MSI/MSI-X interrupts are enabled > for a device, and for MSI-X, the size of the interrupt table and > which BAR/offset it's in. > > ok? sure, ok kettenis@ > Index: pcidump.c >

print msi/x details in pcidump

2019-04-01 Thread Jonathan Matthew
This makes pcidump -v show whether MSI/MSI-X interrupts are enabled for a device, and for MSI-X, the size of the interrupt table and which BAR/offset it's in. ok? Index: pcidump.c === RCS file: /cvs/src/usr.sbin/pcidump/pcidump.c,v

Re: vmctl: report reliable VM state

2019-04-01 Thread Mike Larkin
On Mon, Apr 01, 2019 at 06:05:38PM +0200, Klemens Nanni wrote: > As of now, `vmctl status test' will tell you whether the VM is running > or not; except that "STATE" actually denotes whether the VCPU is > currently running or haltet, not whether the VM is started/running or > stopped. > > I

Re: rsync: add --one-file-system

2019-04-01 Thread Florian Obser
This does not do the right thing when sender and receiver do not agree on file system boundaries. Consider these mount points /dev/sd1g on /rsync-test/dst type ffs (local) /dev/sd1e on /rsync-test/src/e type ffs (local) /dev/sd1f on /rsync-test/src/e/f type ffs (local) and these files /

Re: Removing PF

2019-04-01 Thread Jordan Geoghegan
On 4/1/19 9:03 AM, Kevin Chadwick wrote: On 4/1/19 3:18 PM, Mateusz Guzik wrote: While I support pf removal, I don't think bpf is the way to go. FreeBSD just removed their pf [1] so the code is up for grabs and you can import it with one weird trick. [1]

Re: rsync: add --one-file-system

2019-04-01 Thread Theo de Raadt
Looking at real rsync, it appears the 'x' option is passed to the other side (your code does not do this), and there is also some special case for >1 -x option. Intuitively the client and server must do slightly different things especially when combined with --delete, or if one of them finds a

Re: Removing PF

2019-04-01 Thread Shawn Webb
On Mon, Apr 01, 2019 at 05:31:54AM -0600, Theo de Raadt wrote: > Todd C. Miller wrote: > > > On Mon, 01 Apr 2019 07:01:03 +0200, Claudio Jeker wrote: > > > > > There have been internal discussions about OpenBSD also removing the pf > > > packet filter after the upcoming 6.5 release. Instead a

Re: rsync: add --one-file-system

2019-04-01 Thread Sebastian Benoit
You are missing usage. I think its ok to just add -x to it, not the long option. Otherwise ok benno@ Bj??rn Ketelaars(bjorn.ketela...@hydroxide.nl) on 2019.04.01 21:36:34 +0200: > Add --one-file-system, which prevents openrsync to cross filesystem > boundaries. Option and behaviour is the same

Re: [EXTERNAL] Re: Removing PF

2019-04-01 Thread Eichert, Diana
Oops, I think you've confused me with Miod. He's the one who wrote the vax BPF. I was only talking to him about adding direct SIMH support in 6.6. That way you could have many kernels running within a kernel at boot time. I'm looking forward to running my old HP 2115 Fortran code Who

Re: [EXTERNAL] Re: Removing PF

2019-04-01 Thread Alexander Nasonov
Eichert, Diana wrote: > I wrote a vax BPF jit as a simple exercize some time ago, so all > you really need now is to implement vax-to-${ARCH} jit on an MD > basis. This should be very easy to do as long as BPF does not get > extended to use floating-point values. I'm afraid you have to rewrite it

rsync: add --one-file-system

2019-04-01 Thread Björn Ketelaars
Add --one-file-system, which prevents openrsync to cross filesystem boundaries. Option and behaviour is the same as GPL rsync. OK? diff --git usr.bin/rsync/extern.h usr.bin/rsync/extern.h index 12aceae566c..602cd24cede 100644 --- usr.bin/rsync/extern.h +++ usr.bin/rsync/extern.h @@ -117,6

Re: ksh "clear-screen" editing command

2019-04-01 Thread Sebastian Benoit
Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2019.04.01 16:52:34 +0200: > On Mon, Jun 18 2018, "Todd C. Miller" wrote: > > On Sun, 17 Jun 2018 15:52:34 -0600, "Todd C. Miller" wrote: > > > >> On Sun, 17 Jun 2018 17:29:31 +0200, Mark Kettenis wrote: > >> > >> > If folks indeed think that this is a

Re: [PATCH] bgpctl(8): improve user interface for RPKI Origin Validation

2019-04-01 Thread Sebastian Benoit
Job Snijders(j...@openbsd.org) on 2019.04.01 15:42:02 +0200: > Dear all, > > I've consulted with numerous user interface experts, their consistent > advice was to facilitate internalization by provoking simpler, stronger > emotions through the text based interface. > > bgpctl(8) will now provide

Re: iked curve25519

2019-04-01 Thread Stuart Henderson
On 2019/03/30 13:43, Theo de Raadt wrote: > I think we should switch, waiting doesn't help. > > Reyk Floeter wrote: > > > I like the idea of switching it to the proper ID. > > > > Reyk > > > > > Am 30.03.2019 um 20:31 schrieb Stuart Henderson : > > > > > > curve25519 had a proper ID (31)

Re: Removing PF

2019-04-01 Thread obsd
Op 1-4-2019 om 18:03 schreef Kevin Chadwick: On 4/1/19 3:18 PM, Mateusz Guzik wrote: While I support pf removal, I don't think bpf is the way to go. FreeBSD just removed their pf [1] so the code is up for grabs and you can import it with one weird trick. [1]

Re: [EXTERNAL] Re: iked curve25519

2019-04-01 Thread Eichert, Diana
You didn't ask for an enduser opinion but you should go ahead but I suggest a hard change. I can tell you people will continue to use the old method until it no longer works. -Original Message- From: owner-t...@openbsd.org On Behalf Of Tobias Heider Sent: Saturday, March 30, 2019 1:53

Re: [EXTERNAL] Re: Removing PF

2019-04-01 Thread Eichert, Diana
I thought you were going to deal with MD issues by adding support for SIMH into 6.6? -Original Message- From: owner-t...@openbsd.org On Behalf Of Miod Vallat Sent: Monday, April 1, 2019 7:04 AM To: tech@openbsd.org Subject: [EXTERNAL] Re: Removing PF > Will the bpf JIT changes be done

Re: ksh "clear-screen" editing command

2019-04-01 Thread Klemens Nanni
On Mon, Apr 01, 2019 at 09:53:31AM -0600, Todd C. Miller wrote: > AT ksh doesn't clear the screen by default on ^L. Other shells > like bash, zsh, and tcsh do. I don't object to making it the default > but as I'm not a ksh user I'll defer to those who are. Although I'm mostly using ksh in Vi

vmctl: report reliable VM state

2019-04-01 Thread Klemens Nanni
As of now, `vmctl status test' will tell you whether the VM is running or not; except that "STATE" actually denotes whether the VCPU is currently running or haltet, not whether the VM is started/running or stopped. I tripped over this when trying to use vmctl status test | fgrep 'STATE:

Re: Removing PF

2019-04-01 Thread Kevin Chadwick
On 4/1/19 3:18 PM, Mateusz Guzik wrote: > While I support pf removal, I don't think bpf is the way to go. > > FreeBSD just removed their pf [1] so the code is up for grabs and you > can import it with one weird trick. > > [1] >

Re: ksh "clear-screen" editing command

2019-04-01 Thread Todd C . Miller
On Mon, 01 Apr 2019 16:52:34 +0200, Jeremie Courreges-Anglas wrote: > Since this went in, I'm using it on my machines instead of a bind -m hack. > > Can't we make ^L=clear-screen the default behavior? I don't see > discussions about that. AT ksh doesn't clear the screen by default on ^L. Other

Re: iked(8): add support for IKEv2 Message Fragmentation

2019-04-01 Thread Tobias Heider
Here's the update. What changed: - fixed cleanup of fragments in SA - fixed retransmission of fragmented messages - adjusted copyright headers - Added some comments I also included Stuart's manpage parts as well as some line breaks. We've been testing this version and haven't found anything off

Re: ksh "clear-screen" editing command

2019-04-01 Thread Jeremie Courreges-Anglas
On Mon, Jun 18 2018, "Todd C. Miller" wrote: > On Sun, 17 Jun 2018 15:52:34 -0600, "Todd C. Miller" wrote: > >> On Sun, 17 Jun 2018 17:29:31 +0200, Mark Kettenis wrote: >> >> > If folks indeed think that this is a must-have feature, this is >> > certainly a better approach. I wonder though if

Re: Removing PF

2019-04-01 Thread Devin Ceartas
Will authpf be around?

Re: Removing PF

2019-04-01 Thread Mateusz Guzik
On 4/1/19, Claudio Jeker wrote: > There have been internal discussions about OpenBSD also removing the pf > packet filter after the upcoming 6.5 release. Instead a switch to > using David Gwynne's new bpf filter will happen. > The benefits outweigh the drawbacks and the missing features will be >

Re: [PATCH] bgpctl(8): improve user interface for RPKI Origin Validation

2019-04-01 Thread Claudio Jeker
On Mon, Apr 01, 2019 at 03:42:02PM +0200, Job Snijders wrote: > Dear all, > > I've consulted with numerous user interface experts, their consistent > advice was to facilitate internalization by provoking simpler, stronger > emotions through the text based interface. > > bgpctl(8) will now

Re: [PATCH] bgpctl(8): improve user interface for RPKI Origin Validation

2019-04-01 Thread Theo de Raadt
Job Snijders wrote: > Dear all, > > I've consulted with numerous user interface experts, their consistent > advice was to facilitate internalization by provoking simpler, stronger > emotions through the text based interface. > > bgpctl(8) will now provide simplified 'SAD' or 'HAPPY' ascii

[PATCH] bgpctl(8): improve user interface for RPKI Origin Validation

2019-04-01 Thread Job Snijders
Dear all, I've consulted with numerous user interface experts, their consistent advice was to facilitate internalization by provoking simpler, stronger emotions through the text based interface. bgpctl(8) will now provide simplified 'SAD' or 'HAPPY' ascii ideograms to help network operators

Re: Removing PF

2019-04-01 Thread Alexandr Nedvedicky
On Mon, Apr 01, 2019 at 01:04:19PM -, Miod Vallat wrote: > > > Will the bpf JIT changes be done in time for 6.6? I have no doubt > > that "pfctl -p /dev/bfp" can be made to work in time but for a truly > > performant firewall we will need bpf JIT. > > I wrote a vax BPF jit as a simple

Re: improve rsync(1) manual page

2019-04-01 Thread Theo de Raadt
Ingo Schwarze wrote: > >> * Change the misleading argument placeholder "portnumber" to "service"; > >>even the default ("rsync") isn't a number. In the description, > >>mention services(5), and also mention the default. > > > I don't object, but I wonder how much detail is needed.

Re: improve rsync(1) manual page

2019-04-01 Thread Ingo Schwarze
Hi Christian, Christian Weisgerber wrote on Mon, Apr 01, 2019 at 09:13:27AM +0200: > Ingo Schwarze: >> here are serveral bugfixes and improvements for the rsync(1) manual. > ok Thanks for checking, committed with the following tweaks: > I have some comments, but I think you should commit

Re: Removing PF

2019-04-01 Thread Miod Vallat
> Will the bpf JIT changes be done in time for 6.6? I have no doubt > that "pfctl -p /dev/bfp" can be made to work in time but for a truly > performant firewall we will need bpf JIT. I wrote a vax BPF jit as a simple exercize some time ago, so all you really need now is to implement

Re: Removing PF

2019-04-01 Thread Stuart Henderson
On 2019/04/01 07:01, Claudio Jeker wrote: > There have been internal discussions about OpenBSD also removing the pf > packet filter after the upcoming 6.5 release. Instead a switch to > using David Gwynne's new bpf filter will happen. > The benefits outweigh the drawbacks and the missing features

Re: Removing PF

2019-04-01 Thread Ingo Schwarze
Hi Claudio, Claudio Jeker wrote on Mon, Apr 01, 2019 at 07:01:03AM +0200: > There have been internal discussions about OpenBSD also removing the pf > packet filter after the upcoming 6.5 release. Instead a switch to > using David Gwynne's new bpf filter will happen. > The benefits outweigh the

Re: Removing PF

2019-04-01 Thread Theo de Raadt
Todd C. Miller wrote: > On Mon, 01 Apr 2019 07:01:03 +0200, Claudio Jeker wrote: > > > There have been internal discussions about OpenBSD also removing the pf > > packet filter after the upcoming 6.5 release. Instead a switch to > > using David Gwynne's new bpf filter will happen. > > The

Re: xidle: parse options once, simplify code

2019-04-01 Thread Klemens Nanni
On Mon, Nov 26, 2018 at 06:40:05PM +0100, Klemens Nanni wrote: > On Sun, Nov 11, 2018 at 06:07:10PM +0100, Klemens Nanni wrote: > > There's no point in parsing `-display' separately, just do it once and > > simplify the code while here. > > > > This addresses two of cheloha's comments from my

Re: Removing PF

2019-04-01 Thread Todd C . Miller
On Mon, 01 Apr 2019 07:01:03 +0200, Claudio Jeker wrote: > There have been internal discussions about OpenBSD also removing the pf > packet filter after the upcoming 6.5 release. Instead a switch to > using David Gwynne's new bpf filter will happen. > The benefits outweigh the drawbacks and the

Re: nvme_pci.c patch for MSI-X

2019-04-01 Thread Mark Kettenis
> From: "Ted Unangst" > Date: Mon, 01 Apr 2019 05:55:34 -0400 > > Mark Kettenis wrote: > > > Date: Thu, 28 Mar 2019 09:00:35 -0700 > > > From: Chris Cappuccio > > > > > > I think the current MSI-X implementation is a minimal skeleton, > > > enough for some devices under virtualization. I don't

Re: sys/dev/pci/if_wb.c: repair "} if"

2019-04-01 Thread Klemens Nanni
OK

Re: nvme_pci.c patch for MSI-X

2019-04-01 Thread Ted Unangst
Mark Kettenis wrote: > > Date: Thu, 28 Mar 2019 09:00:35 -0700 > > From: Chris Cappuccio > > > > I think the current MSI-X implementation is a minimal skeleton, > > enough for some devices under virtualization. I don't know if it's > > enough for NVMe on real hardware. > > The main problem is

Re: iwm: enable RF_KILL interrupts on resume

2019-04-01 Thread Stefan Sperling
On Mon, Apr 01, 2019 at 11:40:51AM +0200, Klemens Nanni wrote: > As promised in my earlier mail, here's a diff that fixes seemless > operation with the hardware kill switch on resume after suspend. > > Like the interrupt handler, the resume path needs to check the register > to update flags in

Re: iwm: fix RF_KILL interrupt handling

2019-04-01 Thread Stefan Sperling
On Mon, Apr 01, 2019 at 10:17:22AM +0200, Klemens Nanni wrote: > Index: if_iwm.c > === > RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v > retrieving revision 1.237 > diff -u -p -r1.237 if_iwm.c > --- if_iwm.c 27 Feb 2019 07:47:57 -

iwm: enable RF_KILL interrupts on resume

2019-04-01 Thread Klemens Nanni
As promised in my earlier mail, here's a diff that fixes seemless operation with the hardware kill switch on resume after suspend. Like the interrupt handler, the resume path needs to check the register to update flags in order to propagate the hardware kill switch state, otherwise the driver

iwm: fix RF_KILL interrupt handling

2019-04-01 Thread Klemens Nanni
Coming from an UP and RUNNING interface, turning off the hardware kill switch removes the RUNNING flag and powers down the device. Iff still UP, switching it back on should set RUNNING again to ensure seemless operation at runtime. We can do this by fixing the interrupt handler which currently

Re: Removing PF

2019-04-01 Thread Tom Smyth
Yeah... i would love you all to give affect to that... +1 from me claudioabout time!... Thanks for articulating what i have been thinking all this time... 1/4/2019 will be a historic turning point for us On Monday, 1 April 2019, Claudio Jeker wrote: > There have been internal

Re: Removing PF

2019-04-01 Thread Janne Johansson
Den mån 1 apr. 2019 kl 07:30 skrev Ian McWilliam < i.mcwill...@westernsydney.edu.au>: > "peeing on, or even integration into baby mulching > machines or atomic bombs to be dropped on Australia" > That's a lot of missing features to implement in one release cycle. > > I would like the license

Re: improve rsync(1) manual page

2019-04-01 Thread Theo de Raadt
Christian Weisgerber wrote: > > * Remove excessive verbosity from -g and -o, and improve precision: > > I find "Set the group name to match the source" incomprehensible. > The example given in the previous text may be unelegant, but it helps > me understand what this actually does, Yes,

Re: improve rsync(1) manual page

2019-04-01 Thread Christian Weisgerber
Ingo Schwarze: > here are serveral bugfixes and improvements for the rsync(1) manual. > > OK? ok I have some comments, but I think you should commit this. Further tweaks can follow later. > Missing information: > * Change the misleading argument placeholder "portnumber" to "service"; >