Re: Some tweaks for smfb(4)

[Frederic Cambus]

On Mon, Dec 19, 2016 at 12:21:54PM +0100, Mark Kettenis wrote:

> > Here is a diff with some tweaks for smfb(4):
> > 
> > - Display resolution and color depth when attaching
> 
> We should try to do so in a uniform way though.  None of our drivers
> print the words "frame buffer".  Most of them only print the
> resolution, but I can see the additional value of printing the depth
> as well.  Perhaps we should do that for the other framebuffers as well.

All other frame buffer drivers on Loongson (radeonfb and sisfb) print
it this way, that's why I used the same scheme here. It seems sgi
drivers also do it this way.

I'm all for trying to do things in an uniform way though, and find the
formatting used by efifb(4) possibly better: ": %dx%d, %dbpp\n". Any
thoughts on this?

> > - Do not hardcode 'wantrows' and 'wantcols' when calling rasops_init
> 
> That is undesirable.  The whole idea here is to put some fixed limits
> on the number of rows and colums such that the lines don't get
> insanely long and scrolling doesn't get too slow because the number of
> rows is ridiculously large.
> 
> If you are concerned about the framebuffer console only using a
> limited part of the screen, see my reply to reyk@ from last week.

In this case, the opposite: smfb assumes a fixed 1024x600 or 800x480
resolution so the hardcoded values are too large. On sgi, some drivers
divide screen width and height by the size of the smallest possible
usable font (8x8), so that was the idea.

> Basically, we need to add a bigger console font.

That makes sense, and this is something I'm interested in working on.
I recently imported psftools in ports to be able to start converting
some fonts and started experimenting.

Re: ripd(8) use after free

[Jeremie Courreges-Anglas]

Claudio Jeker  writes:

> On Fri, Dec 23, 2016 at 04:16:11PM +0100, Jeremie Courreges-Anglas wrote:
>> 
>> In the neighbor fsm, NBR_ACT_DEL frees the neighbor structure.  But
>> fields of this structure are later accessed, this is mostly visible with
>> debug output:
>> 
>> nbr_del: neighbor ID 10.64.55.33, peerid 3
>> nbr_fsm: event 'RESPONSE SENT' resulted in action 'DELETE NBR' and changing 
>> state for neighbor ID 223.223.223.223 from 'ACTIVE' to 'DOWN'
>> 
>> 223 is decimal for 0xdf (chunks freed by malloc).
>> 
>> The diff below moves the code around to avoid using free'd memory.
>> I couldn't spot a dependency between the switch code and the "new
>> state" code.
>> 
>> ok?
>> 
>
> I would prefer if we keep this similar to ospfd and instead use an
> inactivity timer to do the free. Another option would be an early return.

Agreed.  An early return looked a bit ugly, and using the inactivity
timer looked consistent with ospfd, so let nbr_act_del() only schedule
the actual deletion.  ACTIVE->DOWN->ACTIVE and ACTIVE->DOWN->*removed*
seem to work as expected.

What bothers me is that right now NBR_EVT_TIMEOUT is only valid in state
NBR_STA_ACTIVE.  Shouldn't it be allowed in state NBR_STA_REQ_RCVD too,
just in case(tm)?

While here, kill a dead decl in ospfe.h.


Index: interface.c
===
RCS file: /d/cvs/src/usr.sbin/ripd/interface.c,v
retrieving revision 1.13
diff -u -p -r1.13 interface.c
--- interface.c 27 Sep 2015 17:32:36 -  1.13
+++ interface.c 27 Dec 2016 23:32:14 -
@@ -467,7 +467,7 @@ if_del(struct iface *iface)
 
/* clear lists etc */
while ((nbr = LIST_FIRST(>nbr_list)) != NULL)
-   nbr_act_del(nbr);
+   nbr_del(nbr);
 
/* XXX rq_list, rp_list */
 
Index: neighbor.c
===
RCS file: /d/cvs/src/usr.sbin/ripd/neighbor.c,v
retrieving revision 1.10
diff -u -p -r1.10 neighbor.c
--- neighbor.c  18 Jul 2016 21:20:31 -  1.10
+++ neighbor.c  27 Dec 2016 23:40:40 -
@@ -203,6 +203,21 @@ nbr_new(u_int32_t nbr_id, struct iface *
 }
 
 void
+nbr_del(struct nbr *nbr)
+{
+   log_debug("nbr_del: neighbor ID %s, peerid %u", inet_ntoa(nbr->id),
+   nbr->peerid);
+
+   /* stop timer */
+   nbr_stop_timer(nbr);
+
+   LIST_REMOVE(nbr, entry);
+   LIST_REMOVE(nbr, hash);
+
+   free(nbr);
+}
+
+void
 nbr_act_del(struct nbr *nbr)
 {
/* If there is no authentication or it is just a route request
@@ -211,20 +226,15 @@ nbr_act_del(struct nbr *nbr)
nbr->state != NBR_STA_REQ_RCVD)
nbr_failed_new(nbr);
 
-   log_debug("nbr_del: neighbor ID %s, peerid %u", inet_ntoa(nbr->id),
+   log_debug("nbr_act_del: neighbor ID %s, peerid %u", inet_ntoa(nbr->id),
nbr->peerid);
 
-   /* stop timer */
-   nbr_stop_timer(nbr);
+   /* schedule kill timer */
+   nbr_set_timer(nbr);
 
/* clear lists */
clear_list(>rq_list);
clear_list(>rp_list);
-
-   LIST_REMOVE(nbr, entry);
-   LIST_REMOVE(nbr, hash);
-
-   free(nbr);
 }
 
 struct nbr *
@@ -316,7 +326,10 @@ nbr_timeout_timer(int fd, short event, v
 {
struct nbr *nbr = arg;
 
-   nbr_fsm(nbr, NBR_EVT_TIMEOUT);
+   if (nbr->state == NBR_STA_DOWN)
+   nbr_del(nbr);
+   else
+   nbr_fsm(nbr, NBR_EVT_TIMEOUT);
 }
 
 /* ARGSUSED */
Index: ripe.h
===
RCS file: /d/cvs/src/usr.sbin/ripd/ripe.h,v
retrieving revision 1.11
diff -u -p -r1.11 ripe.h
--- ripe.h  25 Oct 2014 03:23:49 -  1.11
+++ ripe.h  27 Dec 2016 23:32:42 -
@@ -128,7 +128,7 @@ void md_list_clr(struct auth_md_head *)
 /* neighbor.c */
 voidnbr_init(u_int32_t);
 struct nbr *nbr_new(u_int32_t, struct iface *);
-voidnbr_act_del(struct nbr *);
+voidnbr_del(struct nbr *);
 
 struct nbr *nbr_find_ip(struct iface *, u_int32_t);
 struct nbr *nbr_find_peerid(u_int32_t);
@@ -137,7 +137,7 @@ void nbr_failed_delete(struct 
nbr_fai
 
 int nbr_fsm(struct nbr *, enum nbr_event);
 voidnbr_timeout_timer(int, short, void *);
-voidnbr_act_delete(struct nbr *);
+voidnbr_act_del(struct nbr *);
 
 const char *nbr_event_name(int);
 const char *nbr_action_name(int);

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: Build kernels with -ffreestanding?

[Martin Pieuchot]

On 28/12/16(Wed) 01:05, Jeremie Courreges-Anglas wrote:
> Mark Kettenis  writes:
> 
> >> Date: Sat, 24 Dec 2016 00:08:35 +0100 (CET)
> >> From: Mark Kettenis 
> >> 
> >> We already do this on some architectures, but not on amd64 for
> >> example.  The main reason is that this disables memcpy() optimizations
> >> that have a measurable impact on the network stack performance.
> >> 
> >> We can get those optimizations back by doing:
> >> 
> >> #define memcpy(d, s, n) __builtin_memcpy((d), (s), (n))
> >> 
> >> I verified that gcc still does proper bounds checking on
> >> __builtin_memcpy(), so we don't lose that.
> >> 
> >> The nice thing about this solution is that we can choose explicitly
> >> which optimizations we want.  And as you can see the kernel makefile
> >> gets simpler ;).
> >> 
> >> Of course the real reason why I'm looking into this is that clang
> >> makes it really hard to build kernels without -ffreestanding.
> >> 
> >> The diff below implements this strategy, and enabled the optimizations
> >> for memcpy() and memset().  We can add others if we think there is a
> >> benefit.  I've tested the diff on amd64.  We may need to put an #undef
> >> memcpy somewhere for platforms that use the generic C code for memcpy.
> >> 
> >> Thoughts?
> >
> > So those #undefs are necessary.  New diff below.  Tested on armv7,
> > hppa and sparc64 now as well.
> 
> I think this is the way to go; can't help tests on other archs, though.
> ok jca@ fwiw

For the archives, Hrvoje Popovski measured a performance impact when using
a kernel with this diff to forward packets.  I guess we're missing some
defines.

Re: Build kernels with -ffreestanding?

[Jeremie Courreges-Anglas]

Mark Kettenis  writes:

>> Date: Sat, 24 Dec 2016 00:08:35 +0100 (CET)
>> From: Mark Kettenis 
>> 
>> We already do this on some architectures, but not on amd64 for
>> example.  The main reason is that this disables memcpy() optimizations
>> that have a measurable impact on the network stack performance.
>> 
>> We can get those optimizations back by doing:
>> 
>> #define memcpy(d, s, n) __builtin_memcpy((d), (s), (n))
>> 
>> I verified that gcc still does proper bounds checking on
>> __builtin_memcpy(), so we don't lose that.
>> 
>> The nice thing about this solution is that we can choose explicitly
>> which optimizations we want.  And as you can see the kernel makefile
>> gets simpler ;).
>> 
>> Of course the real reason why I'm looking into this is that clang
>> makes it really hard to build kernels without -ffreestanding.
>> 
>> The diff below implements this strategy, and enabled the optimizations
>> for memcpy() and memset().  We can add others if we think there is a
>> benefit.  I've tested the diff on amd64.  We may need to put an #undef
>> memcpy somewhere for platforms that use the generic C code for memcpy.
>> 
>> Thoughts?
>
> So those #undefs are necessary.  New diff below.  Tested on armv7,
> hppa and sparc64 now as well.

I think this is the way to go; can't help tests on other archs, though.
ok jca@ fwiw

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: clean up iwm task queue mess

[Stefan Sperling]

On Mon, Dec 26, 2016 at 12:50:31PM +0100, Mark Kettenis wrote:
> > Date: Mon, 26 Dec 2016 09:13:50 +0100
> > From: Stefan Sperling 
> > 
> > I do not see a good reason for using multiple custom task queues
> > in this driver, and at the same time it is using systq for tasks.
> > 
> > This moves all tasks to one custom queue to make things consistent.
> > Except I'm leaving the init_task on systq because this task is kind
> > of special (e.g. it might be added during resume and I'm not sure
> > if that requires IPL_HIGH).
> > Perhaps the custom queue would be fine for init_task, too? Not sure.
> 
> Are you certain you don't need work times to be processed while
> processing other work items.  For example, to process state
> transitions while scanning?  Using a single taskq could lead to a
> deadlock in that case...

I have seen no such issue during testing.

This driver does not follow SCAN->SCAN transitions at all. These transitions
are triggered by timeouts when the net80211 stack wants to switch channels.
Because channel switiching is handled in firmware the driver handles such
transitions as a no-op.

Sharing a task queue means that event handlers will be run in the same order
they were triggered. I hope this might fix some problems such as "could not
initiate scan" which some people have been reporting. I have no evidence
support this yet, though.

Re: handle non-standard 11n APs better

[Gregor Best]

On Tue, Dec 27, 2016 at 01:00:54AM +0100, Gregor Best wrote:
> On Mon, Dec 26, 2016 at 08:44:47PM +0100, Stefan Sperling wrote:
> > [...]
> > E.g. at 33C3 there are APs with: RxMCS 0xf8f8f800
> > 
> > The diff below makes OpenBSD clients work in 11n mode on such networks
> > by relaxing our "supported MCS" 11n feature check.
> > [...]
> 
> To go along with the 33c3 motto: "Works for me". Thanks a lot :)
> [...]

Looks like I spoke a bit too soon. The card associates and can receive
IPv6 router advertisements, but that seems to be it. I don't receive
replies to DHCP requests and statically configuring an address doesn't
yield a working connection either.

A PCAP file I captured with

tcpdump -y IEEE802_11 -ni iwm0 -w /tmp/nw.pcap

is at [0]. The output of ifconfig and a dmesg follows. The kernel is
one built from a CVS checkout from 0100 this morning.

Is this related to an AP with weird 11n handling at all?

-- 
Gregor

$ ifconfig iwm0
iwm0: flags=208843 mtu 1500
lladdr e4:a4:71:e1:45:79
index 2 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (OFDM18 mode 11a)
status: active
ieee80211: nwid 33C3-open chan 48 bssid 04:bd:88:62:96:91 65%
inet6 fe80::e6a4:71ff:fee1:4579%iwm0 prefixlen 64 scopeid 0x2
inet6 2001:67c:20a1:1192:e6a4:71ff:fee1:4579 prefixlen 64 autoconf 
pltime 0 vltime 3600
inet6 2001:67c:20a1:1192:8831:5f1e:f152:8cf3 prefixlen 64 deprecated 
autoconf autoconfprivacy pltime 0 vltime 3161
inet6 2001:67c:20a1:1192:2c51:2f3:5efe:5361 prefixlen 64 autoconf 
autoconfprivacy pltime 0 vltime 3464

$ dmesg

OpenBSD 6.0-current (GENERIC.MP) #54: Tue Dec 27 00:55:34 CET 2016
g...@sputnik.unobtanium.de:/usr/obj/sys/arch/amd64/compile/GENERIC.MP
real mem = 17078013952 (16286MB)
avail mem = 16554639360 (15787MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x87ed7000 (44 entries)
bios0: vendor American Megatrends Inc. version "5.11" date 08/29/2016
bios0: Notebook N24_25JU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT SSDT DBGP DBG2 SSDT UEFI 
SSDT BGRT DMAR TPM2 ASF!
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PXSX(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) RP19(S4) PXSX(S4) RP20(S4) 
PXSX(S4) RP01(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2694.51 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2693.75 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2693.75 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2693.75 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu3: 256KB 

Re: handle non-standard 11n APs better

[Stefan Sperling]

On Tue, Dec 27, 2016 at 12:31:36PM +0100, Gregor Best wrote:
> On Tue, Dec 27, 2016 at 01:00:54AM +0100, Gregor Best wrote:
> > On Mon, Dec 26, 2016 at 08:44:47PM +0100, Stefan Sperling wrote:
> > > [...]
> > > E.g. at 33C3 there are APs with: RxMCS 0xf8f8f800
> > > 
> > > The diff below makes OpenBSD clients work in 11n mode on such networks
> > > by relaxing our "supported MCS" 11n feature check.
> > > [...]
> > 
> > To go along with the 33c3 motto: "Works for me". Thanks a lot :)
> > [...]
> 
> Looks like I spoke a bit too soon. The card associates and can receive
> IPv6 router advertisements, but that seems to be it. I don't receive
> replies to DHCP requests and statically configuring an address doesn't
> yield a working connection either.
> 
> A PCAP file I captured with
> 
>   tcpdump -y IEEE802_11 -ni iwm0 -w /tmp/nw.pcap
> 
> is at [0]. The output of ifconfig and a dmesg follows. The kernel is
> one built from a CVS checkout from 0100 this morning.
> 
> Is this related to an AP with weird 11n handling at all?

Not sure. Are you forcing 11a mode, by chance?

When it works it looks like this:
media: IEEE802.11 autoselect (HT-MCS14 mode 11n)
status: active
ieee80211: nwid 33C3-open chan 100 bssid ac:a3:1e:e5:e3:f1 73%

I've talked to the NOC folks last night. They're doing some crazy things to
steer clients between APs and it's not entirely clear how OpenBSD clients
will respond to that.

If you can't get it to work, try to find me at the BSD assembly or at
coffee nerds, and we can debug it together.

Re: autoinstall failure

[Pedro Caetano]

Yet another update on this matter.

I have 6 vms running on the same host.
All the vms have same virtual hardware configured.
.

There is 2 vm where auto upgrade always works.
There are 4 vm where auto upgrade fails, forcing auto upgrade (A) also
fails. Using regular upgrade (u) works.

BR,
Pedro Caetano

On Mon, Dec 26, 2016 at 11:15 AM, Pedro Caetano <
pedrocaet...@binaryflows.com> wrote:

> Hi,
>
> Forcing autoinstall indeed does work. Thank you for the hint.
>
> I just noticed that one other vm running on this host, never seems to
> suffer from this issue. (autoinstall just works)
> No obvious difference in the vm specs nor answer files.
>
> Best regards,
> Pedro Caetano
>
>
>
> On Mon, Dec 26, 2016 at 1:39 AM, Raf Czlonka  wrote:
>
>> On Sun, Dec 25, 2016 at 02:33:36PM GMT, Pedro Caetano wrote:
>> > Starting on the 9th december the autoupgrade process is no longer
>> sucessful
>> > the ai.log is the following:
>> > Choose your keyboard layout (`?` or `L` for list) [default] default
>> > Available disks are: sd0.
>> > Which disk is the root disk? (`?` for details) [sd0] sd0
>> > Checking root filesystem (fsck -fp /dev/sd0a)...OK.
>> > Mounting root filesystem (mount -o ro /dev/sd0a /mnt)...OK.
>> > Force checking of clean non-root filesystems? [no] no
>> > umount: /mnt: Device busy
>> > Can't umount sd0a!
>>
>> FWIW, I got the same error message regarding busy /mnt recently on
>> a physical box.
>>
>> > The release sets, bsd, bsd.rd and pxeboot are built feching sources from
>> > CVS daily. (last build from 25th december)
>>
>> I use daily snapshots.
>>
>> > This bug is not always reproducible. If one restarts the vm, eventually
>> the
>> > installer will proceed sucessfully.
>>
>> Thus far, I had seen the error once.
>>
>> I simply triggered autoupgrade manually from (I)nstall, (U)pgrade,
>> (A)uto* prompt.
>>
>> auto_upgrade.conf:
>>
>> Location of sets = disk
>> Is the disk partition already mounted = yes
>> Pathname to the sets = /snapshots/amd64
>>
>> dmesg:
>>
>> OpenBSD 6.0-current (GENERIC.MP) #71: Fri Dec 23 12:08:23 MST 2016
>> bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> RTC BIOS diagnostic error 1f
>> real mem = 8473620480 (8081MB)
>> avail mem = 8212148224 (7831MB)
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x8ad14000 (63 entries)
>> bios0: vendor Apple Inc. version "MBP91.88Z.00D3.B0D.1602221713" date
>> 02/22/2016
>> bios0: Apple Inc. MacBookPro9,2
>> acpi0 at bios0: rev 2
>> acpi0: sleep states S0 S3 S4 S5
>> acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT
>> SSDT SSDT SSDT SSDT SSDT DMAR MCFG
>> acpi0: wakeup devices P0P2(S3) PEG1(S3) EC__(S4) GMUX(S3) HDEF(S3)
>> RP01(S3) GIGE(S3) SDXC(S3) RP02(S3) ARPT(S3) RP03(S3) EHC1(S3) EHC2(S3)
>> XHC1(S3) ADP1(S4) LID0(S4)
>> acpitimer0 at acpi0: 3579545 Hz, 24 bits
>> acpihpet0 at acpi0: 14318179 Hz
>> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>> cpu0 at mainbus0: apid 0 (boot processor)
>> cpu0: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.68 MHz
>> cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMO
>> V,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,
>> SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTP
>> R,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,
>> AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
>> cpu0: 256KB 64b/line 8-way L2 cache
>> cpu0: TSC frequency 2494679160 <(249)%20467-9160> Hz
>> cpu0: smt 0, core 0, package 0
>> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
>> cpu0: apic clock running at 99MHz
>> cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
>> cpu1 at mainbus0: apid 2 (application processor)
>> cpu1: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.34 MHz
>> cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMO
>> V,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,
>> SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTP
>> R,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,
>> AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
>> cpu1: 256KB 64b/line 8-way L2 cache
>> cpu1: smt 0, core 1, package 0
>> cpu2 at mainbus0: apid 1 (application processor)
>> cpu2: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.34 MHz
>> cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMO
>> V,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,
>> SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTP
>> R,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,
>> AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
>> cpu2: 256KB 64b/line 8-way L2 cache
>> cpu2: smt 1, core 0, package 0
>> cpu3 at mainbus0: apid 3 (application processor)
>> cpu3: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.34 MHz
>> cpu3: 

Re: ripd(8) use after free

[Claudio Jeker]

On Fri, Dec 23, 2016 at 04:16:11PM +0100, Jeremie Courreges-Anglas wrote:
> 
> In the neighbor fsm, NBR_ACT_DEL frees the neighbor structure.  But
> fields of this structure are later accessed, this is mostly visible with
> debug output:
> 
> nbr_del: neighbor ID 10.64.55.33, peerid 3
> nbr_fsm: event 'RESPONSE SENT' resulted in action 'DELETE NBR' and changing 
> state for neighbor ID 223.223.223.223 from 'ACTIVE' to 'DOWN'
> 
> 223 is decimal for 0xdf (chunks freed by malloc).
> 
> The diff below moves the code around to avoid using free'd memory.
> I couldn't spot a dependency between the switch code and the "new
> state" code.
> 
> ok?
> 

I would prefer if we keep this similar to ospfd and instead use an
inactivity timer to do the free. Another option would be an early return.

> 
> Index: neighbor.c
> ===
> RCS file: /d/cvs/src/usr.sbin/ripd/neighbor.c,v
> retrieving revision 1.10
> diff -u -p -p -u -r1.10 neighbor.c
> --- neighbor.c18 Jul 2016 21:20:31 -  1.10
> +++ neighbor.c23 Dec 2016 15:05:20 -
> @@ -116,21 +116,6 @@ nbr_fsm(struct nbr *nbr, enum nbr_event 
>   return (0);
>   }
>  
> - switch (nbr_fsm_tbl[i].action) {
> - case NBR_ACT_RST_TIMER:
> - nbr_set_timer(nbr);
> - break;
> - case NBR_ACT_STRT_TIMER:
> - nbr_set_timer(nbr);
> - break;
> - case NBR_ACT_DEL:
> - nbr_act_del(nbr);
> - break;
> - case NBR_ACT_NOTHING:
> - /* do nothing */
> - break;
> - }
> -
>   if (new_state != 0)
>   nbr->state = new_state;
>  
> @@ -145,6 +130,21 @@ nbr_fsm(struct nbr *nbr, enum nbr_event 
>   nbr_action_name(nbr_fsm_tbl[i].action),
>   inet_ntoa(nbr->id), nbr_state_name(old_state),
>   nbr_state_name(nbr->state));
> + }
> +
> + switch (nbr_fsm_tbl[i].action) {
> + case NBR_ACT_RST_TIMER:
> + nbr_set_timer(nbr);
> + break;
> + case NBR_ACT_STRT_TIMER:
> + nbr_set_timer(nbr);
> + break;
> + case NBR_ACT_DEL:
> + nbr_act_del(nbr);
> + break;
> + case NBR_ACT_NOTHING:
> + /* do nothing */
> + break;
>   }
>  
>   return (0);
> 
> 
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> 

-- 
:wq Claudio

Re: ospf6d: remove struct rroute

[Claudio Jeker]

On Tue, Dec 27, 2016 at 02:55:08PM +0100, Jeremie Courreges-Anglas wrote:
> 
> struct rroute has ben removed from ospfd some time ago.  struct kroute
> takes an additional 'metric' field.
> 

Reads good. OK claudio@

> 
> Index: kroute.c
> ===
> RCS file: /d/cvs/src/usr.sbin/ospf6d/kroute.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 kroute.c
> --- kroute.c  22 Dec 2016 23:01:58 -  1.49
> +++ kroute.c  27 Dec 2016 13:45:35 -
> @@ -51,12 +51,12 @@ struct {
>  
>  struct kroute_node {
>   RB_ENTRY(kroute_node)entry;
> - struct krouter;
>   struct kroute_node  *next;
> + struct krouter;
>  };
>  
>  void kr_redist_remove(struct kroute_node *, struct kroute_node *);
> -int  kr_redist_eval(struct kroute *, struct rroute *);
> +int  kr_redist_eval(struct kroute *, struct kroute *);
>  void kr_redistribute(struct kroute_node *);
>  int  kroute_compare(struct kroute_node *, struct kroute_node *);
>  
> @@ -344,7 +344,7 @@ kr_show_route(struct imsg *imsg)
>  void
>  kr_redist_remove(struct kroute_node *kh, struct kroute_node *kn)
>  {
> - struct rrouterr;
> + struct kroute*kr;
>  
>   /* was the route redistributed? */
>   if ((kn->r.flags & F_REDISTRIBUTED) == 0)
> @@ -352,8 +352,7 @@ kr_redist_remove(struct kroute_node *kh,
>  
>   /* remove redistributed flag */
>   kn->r.flags &= ~F_REDISTRIBUTED;
> - rr.kr = kn->r;
> - rr.metric = DEFAULT_REDIST_METRIC;  /* some dummy value */
> + kr = >r;
>  
>   /* probably inform the RDE (check if no other path is redistributed) */
>   for (kn = kh; kn; kn = kn->next)
> @@ -361,12 +360,12 @@ kr_redist_remove(struct kroute_node *kh,
>   break;
>  
>   if (kn == NULL)
> - main_imsg_compose_rde(IMSG_NETWORK_DEL, 0, ,
> - sizeof(struct rroute));
> + main_imsg_compose_rde(IMSG_NETWORK_DEL, 0, kr,
> + sizeof(struct kroute));
>  }
>  
>  int
> -kr_redist_eval(struct kroute *kr, struct rroute *rr)
> +kr_redist_eval(struct kroute *kr, struct kroute *new_kr)
>  {
>   u_int32_tmetric = 0;
>  
> @@ -411,9 +410,9 @@ kr_redist_eval(struct kroute *kr, struct
>* only one of all multipath routes can be redistributed so
>* redistribute the best one.
>*/
> - if (rr->metric > metric) {
> - rr->kr = *kr;
> - rr->metric = metric;
> + if (new_kr->metric > metric) {
> + *new_kr = *kr;
> + new_kr->metric = metric;
>   }
>  
>   return (1);
> @@ -431,26 +430,25 @@ void
>  kr_redistribute(struct kroute_node *kh)
>  {
>   struct kroute_node  *kn;
> - struct rrouterr;
> + struct kroutekr;
>   int  redistribute = 0;
>  
> - bzero(, sizeof(rr));
> - rr.metric = UINT_MAX;
> + bzero(, sizeof(kr));
> + kr.metric = UINT_MAX;
>   for (kn = kh; kn; kn = kn->next)
> - if (kr_redist_eval(>r, ))
> + if (kr_redist_eval(>r, ))
>   redistribute = 1;
>  
>   if (!redistribute)
>   return;
>  
> - if (rr.kr.flags & F_REDISTRIBUTED) {
> - main_imsg_compose_rde(IMSG_NETWORK_ADD, 0, ,
> - sizeof(struct rroute));
> + if (kr.flags & F_REDISTRIBUTED) {
> + main_imsg_compose_rde(IMSG_NETWORK_ADD, 0, ,
> + sizeof(struct kroute));
>   } else {
> - rr.metric = DEFAULT_REDIST_METRIC;  /* some dummy value */
> - rr.kr = kh->r;
> - main_imsg_compose_rde(IMSG_NETWORK_DEL, 0, ,
> - sizeof(struct rroute));
> + kr = kh->r;
> + main_imsg_compose_rde(IMSG_NETWORK_DEL, 0, ,
> + sizeof(struct kroute));
>   }
>  }
>  
> Index: ospf6d.h
> ===
> RCS file: /d/cvs/src/usr.sbin/ospf6d/ospf6d.h,v
> retrieving revision 1.30
> diff -u -p -r1.30 ospf6d.h
> --- ospf6d.h  2 Sep 2016 14:06:35 -   1.30
> +++ ospf6d.h  27 Dec 2016 13:45:35 -
> @@ -390,16 +390,12 @@ struct kroute {
>   struct in6_addr prefix;
>   struct in6_addr nexthop;
>   u_int32_t   ext_tag;
> + u_int32_t   metric;
>   unsigned intscope;  /* scope of nexthop */
>   u_int16_t   flags;
>   u_int16_t   rtlabel;
>   u_short ifindex;
>   u_int8_tprefixlen;
> -};
> -
> -struct rroute {
> - struct kroute   kr;
> - u_int32_t   metric;
>  };
>  
>  /* name2id */
> Index: rde.c
> ===
> RCS file: /d/cvs/src/usr.sbin/ospf6d/rde.c,v
> retrieving revision 1.68
> diff -u -p -r1.68 rde.c
> --- rde.c 3 Sep 2016 10:25:36 -   1.68
> +++ rde.c 27 Dec 2016 13:45:35 -
> @@ -59,11 +59,11 @@ int 

ospf6d: remove struct rroute

[Jeremie Courreges-Anglas]

struct rroute has ben removed from ospfd some time ago.  struct kroute
takes an additional 'metric' field.


Index: kroute.c
===
RCS file: /d/cvs/src/usr.sbin/ospf6d/kroute.c,v
retrieving revision 1.49
diff -u -p -r1.49 kroute.c
--- kroute.c22 Dec 2016 23:01:58 -  1.49
+++ kroute.c27 Dec 2016 13:45:35 -
@@ -51,12 +51,12 @@ struct {
 
 struct kroute_node {
RB_ENTRY(kroute_node)entry;
-   struct krouter;
struct kroute_node  *next;
+   struct krouter;
 };
 
 void   kr_redist_remove(struct kroute_node *, struct kroute_node *);
-intkr_redist_eval(struct kroute *, struct rroute *);
+intkr_redist_eval(struct kroute *, struct kroute *);
 void   kr_redistribute(struct kroute_node *);
 intkroute_compare(struct kroute_node *, struct kroute_node *);
 
@@ -344,7 +344,7 @@ kr_show_route(struct imsg *imsg)
 void
 kr_redist_remove(struct kroute_node *kh, struct kroute_node *kn)
 {
-   struct rrouterr;
+   struct kroute*kr;
 
/* was the route redistributed? */
if ((kn->r.flags & F_REDISTRIBUTED) == 0)
@@ -352,8 +352,7 @@ kr_redist_remove(struct kroute_node *kh,
 
/* remove redistributed flag */
kn->r.flags &= ~F_REDISTRIBUTED;
-   rr.kr = kn->r;
-   rr.metric = DEFAULT_REDIST_METRIC;  /* some dummy value */
+   kr = >r;
 
/* probably inform the RDE (check if no other path is redistributed) */
for (kn = kh; kn; kn = kn->next)
@@ -361,12 +360,12 @@ kr_redist_remove(struct kroute_node *kh,
break;
 
if (kn == NULL)
-   main_imsg_compose_rde(IMSG_NETWORK_DEL, 0, ,
-   sizeof(struct rroute));
+   main_imsg_compose_rde(IMSG_NETWORK_DEL, 0, kr,
+   sizeof(struct kroute));
 }
 
 int
-kr_redist_eval(struct kroute *kr, struct rroute *rr)
+kr_redist_eval(struct kroute *kr, struct kroute *new_kr)
 {
u_int32_tmetric = 0;
 
@@ -411,9 +410,9 @@ kr_redist_eval(struct kroute *kr, struct
 * only one of all multipath routes can be redistributed so
 * redistribute the best one.
 */
-   if (rr->metric > metric) {
-   rr->kr = *kr;
-   rr->metric = metric;
+   if (new_kr->metric > metric) {
+   *new_kr = *kr;
+   new_kr->metric = metric;
}
 
return (1);
@@ -431,26 +430,25 @@ void
 kr_redistribute(struct kroute_node *kh)
 {
struct kroute_node  *kn;
-   struct rrouterr;
+   struct kroutekr;
int  redistribute = 0;
 
-   bzero(, sizeof(rr));
-   rr.metric = UINT_MAX;
+   bzero(, sizeof(kr));
+   kr.metric = UINT_MAX;
for (kn = kh; kn; kn = kn->next)
-   if (kr_redist_eval(>r, ))
+   if (kr_redist_eval(>r, ))
redistribute = 1;
 
if (!redistribute)
return;
 
-   if (rr.kr.flags & F_REDISTRIBUTED) {
-   main_imsg_compose_rde(IMSG_NETWORK_ADD, 0, ,
-   sizeof(struct rroute));
+   if (kr.flags & F_REDISTRIBUTED) {
+   main_imsg_compose_rde(IMSG_NETWORK_ADD, 0, ,
+   sizeof(struct kroute));
} else {
-   rr.metric = DEFAULT_REDIST_METRIC;  /* some dummy value */
-   rr.kr = kh->r;
-   main_imsg_compose_rde(IMSG_NETWORK_DEL, 0, ,
-   sizeof(struct rroute));
+   kr = kh->r;
+   main_imsg_compose_rde(IMSG_NETWORK_DEL, 0, ,
+   sizeof(struct kroute));
}
 }
 
Index: ospf6d.h
===
RCS file: /d/cvs/src/usr.sbin/ospf6d/ospf6d.h,v
retrieving revision 1.30
diff -u -p -r1.30 ospf6d.h
--- ospf6d.h2 Sep 2016 14:06:35 -   1.30
+++ ospf6d.h27 Dec 2016 13:45:35 -
@@ -390,16 +390,12 @@ struct kroute {
struct in6_addr prefix;
struct in6_addr nexthop;
u_int32_t   ext_tag;
+   u_int32_t   metric;
unsigned intscope;  /* scope of nexthop */
u_int16_t   flags;
u_int16_t   rtlabel;
u_short ifindex;
u_int8_tprefixlen;
-};
-
-struct rroute {
-   struct kroute   kr;
-   u_int32_t   metric;
 };
 
 /* name2id */
Index: rde.c
===
RCS file: /d/cvs/src/usr.sbin/ospf6d/rde.c,v
retrieving revision 1.68
diff -u -p -r1.68 rde.c
--- rde.c   3 Sep 2016 10:25:36 -   1.68
+++ rde.c   27 Dec 2016 13:45:35 -
@@ -59,11 +59,11 @@ int  rde_req_list_exists(struct rde_nbr
 voidrde_req_list_del(struct rde_nbr *, struct lsa_hdr *);
 voidrde_req_list_free(struct rde_nbr *);
 
-struct lsa *rde_asext_get(struct rroute *);

Re: pf route-to rtisvalid

[Martin Pieuchot]

On 24/12/16(Sat) 00:23, Alexander Bluhm wrote:
> Hi,
> 
> I think it is better to check for a valid route than for an existing
> route in pf route-to.  So call rtisvalid() now.  I want to have
> pf_route() and pf_route6() as simmilar as possible so I can merge
> them some day.  As rtalloc() has to stay after embeding the v6
> scope, I have moved it down in the v4 code.  In the v6 code I always
> do the valid route check now.  The duplicate route lookup in
> pf_refragment6() will be fixed later.

The reason for not calling rtisvalid() previously was the same as in
ip_output().  This bug was related to stale ifa hanging to static
routes.  Since it is now "fixed", this should be safe, ok mpi@.

> Index: net/pf.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/pf.c,v
> retrieving revision 1.1006
> diff -u -p -r1.1006 pf.c
> --- net/pf.c  23 Dec 2016 20:49:41 -  1.1006
> +++ net/pf.c  23 Dec 2016 22:53:07 -
> @@ -5832,12 +5832,6 @@ pf_route(struct pf_pdesc *pd, struct pf_
>   if (ifp == NULL)
>   goto bad;
>  
> - rt = rtalloc(sintosa(dst), RT_RESOLVE, rtableid);
> - if (rt == NULL) {
> - ipstat_inc(ips_noroute);
> - goto bad;
> - }
> -
>   if (pd->kif->pfik_ifp != ifp) {
>   if (pf_test(AF_INET, PF_OUT, ifp, ) != PF_PASS)
>   goto bad;
> @@ -5853,6 +5847,12 @@ pf_route(struct pf_pdesc *pd, struct pf_
>  
>   in_proto_cksum_out(m0, ifp);
>  
> + rt = rtalloc(sintosa(dst), RT_RESOLVE, rtableid);
> + if (!rtisvalid(rt)) {
> + ipstat_inc(ips_noroute);
> + goto bad;
> + }
> +
>   if (ntohs(ip->ip_len) <= ifp->if_mtu) {
>   ip->ip_sum = 0;
>   if (ifp->if_capabilities & IFCAP_CSUM_IPv4)
> @@ -5991,6 +5991,12 @@ pf_route6(struct pf_pdesc *pd, struct pf
>   if (IN6_IS_SCOPE_EMBED(>sin6_addr))
>   dst->sin6_addr.s6_addr16[1] = htons(ifp->if_index);
>  
> + rt = rtalloc(sin6tosa(dst), RT_RESOLVE, rtableid);
> + if (!rtisvalid(rt)) {
> + ip6stat.ip6s_noroute++;
> + goto bad;
> + }
> +
>   /*
>* If packet has been reassembled by PF earlier, we have to
>* use pf_refragment6() here to turn it back to fragments.
> @@ -5998,13 +6004,7 @@ pf_route6(struct pf_pdesc *pd, struct pf
>   if ((mtag = m_tag_find(m0, PACKET_TAG_PF_REASSEMBLED, NULL))) {
>   (void) pf_refragment6(, mtag, dst, ifp);
>   } else if ((u_long)m0->m_pkthdr.len <= ifp->if_mtu) {
> - rt = rtalloc(sin6tosa(dst), RT_RESOLVE, rtableid);
> - if (rt == NULL) {
> - ip6stat.ip6s_noroute++;
> - goto bad;
> - }
>   ifp->if_output(ifp, m0, sin6tosa(dst), rt);
> - rtfree(rt);
>   } else {
>   icmp6_error(m0, ICMP6_PACKET_TOO_BIG, 0, ifp->if_mtu);
>   }
> @@ -6012,6 +6012,7 @@ pf_route6(struct pf_pdesc *pd, struct pf
>  done:
>   if (r->rt != PF_DUPTO)
>   pd->m = NULL;
> + rtfree(rt);
>   return;
>  
>  bad:
> 

[s...@spacehopper.org: Re: cert.pem: Re-add mistakenly removed GlobalSign R2]

[Stuart Henderson]

ping?

- Forwarded message from Stuart Henderson  -

From: Stuart Henderson 
Date: Wed, 14 Dec 2016 09:36:15 +
To: Steven McDonald , tech@openbsd.org
User-Agent: NeoMutt/20161126 (1.7.1)
Subject: Re: cert.pem: Re-add mistakenly removed GlobalSign R2
Mail-Followup-To: Steven McDonald , 
tech@openbsd.org

On 2016/12/14 07:50, Stuart Henderson wrote:
> 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 sorting
> > (https://spacehopper.org/format-pem.20160201).
> > 
> > This diff adds it back (though you may want to fetch it from CVS
> > history rather than trusting this mail). I've verified that this is the
> > only case of a duplicate CN in revision 1.9, so no others should be
> > missing.
> 
> I will go over the whole file; I know of at least one root that wasn't
> listed before that we should add, and now that verification has been
> fixed there are a number to be removed too.

The one I was thinking of was indeed GlobalSign R2 (I noticed it with 
nginx.com).

Here's a diff to re-add that and use full subjects. There's some extra noise
as it changes the sort order.

I'll send a separate diff for the removals.

OK?


Index: cert.pem
===
RCS file: /cvs/src/lib/libcrypto/cert.pem,v
retrieving revision 1.13
diff -u -p -r1.13 cert.pem
--- cert.pem4 Sep 2016 11:58:15 -   1.13
+++ cert.pem14 Dec 2016 09:33:45 -
@@ -2,55 +2,7 @@
 
 ### AddTrust AB
 
-=== AddTrust Class 1 CA Root
-Certificate:
-Data:
-Version: 3 (0x2)
-Serial Number: 1 (0x1)
-Signature Algorithm: sha1WithRSAEncryption
-Validity
-Not Before: May 30 10:38:31 2000 GMT
-Not After : May 30 10:38:31 2020 GMT
-Subject: C=SE, O=AddTrust AB, OU=AddTrust TTP Network, CN=AddTrust 
Class 1 CA Root
-X509v3 extensions:
-X509v3 Subject Key Identifier: 
-95:B1:B4:F0:94:B6:BD:C7:DA:D1:11:09:21:BE:C1:AF:49:FD:10:7B
-X509v3 Key Usage: 
-Certificate Sign, CRL Sign
-X509v3 Basic Constraints: critical
-CA:TRUE
-X509v3 Authority Key Identifier: 
-
keyid:95:B1:B4:F0:94:B6:BD:C7:DA:D1:11:09:21:BE:C1:AF:49:FD:10:7B
-DirName:/C=SE/O=AddTrust AB/OU=AddTrust TTP 
Network/CN=AddTrust Class 1 CA Root
-serial:01
-
-SHA1 Fingerprint=CC:AB:0E:A0:4C:23:01:D6:69:7B:DD:37:9F:CD:12:EB:24:E3:94:9D
-SHA256 
Fingerprint=8C:72:09:27:9A:C0:4E:27:5E:16:D0:7F:D3:B7:75:E8:01:54:B5:96:80:46:E3:1F:52:DD:25:76:63:24:E9:A7
--BEGIN CERTIFICATE-
-MIIEGDCCAwCgAwIBAgIBATANBgkqhkiG9w0BAQUFADBlMQswCQYDVQQGEwJTRTEU
-MBIGA1UEChMLQWRkVHJ1c3QgQUIxHTAbBgNVBAsTFEFkZFRydXN0IFRUUCBOZXR3
-b3JrMSEwHwYDVQQDExhBZGRUcnVzdCBDbGFzcyAxIENBIFJvb3QwHhcNMDAwNTMw
-MTAzODMxWhcNMjAwNTMwMTAzODMxWjBlMQswCQYDVQQGEwJTRTEUMBIGA1UEChML
-QWRkVHJ1c3QgQUIxHTAbBgNVBAsTFEFkZFRydXN0IFRUUCBOZXR3b3JrMSEwHwYD
-VQQDExhBZGRUcnVzdCBDbGFzcyAxIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUA
-A4IBDwAwggEKAoIBAQCWltQhSWDia+hBBwzexODcEyPNwTXH+9ZOEQpnXvUGW2ul
-CDtbKRY654eyNAbFvAWlA3yCyykQruGIgb3WntP+LVbBFc7jJp0VLhD7Bo8wBN6n
-tGO0/7Gcrjyvd7ZWxbWroulpOj0OM3kyP3CCkplhbY0wCI9xP6ZIVxn4JdxLZlyl
-dI+Yrsj5wAYi56xz36Uu+1LcsRVlIPo1Zmne3yzxbrww2ywkEtvrNTVokMsAsJch
-PXQhI2U0K7t4WaPW4XY5mqRJjox0r26kmqPZm9I4XJuiGMx1I4S+6+JNM3GOGvDC
-+Mcdoq0Dlyz4zyXG9rgkMbFjXZJ/Y/AlyVMuH79NAgMBAAGjgdIwgc8wHQYDVR0O
-BBYEFJWxtPCUtr3H2tERCSG+wa9J/RB7MAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8E
-BTADAQH/MIGPBgNVHSMEgYcwgYSAFJWxtPCUtr3H2tERCSG+wa9J/RB7oWmkZzBl
-MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxHTAbBgNVBAsTFEFk
-ZFRydXN0IFRUUCBOZXR3b3JrMSEwHwYDVQQDExhBZGRUcnVzdCBDbGFzcyAxIENB
-IFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBACxtZBsfzQ3duQH6lmM0MkhHma6X
-7f1yFqZzR1r0693p9db7RcwpiURdv0Y5PejuvE1Uhh4dbOMXJ0PhiVYrqW9yTkkz
-43J8KiOavD7/KCrto/8cI7pDVwlnTUtiBi34/2ydYB7YHEt9tTEv2dB8Xfjea4MY
-eDdXL+gzB2ffHsdrKpV2ro9Xo/D0UrSpUwjP4E/TelOL/bscVjby/rK25Xa71SJl
-pz/+0WatC7xrmYbvP33zGDLKe8bjq2RGlfgmadlVg3sslgf/WSxEo8bl6ancoWOA
-WiFeIc9TVPC6b4nbqKqVz4vjccweGyBECMB6tkD9xOQ14R0WHNC8K47Wcdk=
--END CERTIFICATE-
-=== AddTrust External CA Root
+=== /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External 
CA Root
 Certificate:
 Data:
 Version: 3 (0x2)
@@ -99,7 +51,55 @@ Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1
 c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
 mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
 -END CERTIFICATE-
-=== AddTrust Public CA Root
+=== /C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Class 1 CA Root
+Certificate:
+Data:
+Version: 3 (0x2)
+Serial Number: 1 (0x1)
+