Re: ARM64 Panic

[Jonathan Gray]

On Tue, Jun 27, 2017 at 12:04:26AM +0100, Stuart Henderson wrote:
> On 2017/06/26 09:30, R0me0 *** wrote:
> > Hello guys,
> > After Installed a snapshot from one week ago.
> 
> A problem with the dwctwo(4) driver which could result in this
> was fixed on 2017/06/20. I'm unsure whether this made it into a
> snapshot yet, but if you're not already running "OpenBSD
> 6.1-current (GENERIC) #0: Wed Jun 21 17:47:53 AEST 2017" you
> should update to at least that version, if it still occurs then
> you could build a new kernel or wait for a newer snap to be
> built.
> 

It does include it.  There will be no new snapshots until someone has
time to look into making lld handle the linker script the kernel now
requires.  This also means you can't build your own kernel till then.

Re: ARM64 Panic

[R0me0 ***]

Hello, Stuart! :) Thank you for the reply, I will try a fresh install
:)

[] 's guys

2017-06-26 20:04 GMT-03:00 Stuart Henderson :

> On 2017/06/26 09:30, R0me0 *** wrote:
> > Hello guys,
> > After Installed a snapshot from one week ago.
>
> A problem with the dwctwo(4) driver which could result in this
> was fixed on 2017/06/20. I'm unsure whether this made it into a
> snapshot yet, but if you're not already running "OpenBSD
> 6.1-current (GENERIC) #0: Wed Jun 21 17:47:53 AEST 2017" you
> should update to at least that version, if it still occurs then
> you could build a new kernel or wait for a newer snap to be
> built.
>
>

Re: ARM64 Panic

[Stuart Henderson]

On 2017/06/26 09:30, R0me0 *** wrote:
> Hello guys,
> After Installed a snapshot from one week ago.

A problem with the dwctwo(4) driver which could result in this
was fixed on 2017/06/20. I'm unsure whether this made it into a
snapshot yet, but if you're not already running "OpenBSD
6.1-current (GENERIC) #0: Wed Jun 21 17:47:53 AEST 2017" you
should update to at least that version, if it still occurs then
you could build a new kernel or wait for a newer snap to be
built.

bsd.rd fails to boot on entry point

[ljung . peter]

>Synopsis:  bsd.rd fails to boot on entry point
>Category:  amd64
>Environment:
System  : OpenBSD 6.0
Details : OpenBSD 6.0 (GENERIC.MP) #2319: Tue Jul 26 13:00:43 MDT 
2016
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
bsd.rd freeze on entry point line when trying to boot 6.1 release 
install kernel
I have checked sha256 checksum of bsd.rd
I have also compared output when booting bsd.rd for 6.0 release

The 6.0 works fine 

booting hd0a:6.0/amd64/bsd.rd: ...
entry point at 0x100100 ...
...

But 6.1 fails   

booting hd0a:6.1/amd64/bsd.rd: ...
entry point at 0x20 ...


I noticed that entry point is 0x100100 on working boot
While it freeze on entry point 0x20

Note that dmesg etc. output is from current working 6.0 install

>How-To-Repeat:
Happen on every boot attempt which bsd.rd 6.1 release
>Fix:
I have not found a fix for it


dmesg:
OpenBSD 6.0 (GENERIC.MP) #2319: Tue Jul 26 13:00:43 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1982316544 (1890MB)
avail mem = 1917825024 (1828MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
bios0: vendor LENOVO version "6QET61WW (1.31 )" date 10/26/2010
bios0: LENOVO 3249MDU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA SSDT 
SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) 
EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz, 931.19 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz, 931.00 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz, 931.00 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,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 5 (application processor)
cpu3: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz, 931.00 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 2, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 13 (EXP1)
acpiprt3 at acpi0: bus -1 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus 5 (EXP4)
acpiprt6 at acpi0: bus 2 (EXP5)
acpicpu0 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
C1(1000@3 mwait.1), PSS
acpicpu1 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
C1(1000@3 mwait.1), PSS
acpicpu2 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
C1(1000@3 mwait.1), PSS
acpicpu3 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10), 
C1(1000@3 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
"PNP0303" at acpi0 not configured
"LEN0018" at acpi0 not configured
"SMO1200" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "42T4837" serial 51533 type LION oem "LGC"
acpiac0 at acpi0: AC unit offline
acpithinkpad0 at acpi0
"PNP0C14" at acpi0 not configured
acpidock0 at acpi0: GDCK not 

Re: spoofed icmp6 echo reply for link local address

[Alexander Bluhm]

On Sat, Jun 24, 2017 at 09:41:18PM +0200, Harald Dunkel wrote:
> That was a lot of work.
> 
> commit 270aa588bf833a21eacc7de79669da22a9ed8fa7
> Author: mpi 
> Date:   Thu Mar 2 09:06:59 2017 +
> 
> Use the routing table rather than the global list of IPv6 address.
> 
> ok bluhm@

I have commited the fix.  Thanks for identifying the breakage.

bluhm

Re: IPv6 not working before pinging the gateway

[R0me0 ***]

Did you open a trouble ticket on Hetzner?




2017-06-26 8:34 GMT-03:00 Martin Pieuchot :

> On 26/06/17(Mon) 12:39, Marc Peters wrote:
> > Am 06/26/17 um 10:58 schrieb Martin Pieuchot:
> > > [...]
> > > Could you set net.inet6.icmp6.nd6_debug to 1 and redo this?
> > >
> > > Do you see anything in the log?
> >
> > Rebooting the box with the sysctl active show following
> /var/log/messages:
> >
> > Jun 26 12:25:35 arafel /bsd: nd6_na_input: ND packet from non-neighbor
>
> Indeed.
>
> Your machine is asking with the following address:
>
> 2a01:4f8:212:216c::1:443 > ff02::1:ff00:1: icmp6: neighbor sol: who has
> fe80::1
>
> Your provider is answering with an address that doesn't match your
> subnet:
>
> 2a01:4f8::a:21:b > 2a01:4f8:212:216c::1:443: icmp6: neighbor adv: tgt is
> fe80::1 [class 0xc0]
>
> It'd be nice if somebody could tell us what the RFCs say about this
> case.  Florian do you have an idea?  Should we fix something or should
> Marc tell his provider to fix his setup?
>
>

Re: IPv6 not working before pinging the gateway

[Marc Peters]

Am 06/26/17 um 10:58 schrieb Martin Pieuchot:
> On 22/06/17(Thu) 17:59, Marc Peters wrote:
>> Am 06/22/17 um 16:51 schrieb Stefan Sperling:
>>> On Thu, Jun 22, 2017 at 04:05:27PM +0200, Marc Peters wrote:
 Is there any way for us to fix it or is it just a misconfiguration at
 Hetzner?
>>>
>>> It might help to look at what is actually going over the wire
>>> while pings are stuck: tcpdump -n -i em0 ip6
>>>
>>
>> right after flushing the ndp and trying to ping google:
> 
> Could you set net.inet6.icmp6.nd6_debug to 1 and redo this? 
> 
> Do you see anything in the log?
> 

Rebooting the box with the sysctl active show following /var/log/messages:

Jun 26 12:25:35 arafel /bsd: nd6_na_input: ND packet from non-neighbor
Jun 26 12:25:35 arafel apmd: battery status: absent. external power
status: not known. estimated battery life 0%
Jun 26 12:25:36 arafel /bsd: nd6_na_input: ND packet from non-neighbor
Jun 26 12:26:07 arafel last message repeated 15 times
Jun 26 12:28:08 arafel last message repeated 61 times


This is, what i did, including the tcpdumps:

~ # sysctl net.inet6.icmp6.nd6_debug

net.inet6.icmp6.nd6_debug=1
root@arafel
~ # ndp -na
Neighbor Linklayer Address   Netif Expire
S Flags
2a01:4f8:212:216c::2 30:85:a9:a4:ce:5e em0 permanent R l
2a01:4f8:212:216c::2530:85:a9:a4:ce:5e em0 permanent R l
2a01:4f8:212:216c::1:443 30:85:a9:a4:ce:5e em0 permanent R l
fe80::1%em0  (incomplete)  em0 expired
I  1
fe80::3285:a9ff:fea4:ce5e%em030:85:a9:a4:ce:5e em0 permanent R l
root@arafel
~ #
I-search:
~ # ndp -na
~ # ndp -d fe80::1%em0
fe80::1%em0 (fe80::1%em0) deleted
root@arafel
~ # ping6 www.google.de
^C
root@arafel
~ # ndp -na
Neighbor Linklayer Address   Netif Expire
S Flags
2a01:4f8:212:216c::2 30:85:a9:a4:ce:5e em0 permanent R l
2a01:4f8:212:216c::2530:85:a9:a4:ce:5e em0 permanent R l
2a01:4f8:212:216c::1:443 30:85:a9:a4:ce:5e em0 permanent R l
fe80::1%em0  (incomplete)  em0 1s
I  2
fe80::3285:a9ff:fea4:ce5e%em030:85:a9:a4:ce:5e em0 permanent R l
root@arafel
~ # ping6 fe80::1%em0
PING fe80::1%em0 (fe80::1%em0): 56 data bytes
64 bytes from fe80::1%em0: icmp_seq=4 hlim=64 time=821.274 ms
64 bytes from fe80::1%em0: icmp_seq=5 hlim=64 time=1.836 ms
64 bytes from fe80::1%em0: icmp_seq=6 hlim=64 time=0.636 ms
64 bytes from fe80::1%em0: icmp_seq=7 hlim=64 time=0.595 ms
64 bytes from fe80::1%em0: icmp_seq=8 hlim=64 time=0.633 ms
64 bytes from fe80::1%em0: icmp_seq=9 hlim=64 time=1.617 ms
^C
--- fe80::1%em0 ping statistics ---
10 packets transmitted, 6 packets received, 40.0% packet loss
round-trip min/avg/max/std-dev = 0.595/137.765/821.274/305.675 ms
root@arafel
~ # ping6 www.google.de
PING www.google.de (2a00:1450:4001:81e::2003): 56 data bytes
64 bytes from 2a00:1450:4001:81e::2003: icmp_seq=0 hlim=56 time=5.073 ms
64 bytes from 2a00:1450:4001:81e::2003: icmp_seq=1 hlim=56 time=5.019 ms
64 bytes from 2a00:1450:4001:81e::2003: icmp_seq=2 hlim=56 time=5.077 ms
^C
--- www.google.de ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 5.019/5.056/5.077/0.027 ms
root@arafel
~ # ndp -na
Neighbor Linklayer Address   Netif Expire
S Flags
2a01:4f8:212:216c::2 30:85:a9:a4:ce:5e em0 permanent R l
2a01:4f8:212:216c::2530:85:a9:a4:ce:5e em0 permanent R l
2a01:4f8:212:216c::1:443 30:85:a9:a4:ce:5e em0 permanent R l
fe80::1%em0  cc:e1:7f:07:e0:88 em0 13s   R R
fe80::3285:a9ff:fea4:ce5e%em030:85:a9:a4:ce:5e em0 permanent R l
root@arafel
~ # ndp -d fe80::1%em0
fe80::1%em0 (fe80::1%em0) deleted
root@arafel
~ # ping6 www.google.de
PING www.google.de (2a00:1450:4001:81e::2003): 56 data bytes
^C
--- www.google.de ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
root@arafel
~ # ndp -na
Neighbor Linklayer Address   Netif Expire
S Flags
2a01:4f8:212:216c::2 30:85:a9:a4:ce:5e em0 permanent R l
2a01:4f8:212:216c::2530:85:a9:a4:ce:5e em0 permanent R l
2a01:4f8:212:216c::1:443 30:85:a9:a4:ce:5e em0 permanent R l
fe80::1%em0  cc:e1:7f:07:e0:88 em0 expired   I R
fe80::3285:a9ff:fea4:ce5e%em030:85:a9:a4:ce:5e em0 permanent R l
root@arafel
~ # ping6 www.google.de
PING www.google.de (2a00:1450:4001:81e::2003): 56 data bytes
^C
--- www.google.de ping statistics ---
9 packets transmitted, 0 packets received, 100.0% packet loss
root@arafel
~ # ping fe80::1%em0
ping: no address associated with name
root@arafel
~ # ping6 fe80::1%em0
PING fe80::1%em0 (fe80::1%em0): 56 data bytes
64 bytes from fe80::1%em0: icmp_seq=0 hlim=64 time=10.294 ms
64 bytes from 

Re: IPv6 not working before pinging the gateway

[Stefan Sperling]

On Mon, Jun 26, 2017 at 11:29:06AM +0200, Marc Peters wrote:
> Haven't got time to rebuild the kernel with debug options yet, or is
> this not needed?

Not needed. Just run sysctl net.inet6.icmp6.nd6_debug=1

Re: IPv6 not working before pinging the gateway

[Martin Pieuchot]

On 22/06/17(Thu) 17:59, Marc Peters wrote:
> Am 06/22/17 um 16:51 schrieb Stefan Sperling:
> > On Thu, Jun 22, 2017 at 04:05:27PM +0200, Marc Peters wrote:
> >> Is there any way for us to fix it or is it just a misconfiguration at
> >> Hetzner?
> > 
> > It might help to look at what is actually going over the wire
> > while pings are stuck: tcpdump -n -i em0 ip6
> > 
> 
> right after flushing the ndp and trying to ping google:

Could you set net.inet6.icmp6.nd6_debug to 1 and redo this? 

Do you see anything in the log?