Problem with boot block / softraid on current
One of my amd64 machines does not boot anymore after updating to current (attached dmesg was obtained after booting a build of current from today but with a boot block from December, 22nd). Interestingly, the same disk (with a boot block from today's build) still boots fine with another amd64 machine (an old x61s thinkpad). The disk image makes use of a softraid(4) encrypted root partition. On the affected machine, it triggers a reboot directly after the password has been entered. I could narrow the problem down to the use of installboot(8), i.e., booting current still works on the affected machine with a boot block based on my previous build from December, 22nd. Best regards Andreas OpenBSD 6.0-current (GENERIC.MP) #0: Tue Jan 3 05:18:14 CET 2017 bu...@obsd.bartelt.name:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error d0 real mem = 17083674624 (16292MB) avail mem = 16561262592 (15794MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcba36018 (98 entries) bios0: vendor Hewlett-Packard version "J61 v03.90" date 06/01/2016 bios0: Hewlett-Packard HP Z620 Workstation acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SLIC SSDT SSDT ASF! UEFI DMAR acpi0: wakeup devices PS2K(S3) BR20(S4) EUSB(S4) USBE(S4) GBE_(S4) NPE1(S4) NPE2(S4) NPE3(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PWRB(S3) 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) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2893.29 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2893294400 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) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2892.86 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2892.86 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2892.86 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 8 (application processor) cpu4: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2892.86 MHz cpu4: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 4, package 0 cpu5 at mainbus0: apid 10 (application processor) cpu5: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2892.86 MHz cpu5: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 0, core 5, package 0 cpu6 at mainbus0: apid 12 (application processor) cpu6: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 2892.86 MHz cpu6: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu6: 256KB 64b/line 8
Re: ntpd with default config broken in -current
On 2017/01/02 16:37, Matthieu Herrb wrote:
> On Mon, Jan 02, 2017 at 03:59:51PM +0100, Matthieu Herrb wrote:
> > Hi,
> >
> > running -current on amd64 and i386 with the default /etc/ntpd.conf,
> > ntpd doesn't send any NTP request and doesn't sync the clock...
> >
> > mirrorball% ntpctl -sa
> > 0/4 peers valid, clock unsynced
> >
> > peer
> >wt tl st next poll offset delay jitter
> > 151.80.19.218 from pool pool.ntp.org
> > 1 2 -0s0s peer not valid
> > 37.187.104.44 from pool pool.ntp.org
> > 1 2 -0s0s peer not valid
> > 37.187.2.84 from pool pool.ntp.org
> > 1 2 -0s0s peer not valid
> > 163.172.163.169 from pool pool.ntp.org
> > 1 2 -0s0s peer not valid
> >
> > tcpdump -n -i em0 port 123 doesn't show any trafic on ntp port
> >
>
> Looking a bit more, this is caused by a cert validation failure during
> constraints checks.
> The www.google.com certificate fails verification because the 'Equifax
> Secure Certificate Authority' root CA certificate that is on top of
> the www.google.com certificate chain is missing from newer
> /etc/ssl/cert.pem.
It fails verification because alt chains aren't working correctly.
It's this problem which I mentioned on another list:
- Forwarded message from Stuart Henderson -
From: Stuart Henderson
Date: Mon, 2 Jan 2017 13:26:07 +
Subject: alt chains / verify callback [Re: CVS: cvs.openbsd.org: src]
On 2016/12/26 09:20, Joel Sing wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: js...@cvs.openbsd.org 2016/12/26 09:20:58
>
> Modified files:
> lib/libtls : tls.c tls_client.c
>
> Log message:
> Hook up a certificate verify callback so that we can set user friendly
> error messages, instead of libssl error strings. This gives us messages
> like:
>
> certificate verification failed: certificate has expired
>
> Instead of:
>
> 14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>
> This also lets us always enable peer verification since the no verification
> case is now handled via the callback.
>
> Tested by tedu@
>
> ok beck@
>
naddy ran into a problem fetching ports distfiles from a google server
with ftp(1) with the new cert.pem, whereas it was working OK for me
when I tested the cert.pem update with ftp(1) on a slightly older
snapshot (23 Dec).
I've bisected and found that this was the commit that stopped it from
working. However testing further I find that curl(1) (which doesn't
use libtls) also fails in a similar way.
google's chain looks like this;
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
With the new cert.pem the old 1024-bit "Equifax Secure Certificate Authority"
cert is no longer included, so alt chains need to work to be able to connect to
it (GeoTrust Global CA is in cert.pem).
On -current:
$ nc -vvc google.com 443
Connection to google.com 443 port [tcp/https] succeeded!
nc: tls handshake failed (certificate verification failed: certificate not
trusted)
On a machine with new cert.pem but older libtls:
$ ssh jodrell nc -vvc google.com 443
Connection to google.com 443 port [tcp/https] succeeded!
TLS handshake negotiated TLSv1.2/ECDHE-ECDSA-CHACHA20-POLY1305 with host
google.com
Peer name: google.com
Subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
Issuer: /C=US/O=Google Inc/CN=Google Internet Authority G2
Valid From: Thu Dec 15 14:04:15 2016
Valid Until: Thu Mar 9 13:35:00 2017
Cert Hash:
SHA256:c6ad71b8ad015bff4df56886261d0f975caa3ae427a3e68c2f8bf92f36824d4b
OCSP URL: http://clients1.google.com/ocsp
And on either machine with curl:
$ curl https://www.google.com/
curl: (51) SSL certificate verify result: certificate not trusted (27)
curl is not using SSL_CTX_set_cert_verify_callback; in that case the failure
is coming from SSL_get_verify_result -
lib/vtls/openssl.c
2796 lerr = data->set.ssl.certverifyresult =
2797 SSL_get_verify_result(connssl->handle);
2798
2799 if(data->set.ssl.certverifyresult != X509_V_OK) {
2800 if(data->set.ssl.verifypeer) {
2801 /* We probably never reach this, because SSL_connect() will fail
2802and we return earlier if verifypeer is set? */
2803 if(strict)
2804 failf(data, "SSL certificate verify result: %s (%ld)",
2805 X509_verify_cert_error_string(lerr), lerr);
2806 result = CURLE_PEER_FAILED_VERIFICATION;
2807 }
Does anyone have ideas to fix it? If not, which of the temporary workarounds
would be preferable?
- re-add the removed CAs to ce
Re: IPv6/NDP/IPsec breakage in -current
Alexander Bluhm:
> naddy: How do you work around this problem currently in your setup?
I carry along the patch below (from mpi@).
Index: netinet6/nd6_nbr.c
===
RCS file: /cvs/src/sys/netinet6/nd6_nbr.c,v
retrieving revision 1.113
diff -u -p -r1.113 nd6_nbr.c
--- netinet6/nd6_nbr.c 22 Dec 2016 13:39:32 - 1.113
+++ netinet6/nd6_nbr.c 26 Dec 2016 20:11:01 -
@@ -433,54 +433,23 @@ nd6_ns_output(struct ifnet *ifp, struct
}
ip6->ip6_dst = dst_sa.sin6_addr;
if (!dad) {
- /*
-* RFC2461 7.2.2:
-* "If the source address of the packet prompting the
-* solicitation is the same as one of the addresses assigned
-* to the outgoing interface, that address SHOULD be placed
-* in the IP Source Address of the outgoing solicitation.
-* Otherwise, any one of the addresses assigned to the
-* interface should be used."
-*
-* We use the source address for the prompting packet
-* (saddr6), if:
-* - saddr6 is given from the caller (by giving "ln"), and
-* - saddr6 belongs to the outgoing interface.
-* Otherwise, we perform the source address selection as usual.
-*/
- struct ip6_hdr *hip6; /* hold ip6 */
- struct in6_addr *saddr6;
+/* Perform source address selection. */
+ struct rtentry *rt;
- if (ln && ln->ln_hold) {
- hip6 = mtod(ln->ln_hold, struct ip6_hdr *);
- /* XXX pullup? */
- if (sizeof(*hip6) < ln->ln_hold->m_len)
- saddr6 = &hip6->ip6_src;
- else
- saddr6 = NULL;
- } else
- saddr6 = NULL;
- if (saddr6 && in6ifa_ifpwithaddr(ifp, saddr6))
- src_sa.sin6_addr = *saddr6;
- else {
- struct rtentry *rt;
+ rt = rtalloc(sin6tosa(&dst_sa), RT_RESOLVE,
+ m->m_pkthdr.ph_rtableid);
+ if (!rtisvalid(rt)) {
+ char addr[INET6_ADDRSTRLEN];
- rt = rtalloc(sin6tosa(&dst_sa), RT_RESOLVE,
- m->m_pkthdr.ph_rtableid);
- if (!rtisvalid(rt)) {
- char addr[INET6_ADDRSTRLEN];
-
- nd6log((LOG_DEBUG,
- "%s: source can't be determined: dst=%s\n",
- __func__, inet_ntop(AF_INET6,
- &dst_sa.sin6_addr, addr, sizeof(addr;
- rtfree(rt);
- goto bad;
- }
- src_sa.sin6_addr =
- ifatoia6(rt->rt_ifa)->ia_addr.sin6_addr;
+ nd6log((LOG_DEBUG,
+ "%s: source can't be determined: dst=%s\n",
+ __func__, inet_ntop(AF_INET6,
+ &dst_sa.sin6_addr, addr, sizeof(addr;
rtfree(rt);
+ goto bad;
}
+ src_sa.sin6_addr = ifatoia6(rt->rt_ifa)->ia_addr.sin6_addr;
+ rtfree(rt);
} else {
/*
* Source address for DAD packet must always be IPv6
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: IPv6/NDP/IPsec breakage in -current
On Mon, Jan 02, 2017 at 09:53:14AM +0100, Martin Pieuchot wrote:
> This is still an issue, multiple diffs are floating around, could we
> commit a fix?
The only real bug is the length check. Unfortunaltely it will not
fix naddy's setup. I noone objects, I will commit this as it makes
the behavior independent from the mbuf layout.
ok?
I think we should make it possible to exclude neigbor discovery
packets from a transparent IPsec flow. If I understand ipsec.conf(5)
correctly, it is currently only possible to exclude all icmp6
packets. This is bad as the icmp6 packet may contain confidential
data in the quoted packet.
naddy: How do you work around this problem currently in your setup?
bluhm
Index: netinet6/nd6_nbr.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/nd6_nbr.c,v
retrieving revision 1.113
diff -u -p -r1.113 nd6_nbr.c
--- netinet6/nd6_nbr.c 22 Dec 2016 13:39:32 - 1.113
+++ netinet6/nd6_nbr.c 2 Jan 2017 14:40:28 -
@@ -453,8 +453,7 @@ nd6_ns_output(struct ifnet *ifp, struct
if (ln && ln->ln_hold) {
hip6 = mtod(ln->ln_hold, struct ip6_hdr *);
- /* XXX pullup? */
- if (sizeof(*hip6) < ln->ln_hold->m_len)
+ if (sizeof(*hip6) <= ln->ln_hold->m_len)
saddr6 = &hip6->ip6_src;
else
saddr6 = NULL;
Re: ntpd with default config broken in -current
On Mon, Jan 02, 2017 at 03:59:51PM +0100, Matthieu Herrb wrote: > Hi, > > running -current on amd64 and i386 with the default /etc/ntpd.conf, > ntpd doesn't send any NTP request and doesn't sync the clock... > > mirrorball% ntpctl -sa > 0/4 peers valid, clock unsynced > > peer >wt tl st next poll offset delay jitter > 151.80.19.218 from pool pool.ntp.org > 1 2 -0s0s peer not valid > 37.187.104.44 from pool pool.ntp.org > 1 2 -0s0s peer not valid > 37.187.2.84 from pool pool.ntp.org > 1 2 -0s0s peer not valid > 163.172.163.169 from pool pool.ntp.org > 1 2 -0s0s peer not valid > > tcpdump -n -i em0 port 123 doesn't show any trafic on ntp port > Looking a bit more, this is caused by a cert validation failure during constraints checks. mirrorball% doas ntpd -d -v ntp engine ready constraint request to 74.125.232.243 constraint request to 74.125.232.240 constraint request to 74.125.232.242 constraint request to 74.125.232.244 constraint request to 2a00:1450:4010:c03::6a constraint request to 74.125.232.241 tls write failed: 74.125.232.243 (www.google.com): certificate verification failed: certificate not trusted tls write failed: 74.125.232.240 (www.google.com): certificate verification failed: certificate not trusted no constraint reply from 74.125.232.243 received in time, next query 900s tls write failed: 74.125.232.242 (www.google.com): certificate verification failed: certificate not trusted no constraint reply from 74.125.232.240 received in time, next query 900s tls write failed: 74.125.232.244 (www.google.com): certificate verification failed: certificate not trusted no constraint reply from 74.125.232.242 received in time, next query 900s tls write failed: 74.125.232.241 (www.google.com): certificate verification failed: certificate not trusted no constraint reply from 74.125.232.244 received in time, next query 900s no constraint reply from 74.125.232.241 received in time, next query 900s tls write failed: 2a00:1450:4010:c03::6a (www.google.com): certificate verification failed: certificate not trusted no constraint reply from 2a00:1450:4010:c03::6a received in time, next query 900s The www.google.com certificate fails verification because the 'Equifax Secure Certificate Authority' root CA certificate that is on top of the www.google.com certificate chain is missing from newer /etc/ssl/cert.pem. -- Matthieu Herrb
ntpd with default config broken in -current
Hi, running -current on amd64 and i386 with the default /etc/ntpd.conf, ntpd doesn't send any NTP request and doesn't sync the clock... mirrorball% ntpctl -sa 0/4 peers valid, clock unsynced peer wt tl st next poll offset delay jitter 151.80.19.218 from pool pool.ntp.org 1 2 -0s0s peer not valid 37.187.104.44 from pool pool.ntp.org 1 2 -0s0s peer not valid 37.187.2.84 from pool pool.ntp.org 1 2 -0s0s peer not valid 163.172.163.169 from pool pool.ntp.org 1 2 -0s0s peer not valid tcpdump -n -i em0 port 123 doesn't show any trafic on ntp port Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface defaultblackipUGS0 55 - 8 em0 224/4 localhost URS0 79 32768 8 lo0 127/8 localhost UGRS 00 32768 8 lo0 localhost localhost UHhl 2 46 32768 1 lo0 192.168.31/24 mirrorball UCn5 1600 - 4 em0 mirrorball b8:ae:ed:72:d0:cd UHLl 0 253 - 1 em0 alix 00:0d:b9:15:76:50 UHLc 0 851 - 3 em0 moonshine 10:78:d2:eb:7d:d7 UHLc 1 221 - 3 em0 freenas00:9c:02:a0:45:b3 UHLc 2 15 - 3 em0 blackip00:08:a2:09:99:52 UHLch 1 30 - 3 em0 black 00:00:24:cd:7e:50 UHLc 0 520 - 3 em0 192.168.31.255 mirrorball UHb15 - 1 em0 Internet6: DestinationGatewayFlags Refs Use Mtu Prio Iface defaultfe80::31:200%em0 UGS2 39 - 8 em0 ::/96 localhost UGRS 00 32768 8 lo0 ::/104 localhost UGRS 00 32768 8 lo0 localhost localhost UHhl 14 28 32768 1 lo0 ::127.0.0.0/104localhost UGRS 00 32768 8 lo0 ::224.0.0.0/100localhost UGRS 00 32768 8 lo0 ::255.0.0.0/104localhost UGRS 00 32768 8 lo0 :::0.0.0.0/96 localhost UGRS 00 32768 8 lo0 2002::/24 localhost UGRS 00 32768 8 lo0 2002:7f00::/24 localhost UGRS 00 32768 8 lo0 2002:e000::/20 localhost UGRS 00 32768 8 lo0 2002:ff00::/24 localhost UGRS 00 32768 8 lo0 2a03:7220:8081:610 mirrorball.herrb.n UCn42 - 4 em0 mirrorball.herrb.n b8:ae:ed:72:d0:cd UHLl 0 154 - 1 em0 blackip.herrb.net 00:08:a2:09:99:52 UHLc 0 161 - 3 em0 2a03:7220:8081:610 00:0d:b9:15:76:50 UHLc 2 195 - 3 em0 freedom.herrb.net 00:23:8b:f2:b7:a3 UHLc 1 177 - 3 em0 nebraska.herrb.net 7c:7a:91:ef:4e:d0 UHLc 2 47 - 3 em0 fe80::/10 localhost UGRS 01 32768 8 lo0 fec0::/10 localhost UGRS 00 32768 8 lo0 fe80::%em0/64 fe80::baae:edff:fe UCn10 - 4 em0 fe80::31:200%em0 00:08:a2:09:99:52 UHLch 1 427 - 3 em0 fe80::baae:edff:fe b8:ae:ed:72:d0:cd UHLl 0 51 - 1 em0 fe80::1%lo0fe80::1%lo0UHl00 32768 1 lo0 ff01::/16 localhost UGRS 01 32768 8 lo0 ff01::%em0/32 fe80::baae:edff:fe Um 01 - 4 em0 ff01::%lo0/32 localhost Um 01 32768 4 lo0 ff02::/16 localhost UGRS 01 32768 8 lo0 ff02::%em0/32 fe80::baae:edff:fe Um 04 - 4 em0 ff02::%lo0/32 localhost Um 01 32768 4 lo0 OpenBSD 6.0-current (GENERIC.MP) #15: Mon Jan 2 13:05:09 CET 2017 matth...@mirrorball.herrb.net:/usr/obj/GENERIC.MP real mem = 8453414912 (8061MB) avail mem = 8192557056 (7813MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xa2ee6000 (52 entries) bios0: vendor Intel Corporation version "RYBDWi35.86A.0353.2015.1222.0947" date 12/22/2015 bios0: Intel Corporation NUC5i3RYB acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI LPIT SSDT ASF! SSDT SSDT SSDT DMAR BGRT acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at a
Re: IPv6/NDP/IPsec breakage in -current
On 06/12/16(Tue) 15:23, Alexander Bluhm wrote:
> On Mon, Nov 21, 2016 at 03:15:39PM +0100, Martin Pieuchot wrote:
> > naddy@ confirmed this diff fixes his tunnel mode setup, ok?
>
> IPv6 neighbor discovery over IPsec does not work reliably. It uses
> link-local, global and multicast addresses and depending on your
> flows and SA it either works or not.
>
> The (sizeof(*hip6) < ln->ln_hold->m_len) check is wrong, so the
> code used saddr6 = NULL before. With that and m_inject() it worked.
> We have a bug that was hiding a problem, but now the bug is not
> triggered anymore.
>
> Then there is RFC 2461 written in this old IPv6 spirit. If we have
> a bunch of address scopes, use the best matching address. Then
> chances are high, that autoconfiguration and featuritis works.
>
> SEND brings the issue to a new x509 certificate problem level.
>
> I am not sure what to do.
>
> mpi@ suggests to remove the IPv6 spirit and by accident it fixes
> naddy@'s problem. I am a bit reluctant to remove it. It is not a
> propper fix and may trigger problems elsewhere.
>
> In my IPv6+IPsec setup I use a separate unencrypted network for
> IKE, ESP and corresponding ND packets.
>
> For transparent mode I have no better solution than excluding ICMP6
> from the flow.
>
> At least we should put something into the ipsec.conf(5) man page.
This is still an issue, multiple diffs are floating around, could we
commit a fix?
> > > Index: netinet6/nd6_nbr.c
> > > ===
> > > RCS file: /cvs/src/sys/netinet6/nd6_nbr.c,v
> > > retrieving revision 1.110
> > > diff -u -p -r1.110 nd6_nbr.c
> > > --- netinet6/nd6_nbr.c23 Aug 2016 11:03:10 - 1.110
> > > +++ netinet6/nd6_nbr.c4 Nov 2016 09:02:47 -
> > > @@ -433,54 +433,23 @@ nd6_ns_output(struct ifnet *ifp, struct
> > > }
> > > ip6->ip6_dst = dst_sa.sin6_addr;
> > > if (!dad) {
> > > - /*
> > > - * RFC2461 7.2.2:
> > > - * "If the source address of the packet prompting the
> > > - * solicitation is the same as one of the addresses assigned
> > > - * to the outgoing interface, that address SHOULD be placed
> > > - * in the IP Source Address of the outgoing solicitation.
> > > - * Otherwise, any one of the addresses assigned to the
> > > - * interface should be used."
> > > - *
> > > - * We use the source address for the prompting packet
> > > - * (saddr6), if:
> > > - * - saddr6 is given from the caller (by giving "ln"), and
> > > - * - saddr6 belongs to the outgoing interface.
> > > - * Otherwise, we perform the source address selection as usual.
> > > - */
> > > - struct ip6_hdr *hip6; /* hold ip6 */
> > > - struct in6_addr *saddr6;
> > > + /* Perform source address selection. */
> > > + struct rtentry *rt;
> > >
> > > - if (ln && ln->ln_hold) {
> > > - hip6 = mtod(ln->ln_hold, struct ip6_hdr *);
> > > - /* XXX pullup? */
> > > - if (sizeof(*hip6) < ln->ln_hold->m_len)
> > > - saddr6 = &hip6->ip6_src;
> > > - else
> > > - saddr6 = NULL;
> > > - } else
> > > - saddr6 = NULL;
> > > - if (saddr6 && in6ifa_ifpwithaddr(ifp, saddr6))
> > > - src_sa.sin6_addr = *saddr6;
> > > - else {
> > > - struct rtentry *rt;
> > > + rt = rtalloc(sin6tosa(&dst_sa), RT_RESOLVE,
> > > + m->m_pkthdr.ph_rtableid);
> > > + if (!rtisvalid(rt)) {
> > > + char addr[INET6_ADDRSTRLEN];
> > >
> > > - rt = rtalloc(sin6tosa(&dst_sa), RT_RESOLVE,
> > > - m->m_pkthdr.ph_rtableid);
> > > - if (!rtisvalid(rt)) {
> > > - char addr[INET6_ADDRSTRLEN];
> > > -
> > > - nd6log((LOG_DEBUG,
> > > - "%s: source can't be determined: dst=%s\n",
> > > - __func__, inet_ntop(AF_INET6,
> > > - &dst_sa.sin6_addr, addr, sizeof(addr;
> > > - rtfree(rt);
> > > - goto bad;
> > > - }
> > > - src_sa.sin6_addr =
> > > - ifatoia6(rt->rt_ifa)->ia_addr.sin6_addr;
> > > + nd6log((LOG_DEBUG,
> > > + "%s: source can't be determined: dst=%s\n",
> > > + __func__, inet_ntop(AF_INET6,
> > > + &dst_sa.sin6_addr, addr, sizeof(addr;
> > > rtfree(rt);
> > > + goto bad;
> > > }
> > > + src_sa.sin6_addr = ifatoia6(rt->rt_ifa)->ia_addr.sin6_addr;
> > > + rtfree(rt);
> > > } else {
> > > /*
> > >* Source address for DA
Re: 6.0-stable crash: uvm_fault(0xd0b89620, 0xd1bb2000, 0, 1) -> e
Hello, On 30/12/16(Fri) 15:06, Listas IT wrote: > >Synopsis:6.0-stable crash > >Category:i386 > >Environment: > System : OpenBSD 6.0 > Details : OpenBSD 6.0 (GENERIC) #2: Mon Oct 17 22:43:38 CEST 2016 > > r...@stable-60-i386.mtier.org:/binpatchng/work-binpatch60-i386/src/sys/arch/i386/compile/GENERIC > > Architecture: OpenBSD.i386 > Machine : i386 > >Description: > > This machine was running 5.7 for over a year without any incidents. A few > minutes after installing 6.0-release got the first crash. > Updated to -stable (via mtier-openup) and got the same crash: That's a known bug in 6.0 that is fixed in -current. You could update to a snapshot a report back if you still see something wrong. > > starting local daemons: cron. > Fri Dec 30 12:41:15 ART 2016 > > OpenBSD/i386 (unX.dna.uba.ar) (tty00) > > login: uvm_fault(0xd0b89620, 0xd1bb2000, 0, 1) -> e > kernel: page fault trap, code=0 > Stopped at docopyf+0x5:repe movsl (%esi),%es:(%edi) > ddb> trace > docopyf(d5fcc600,d1b5c012,3fec,d1b53000,f5a99d30) at docopyf+0x5 > bpf_catchpacket(d1b53000,d5fcc600,3fec,,d0414120) at > bpf_catchpacket+0x > c6 > _bpf_mtap(d189ada0,d5fcc600,1,0,0) at _bpf_mtap+0xec > bpf_mtap(d189ada0,d5fcc600,1,d192c880,d5fcc300) at bpf_mtap+0x27 > bpf_mtap_ether(d189ada0,d5fcc600,1,d028541d,d1912000) at bpf_mtap_ether+0xe9 > if_input(d1912054,f5a99e50,24b0,10,1) at if_input+0xa8 > re_rxeof(d1912000,3e,1,30,1) at re_rxeof+0x341 > re_intr(d1912000,d1899040) at re_intr+0x192 > Xintr_ioapic2() at Xintr_ioapic2+0x65 > --- interrupt --- > acpicpu_idle(d03b303b,d0bad67c,d0c6bfa0,0,0) at acpicpu_idle+0xad > cpu_idle_cycle(d0c6bfa0) at cpu_idle_cycle+0xc > ddb> ps >TID PPID PGRPUID S FLAGS WAIT COMMAND > 78692 78502 78502 67 30x90 lockf httpd2 > 4524 78502 78502 67 30x90 lockf httpd2 > 47962 78502 78502 67 30x90 lockf httpd2 > 35089 78502 78502 67 30x90 lockf httpd2 > 67972 78502 78502 67 30x90 kqreadhttpd2 > 44023 1 44023 0 30x100083 ttyin getty > 8292 1 8292 0 30x100083 ttyin getty > 22867 1 22867 0 30x100083 ttyin getty > 50323 1 50323 0 30x100083 ttyin getty > 19497 1 19497 0 30x100083 ttyin getty > 44638 1 44638 0 30x100083 ttyin getty > 60131 1 60131 0 30x100098 poll cron > 78502 1 78502 0 30x80 selecthttpd2 > 16139 36900 83249502 30x93 poll mysqld > 62031 36900 83249502 3 0x493 thrsleep mysqld > 13076 36900 83249502 3 0x493 thrsleep mysqld > 47764 36900 83249502 3 0x493 thrsleep mysqld > 48333 36900 83249502 3 0x493 thrsleep mysqld > 28739 36900 83249502 3 0x493 thrsleep mysqld > 59318 36900 83249502 3 0x493 thrsleep mysqld > 31256 36900 83249502 3 0x493 thrsleep mysqld > --db_more-- 7786 36900 83249502 3 0x493 thrsleep mysqld > 25459 36900 83249502 3 0x493 thrsleep mysqld > 19266 36900 83249502 3 0x493 thrsleep mysqld > 13987 36900 83249502 3 0x493 thrsleep mysqld > 16315 36900 83249502 3 0x493 thrsleep mysqld > 10961 36900 83249502 3 0x493 thrsleep mysqld > 81500 36900 83249502 3 0x493 selectmysqld > 90956 36900 83249502 3 0x493 thrsleep mysqld > 42732 36900 83249502 3 0x493 selectmysqld > 20454 36900 83249502 3 0x493 selectmysqld > 22513 36900 83249502 3 0x493 thrsleep mysqld > 37764 36900 83249502 3 0x493 thrsleep mysqld > 24394 36900 83249502 3 0x493 thrsleep mysqld > 3971 36900 83249502 3 0x493 thrsleep mysqld > 63030 36900 83249502 3 0x493 thrsleep mysqld > 23296 36900 83249502 3 0x49b sigwait mysqld > 36900 1 83249 0 30x10008b pause sh > 12239 1 12239 99 30x100090 poll sndiod > 70248 1 70248110 30x100090 poll sndiod > 78230 9854 9854 95 30x100092 kqreadsmtpd > 61850 9854 9854103 30x100092 kqreadsmtpd > 37701 9854 9854 95 30x100092 kqreadsmtpd > 66551 9854 9854 95 30x100092 kqreadsmtpd > --db_more-- 63704 9854 9854 95 30x100092 kqreadsmtpd > 66253 9854 9854 95 30x100092 kqreadsmtpd > 9854 1 9854 0 30x100080 kqreadsmtpd > 90405 1 90405
