Re: cert.pem: Re-add mistakenly removed GlobalSign R2

On 2016/12/14 13:19, Steven McDonald wrote: > It looks like revision 1.10 of cert.pem (which was intended only to > sort the contents of the file) accidentally removed the GlobalSign R2 > CA -- probably because it has the same CN as the R3 CA. The CN is used > as a hash key in the script used for

Re: ospfd - handling mtu changes

On Mon, Dec 05, 2016 at 06:06:42PM +0100, Remi Locherer wrote: > On Tue, Nov 29, 2016 at 12:14:40PM +0100, Jeremie Courreges-Anglas wrote: > > Remi Locherer writes: > > > > > On Sat, Nov 26, 2016 at 09:39:40AM +0100, Jeremie Courreges-Anglas wrote: > > >> Remi Locherer

Re: global mbuf memory limit

> On 22 Nov 2016, at 21:20, Mark Kettenis wrote: > >> Date: Tue, 22 Nov 2016 12:42:39 +1000 >> From: David Gwynne >> >> right now pools that make up mbufs are each limited individually. >> >> the following diff instead has the mbuf layer have a

cert.pem: Re-add mistakenly removed GlobalSign R2

It looks like revision 1.10 of cert.pem (which was intended only to sort the contents of the file) accidentally removed the GlobalSign R2 CA -- probably because it has the same CN as the R3 CA. The CN is used as a hash key in the script used for sorting

Re: ripd(8) fails on P2P links

Piotr Durlej writes: [...] > Any thoughts? Is the patch ok, wrong, accepted, rejected or unnoticed? Your diff wouldn't apply because of mangled whitespace (please don't copy/paste diffs). Here's an updated diff below (untested). Index: packet.c

Re: ripd(8) fails on P2P links

On 2016-12-06 00:12, Piotr Durlej wrote: Hi, I dislike cross-posting/repeated posting but I was advised to do so by mpi@. I just want to make sure my previous mail sent to bugs@ hasn't gone unnoticed. The problem is that ripd(8) is unable to determine the interface on which a RIP packet was

Re: arm64: add efibind header for efiboot(8)

On Tue, 13 Dec 2016 18:06:11 +0100, Patrick Wildt wrote: > Turns out, the copyright seems to be bad. This version is taken from > tianocore/edk2, modified to work with our efiboot(8) checkout. Great, thanks. > The diff to the arm efibind header is comparatively small now. Even better. OK

Re: arm64: add efibind header for efiboot(8)

On Tue, Dec 13, 2016 at 05:32:38PM +0100, Patrick Wildt wrote: > Hi, > > this diff adds the efibind header that will be used for the upcoming > OpenBSD/arm64 port. > > Taken from FreeBSD, extended by two OpenBSD ifdefs. > > ok? > > Patrick > Turns out, the copyright seems to be bad. This

Re: Fix for /32 cloning route

On Tue, Dec 13, 2016 at 10:02:21AM +0100, Martin Pieuchot wrote: > Hence the fix below that use a higher priority for cloned routes. > ok? OK bluhm@ > > Index: net/route.c > === > RCS file: /cvs/src/sys/net/route.c,v > retrieving

Re: arm64: add efibind header for efiboot(8)

> The copyright notice says there is a license but doesn't specify > what the license is. In constrast, sys/stand/efi/include/arm/efibind.h > explicitly states it is under the BSD license and provides a link > to the license text. > > I guess this is the same as

Re: arm64: add efibind header for efiboot(8)

The copyright notice says there is a license but doesn't specify what the license is. In constrast, sys/stand/efi/include/arm/efibind.h explicitly states it is under the BSD license and provides a link to the license text. I guess this is the same as sys/stand/efi/include/amd64/efibind.h so it

arm64: add efibind header for efiboot(8)

Hi, this diff adds the efibind header that will be used for the upcoming OpenBSD/arm64 port. Taken from FreeBSD, extended by two OpenBSD ifdefs. ok? Patrick diff --git a/sys/stand/efi/include/arm64/efibind.h b/sys/stand/efi/include/arm64/efibind.h new file mode 100644 index

Re: BFD: route get and route monitor

On 2016 Dec 05 (Mon) at 15:39:31 +0100 (+0100), Peter Hessler wrote: :On 2016 Sep 30 (Fri) at 10:16:19 +0200 (+0200), Peter Hessler wrote: ::This diff makes route get and route monitor work. sockaddr_bfd is so we ::can play like the other RTAX_* indexes in rti_info of route messages. :: ::OK? ::

dhcrelay(8): allow multiple interfaces on l2

This diff implements support for allowing dhcrelay(8) to run on multiple source interfaces with just one instance when using layer 2. This is useful if you want to run dhcrelay(8) on multiple interfaces and want to use the same circuit-id/remote-id (e.g. have multiple vlan(4)s on the same

Re: bpf_mtap(9) w/o KERNEL_LOCK

On Mon, Dec 12, 2016 at 03:22:36PM +0100, Martin Pieuchot wrote: > @@ -56,15 +56,17 @@ struct bpf_d { ... > - struct bpf_if * bd_bif; /* interface descriptor */ > + int __in_uiomove; > + > + struct bpf_if *bd_bif; /* interface descriptor */ If __in_uiomove

Re: dhcrelay(8): fix default layer 3 remote-id

I think that matches the previous behaviour, OK reyk > On 13.12.2016, at 15:10, Rafael Zalamena wrote: > > After the many iterations of the layer 2 diff, I noticed I broke the > layer 3 default Relay Agent Information insertion: the relayed packet is > using the wrong

dhcrelay(8): fix default layer 3 remote-id

After the many iterations of the layer 2 diff, I noticed I broke the layer 3 default Relay Agent Information insertion: the relayed packet is using the wrong address in the remote-id field. This diff makes the Relay Agent Information init function to run later and get the right address for the

Re: [patch]: Make ip4 mcast membership data structure similar to ip6

Hello, On 10/12/16(Sat) 11:08, Dimitris Papastamos wrote: > While I was playing around with the ip4 multicast code, I thought > I would attempt to make the membership data structure similar to that > of ip6. This means changing from a dynamic array to a linked list. I like this a lot.

Re: ifconfig: print netmask in CIDR notation

On 13/12/16(Tue) 11:32, Reyk Floeter wrote: > [...] > Simple reasons: this is a different discussion or diff. If we would > want to remove non-contiguous netmasks completely, it should be done > in the stack. Until then, it is better that ifconfig can cope with > them. The stack no longer

Re: ifconfig: print netmask in CIDR notation

On Tue, Dec 13, 2016 at 10:13:32AM +, Stuart Henderson wrote: > On 2016/12/13 10:51, Reyk Floeter wrote: > > printing the netmask in hex seems to be a historical artifact in ifconfig; > > I always wondered about it and I never got used to it. > > > > The following diff changes ifconfig output

Re: ifconfig: print netmask in CIDR notation

On 2016/12/13 10:51, Reyk Floeter wrote: > printing the netmask in hex seems to be a historical artifact in ifconfig; > I always wondered about it and I never got used to it. > > The following diff changes ifconfig output to print contiguous > netmasks in CIDR notation. Non-contiguous netmasks

Re: ifconfig: print netmask in CIDR notation

On Tue, Dec 13, 2016 at 10:58:28AM +0100, Mark Kettenis wrote: > > Date: Tue, 13 Dec 2016 10:51:40 +0100 > > From: Reyk Floeter > > > > Hi, > > > > printing the netmask in hex seems to be a historical artifact in ifconfig; > > I always wondered about it and I never got used to

Re: ifconfig: print netmask in CIDR notation

> Date: Tue, 13 Dec 2016 10:51:40 +0100 > From: Reyk Floeter > > Hi, > > printing the netmask in hex seems to be a historical artifact in ifconfig; > I always wondered about it and I never got used to it. > > The following diff changes ifconfig output to print contiguous >

ifconfig: print netmask in CIDR notation

Hi, printing the netmask in hex seems to be a historical artifact in ifconfig; I always wondered about it and I never got used to it. The following diff changes ifconfig output to print contiguous netmasks in CIDR notation. Non-contiguous netmasks will still be printed in full, tunnels will

Fix for /32 cloning route

jsing@ and matthew@ reported a problem with /32 cloning routes, used at least on Google Compute Engine. The problem is that when I have the following routing table, no route can be clone from 10.128.0.1/32: 10.128.0.1/32 10.128.0.3 UCS10 - 8 vio0 10.128.0.3

Re: stop letting interface up/down fail silently

On 13/12/16(Tue) 17:01, David Gwynne wrote: > at the moment if ifconfig foo0 up fails, nothing says so because > the kernel doesnt propagate the return code from the IFFLAGS ioctl > back to userland. > > it also reports a link state change before it actually tries to > bring the interface up or