Re: GRE datagram socket support

2020-01-21 Thread Theo de Raadt
David Gwynne wrote: > > On 22 Jan 2020, at 8:54 am, Damien Miller wrote: > > > > On Wed, 22 Jan 2020, David Gwynne wrote: > > > >>> Index: sys/kern/kern_pledge.c > >>> === > >>> RCS file: /cvs/src/sys/kern/kern_pledge.c,v > >>> re

Re: GRE datagram socket support

2020-01-21 Thread David Gwynne
> On 22 Jan 2020, at 8:54 am, Damien Miller wrote: > > On Wed, 22 Jan 2020, David Gwynne wrote: > >>> Index: sys/kern/kern_pledge.c >>> === >>> RCS file: /cvs/src/sys/kern/kern_pledge.c,v >>> retrieving revision 1.255 >>> diff -u

Re: GRE datagram socket support

2020-01-21 Thread Theo de Raadt
I am a big grumpy about /etc/protocols becoming another file that is bypassed (accepted transparently) in kernel pledge. but dlg has convinced me hardcoding would be worse.

Re: GRE datagram socket support

2020-01-21 Thread YASUOKA Masahiko
Hi, I think that is a good idea. On Wed, 22 Jan 2020 08:35:05 +1000 David Gwynne wrote: > Has anyone got an opinion on this? I am still interested in doing more > packet capture things on OpenBSD using GRE as a transport, and the idea > of maintaining this out of tree just makes me feel tired. >

Re: GRE datagram socket support

2020-01-21 Thread Damien Miller
On Wed, 22 Jan 2020, David Gwynne wrote: > Has anyone got an opinion on this? I am still interested in doing more > packet capture things on OpenBSD using GRE as a transport, and the idea > of maintaining this out of tree just makes me feel tired. This is cool. I don't spot any major problems wit

Re: GRE datagram socket support

2020-01-21 Thread David Gwynne
Has anyone got an opinion on this? I am still interested in doing more packet capture things on OpenBSD using GRE as a transport, and the idea of maintaining this out of tree just makes me feel tired. On Tue, Oct 29, 2019 at 06:34:50PM +1000, David Gwynne wrote: > i've been toying with this idea o

GRE datagram socket support

2019-10-29 Thread David Gwynne
i've been toying with this idea of implementing GRE as a datagram protocol that userland can use just like UDP. the idea is to make it easy to support the implementation of NHRP in userland for mgre(4), and also for ERSPAN* support without going down the path linux took**. so this is the result of