Quantcast

losing ipv6 connectivity after some uptime

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

losing ipv6 connectivity after some uptime

Paul de Weerd
Hi all,

This weekend my workstation lost v6 connectivity.  I didn't notice, as
I wasn't around (social commitments), but my backup script did.
Investigating this problem, it looks like ndp lost the entry for the
default gateway:

[weerd@pom] $ netstat -rnf inet6 | awk '/^default/'  
default                            fe80::260:e0ff:fe52:f96%em0    UG 0     6880     -    56 em0  
[weerd@pom] $ ndp -an | grep `netstat -rnf inet6 | awk '/^default/ {print $2}'`
fe80::260:e0ff:fe52:f96%em0          00:60:e0:52:0f:96     em0 expired   I R 3

Deleting the expired entry doesn't seem very effective:

[weerd@pom] $ doas ndp -d `netstat -rnf inet6 | awk '/^default/ {print $2}'`
fe80::260:e0ff:fe52:f96%em0 (fe80::260:e0ff:fe52:f96%em0) deleted
[weerd@pom] $ ndp -an | grep `netstat -rnf inet6 | awk '/^default/ {print $2}'`
fe80::260:e0ff:fe52:f96%em0          00:60:e0:52:0f:96     em0 expired   I R
[weerd@pom] $ doas ndp -d `netstat -rnf inet6 | awk '/^default/ {print $2}'`
fe80::260:e0ff:fe52:f96%em0 (fe80::260:e0ff:fe52:f96%em0) deleted
[weerd@pom] $ ndp -an | grep `netstat -rnf inet6 | awk '/^default/ {print $2}'`
fe80::260:e0ff:fe52:f96%em0          00:60:e0:52:0f:96     em0 expired   I R
[weerd@pom] $ doas ndp -d `netstat -rnf inet6 | awk '/^default/ {print $2}'`
fe80::260:e0ff:fe52:f96%em0 (fe80::260:e0ff:fe52:f96%em0) deleted
[weerd@pom] $ ndp -an | grep `netstat -rnf inet6 | awk '/^default/ {print $2}'`
fe80::260:e0ff:fe52:f96%em0          00:60:e0:52:0f:96     em0 expired   I R

Until, after some time (many delete attempts later):

[weerd@pom] $ ndp -an | grep `netstat -rnf inet6 | awk '/^default/ {print $2}'`
fe80::260:e0ff:fe52:f96%em0          00:60:e0:52:0f:96     em0 4s        D R  

And v6 connectivity is back:

[weerd@pom] $ ping6 -c1 www.google.com                                        
PING www.google.com (2a00:1450:4009:802::2004): 56 data bytes                  
64 bytes from 2a00:1450:4009:802::2004: icmp_seq=0 hlim=55 time=11.600 ms      

--- www.google.com ping statistics ---                                        
1 packets transmitted, 1 packets received, 0.0% packet loss                    
round-trip min/avg/max/std-dev = 11.600/11.600/11.600/0.000 ms                

What else can I do to further debug this issue?

Paul

[weerd@pom] $ cat /etc/hostname.em0
up                                                                            
dhcp                                                                          
rtsol                                                                          
autoconfprivacy                                                                
[weerd@pom] $ ifconfig em0
[weerd@pom] $ ifconfig em0                                                    
em0: flags=208843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6> mtu 1500  
        lladdr b8:ca:3a:93:03:e8                                              
        index 1 priority 0 llprio 3                                            
        groups: egress                                                        
        media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)    
        status: active                                                        
        inet 192.168.34.149 netmask 0xffffff00 broadcast 192.168.34.255        
        inet6 fe80::baca:3aff:fe93:3e8%em0 prefixlen 64 scopeid 0x1            
        inet6 20xx:xxxx:xxxx:0:baca:3aff:fe93:3e8 prefixlen 64 autoconf pltime 0 vltime 2591971                                                                  
        inet6 20xx:xxxx:xxxx:0:54fe:33ab:fb4a:dd2b prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 117032                                      
        inet6 20xx:xxxx:xxxx:0:20dc:67c0:c0d:3040 prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 203427                                        
        inet6 20xx:xxxx:xxxx:0:1834:3827:aade:ffd5 prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 289776                                      
        inet6 20xx:xxxx:xxxx:0:3c01:13b2:ad74:200c prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 375819                                      
        inet6 20xx:xxxx:xxxx:0:d4b9:dd0f:1997:a621 prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 462100                                      
        inet6 20xx:xxxx:xxxx:0:e0cd:35d1:8fc4:3f68 prefixlen 64 autoconf autoconfprivacy pltime 0 vltime 548408                                                  
[weerd@pom] $ dmesg
OpenBSD 6.0-current (GENERIC.MP) #182: Mon Feb 20 06:47:57 MST 2017
    [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8477282304 (8084MB)
avail mem = 8215695360 (7835MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec410 (86 entries)
bios0: vendor Dell Inc. version "A12" date 05/06/2015
bios0: Dell Inc. OptiPlex 9020
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT ASF! DMAR
acpi0: wakeup devices UAR1(S3) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) HDEF(S4) PEG0(S4) PEGP(S4) PEG1(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.84 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 3392835430 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.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.14 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.14 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.14 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.14 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.14 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 1, core 1, package 0
cpu6 at mainbus0: apid 5 (application processor)
cpu6: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.14 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu6: 256KB 64b/line 8-way L2 cache
cpu6: smt 1, core 2, package 0
cpu7 at mainbus0: apid 7 (application processor)
cpu7: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.14 MHz
cpu7: 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu7: 256KB 64b/line 8-way L2 cache
cpu7: smt 1, core 3, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec00000, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xf8000000, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu4 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu5 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu6 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu7 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpitz0 at acpi0: critical temperature is 105 degC
acpitz1 at acpi0: critical temperature is 105 degC
"INT3F0D" at acpi0 not configured
"PNP0501" at acpi0 not configured
acpibtn0 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 3392 MHz: speeds: 3401, 3400, 3200, 3000, 2800, 2700, 2500, 2300, 2100, 1900, 1700, 1500, 1400, 1200, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x06
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1920x1080, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x06: msi
azalia0: No codecs found
xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x04: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel 8 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
puc0 at pci0 dev 22 function 3 "Intel 8 Series KT" rev 0x04: ports: 1 com
com4 at puc0 port 0 apic 8 int 19: ns16550a, 16 byte fifo
com4: probed fifo depth: 0 bytes
em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x04: msi, address b8:ca:3a:93:03:e8
ehci0 at pci0 dev 26 function 0 "Intel 8 Series USB" rev 0x04: apic 8 int 16
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia1 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x04: msi
azalia1: codecs: Realtek/0x0280
audio0 at azalia1
ehci1 at pci0 dev 29 function 0 "Intel 8 Series USB" rev 0x04: apic 8 int 23
usb2 at ehci1: USB revision 2.0
uhub2 at usb2 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
pcib0 at pci0 dev 31 function 0 "Intel Q87 LPC" rev 0x04
ahci0 at pci0 dev 31 function 2 "Intel 8 Series AHCI" rev 0x04: msi, AHCI 1.3
ahci0: port 0: 3.0Gb/s
ahci0: port 1: 1.5Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, WDC WD5003ABYX-1, 01.0> SCSI3 0/direct fixed naa.50014ee0038d67ab
sd0: 476940MB, 512 bytes/sector, 976773168 sectors
cd0 at scsibus1 targ 1 lun 0: <HL-DT-ST, DVD+-RW GT80N, A103> ATAPI 5/cdrom removable
ichiic0 at pci0 dev 31 function 3 "Intel 8 Series SMBus" rev 0x04: apic 8 int 18
iic0 at ichiic0
spdmem0 at iic0 addr 0x51: 4GB DDR3 SDRAM PC3-12800
spdmem1 at iic0 addr 0x53: 4GB DDR3 SDRAM PC3-12800
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT
uhub3 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.04 addr 2
uhidev0 at uhub3 port 1 configuration 1 interface 0 "Logitech USB Gaming Mouse" rev 2.00/46.00 addr 3
uhidev0: iclass 3/1
ums0 at uhidev0: 16 buttons, Z and W dir
wsmouse0 at ums0 mux 0
uhidev1 at uhub3 port 1 configuration 1 interface 1 "Logitech USB Gaming Mouse" rev 2.00/46.00 addr 3
uhidev1: iclass 3/0, 17 report ids
uhid0 at uhidev1 reportid 16: input=6, output=6, feature=0
uhid1 at uhidev1 reportid 17: input=19, output=19, feature=0
uhidev2 at uhub3 port 2 configuration 1 interface 0 "Logitech Logitech Illuminated Keyboard" rev 2.00/55.01 addr 4
uhidev2: iclass 3/1
ukbd0 at uhidev2: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev3 at uhub3 port 2 configuration 1 interface 1 "Logitech Logitech Illuminated Keyboard" rev 2.00/55.01 addr 4
uhidev3: iclass 3/0, 16 report ids
uhid2 at uhidev3 reportid 3: input=7, output=0, feature=0
uhid3 at uhidev3 reportid 16: input=6, output=6, feature=0
uhidev4 at uhub3 port 4 configuration 1 interface 0 "RDing TEMPERHUM1V1.2" rev 2.00/0.01 addr 5
uhidev4: iclass 3/1, 1 report id
ukbd1 at uhidev4 reportid 1: 8 variable keys, 5 key codes
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0
uhidev5 at uhub3 port 4 configuration 1 interface 1 "RDing TEMPERHUM1V1.2" rev 2.00/0.01 addr 5
uhidev5: iclass 3/1
ugold0 at uhidev5
uhub4 at uhub2 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.04 addr 2
uvideo0 at uhub4 port 4 configuration 1 interface 0 "Logitech QuickCam Pro 9000" rev 2.00/0.08 addr 3
video0 at uvideo0
uaudio0 at uhub4 port 4 configuration 1 interface 2 "Logitech QuickCam Pro 9000" rev 2.00/0.08 addr 3
uaudio0: audio rev 1.00, 2 mixer controls
audio1 at uaudio0
uhub5 at uhub4 port 5 configuration 1 interface 0 "VIA Labs, Inc. USB2.0 Hub" rev 2.10/90.90 addr 4
uhub6 at uhub5 port 1 configuration 1 interface 0 "VIA Labs, Inc. USB2.0 Hub" rev 2.10/90.90 addr 5
umass0 at uhub6 port 1 configuration 1 interface 0 "Western Digital My Passport 0748" rev 2.10/10.19 addr 6
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0: <WD, My Passport 0748, 1019> SCSI4 0/direct fixed
sd1: 1907697MB, 512 bytes/sector, 3906963456 sectors
ses0 at scsibus2 targ 1 lun 1: <WD, SES Device, 1019> SCSI4 13/enclosure services fixed
ses0: unable to read enclosure configuration
umass1 at uhub6 port 2 configuration 1 interface 0 "Western Digital My Passport 0748" rev 2.10/10.19 addr 7
umass1: using SCSI over Bulk-Only
scsibus3 at umass1: 2 targets, initiator 0
sd2 at scsibus3 targ 1 lun 0: <WD, My Passport 0748, 1019> SCSI4 0/direct fixed
sd2: 1907697MB, 512 bytes/sector, 3906963456 sectors
ses1 at scsibus3 targ 1 lun 1: <WD, SES Device, 1019> SCSI4 13/enclosure services fixed
ses1: unable to read enclosure configuration
ugold0: 2 sensors type si7006 (temperature and humidity)
umass2 at uhub6 port 3 configuration 1 interface 0 "Western Digital My Passport 0748" rev 2.10/10.19 addr 8
umass2: using SCSI over Bulk-Only
scsibus4 at umass2: 2 targets, initiator 0
sd3 at scsibus4 targ 1 lun 0: <WD, My Passport 0748, 1019> SCSI4 0/direct fixed
sd3: 1907697MB, 512 bytes/sector, 3906963456 sectors
ses2 at scsibus4 targ 1 lun 1: <WD, SES Device, 1019> SCSI4 13/enclosure services fixed
ses2: unable to read enclosure configuration
umass3 at uhub6 port 4 configuration 1 interface 0 "Western Digital My Passport 0730" rev 2.10/10.08 addr 9
umass3: using SCSI over Bulk-Only
scsibus5 at umass3: 2 targets, initiator 0
sd4 at scsibus5 targ 1 lun 0: <WD, My Passport 0730, 1008> SCSI4 0/direct fixed
sd4: 953837MB, 512 bytes/sector, 1953458176 sectors
ses3 at scsibus5 targ 1 lun 1: <WD, SES Device, 1008> SCSI4 13/enclosure services fixed
ses3: unable to read enclosure configuration
umass4 at uhub5 port 2 configuration 1 interface 0 "Western Digital Elements 10B8" rev 2.10/10.12 addr 10
umass4: using SCSI over Bulk-Only
scsibus6 at umass4: 2 targets, initiator 0
sd5 at scsibus6 targ 1 lun 0: <WD, Elements 10B8, 1012> SCSI4 0/direct fixed serial.105810b835354C4C3435
sd5: 1907697MB, 512 bytes/sector, 3906963456 sectors
umass5 at uhub5 port 3 configuration 1 interface 0 "Western Digital My Passport 0748" rev 2.10/10.10 addr 11
umass5: using SCSI over Bulk-Only
scsibus7 at umass5: 2 targets, initiator 0
sd6 at scsibus7 targ 1 lun 0: <WD, My Passport 0748, 1010> SCSI4 0/direct fixed
sd6: 1907697MB, 512 bytes/sector, 3906963456 sectors
ses4 at scsibus7 targ 1 lun 1: <WD, SES Device, 1010> SCSI4 13/enclosure services fixed
ses4: unable to read enclosure configuration
umass6 at uhub5 port 4 configuration 1 interface 0 "Western Digital My Passport 259D" rev 2.10/10.12 addr 12
umass6: using SCSI over Bulk-Only
scsibus8 at umass6: 2 targets, initiator 0
sd7 at scsibus8 targ 1 lun 0: <WD, My Passport 259D, 1012> SCSI4 0/direct fixed
sd7: 3815415MB, 512 bytes/sector, 7813969920 sectors
ses5 at scsibus8 targ 1 lun 1: <WD, SES Device, 1012> SCSI4 13/enclosure services fixed
ses5: unable to read enclosure configuration
uhub7 at uhub4 port 6 configuration 1 interface 0 "VIA Labs, Inc. USB2.0 Hub" rev 2.10/90.90 addr 13
uhub8 at uhub7 port 1 configuration 1 interface 0 "VIA Labs, Inc. USB2.0 Hub" rev 2.10/90.90 addr 14
umass7 at uhub8 port 1 configuration 1 interface 0 "Western Digital My Passport 0740" rev 2.10/10.03 addr 15
umass7: using SCSI over Bulk-Only
scsibus9 at umass7: 2 targets, initiator 0
sd8 at scsibus9 targ 1 lun 0: <WD, My Passport 0740, 1003> SCSI4 0/direct fixed
sd8: 953837MB, 512 bytes/sector, 1953458176 sectors
ses6 at scsibus9 targ 1 lun 1: <WD, SES Device, 1003> SCSI4 13/enclosure services fixed
ses6: unable to read enclosure configuration
umass8 at uhub8 port 3 configuration 1 interface 0 "Western Digital My Passport 0748" rev 2.10/10.10 addr 16
umass8: using SCSI over Bulk-Only
scsibus10 at umass8: 2 targets, initiator 0
sd9 at scsibus10 targ 1 lun 0: <WD, My Passport 0748, 1010> SCSI4 0/direct fixed
sd9: 1907697MB, 512 bytes/sector, 3906963456 sectors
ses7 at scsibus10 targ 1 lun 1: <WD, SES Device, 1010> SCSI4 13/enclosure services fixed
ses7: unable to read enclosure configuration
umass9 at uhub8 port 4 configuration 1 interface 0 "Western Digital My Passport 0748" rev 2.10/10.10 addr 17
umass9: using SCSI over Bulk-Only
scsibus11 at umass9: 2 targets, initiator 0
sd10 at scsibus11 targ 1 lun 0: <WD, My Passport 0748, 1010> SCSI4 0/direct fixed
sd10: 1907697MB, 512 bytes/sector, 3906963456 sectors
ses8 at scsibus11 targ 1 lun 1: <WD, SES Device, 1010> SCSI4 13/enclosure services fixed
ses8: unable to read enclosure configuration
umass10 at uhub7 port 2 configuration 1 interface 0 "Western Digital My Passport 0748" rev 2.10/10.19 addr 18
umass10: using SCSI over Bulk-Only
scsibus12 at umass10: 2 targets, initiator 0
sd11 at scsibus12 targ 1 lun 0: <WD, My Passport 0748, 1019> SCSI4 0/direct fixed
sd11: 1907697MB, 512 bytes/sector, 3906963456 sectors
ses9 at scsibus12 targ 1 lun 1: <WD, SES Device, 1019> SCSI4 13/enclosure services fixed
ses9: unable to read enclosure configuration
vscsi0 at root
scsibus13 at vscsi0: 256 targets
softraid0 at root
scsibus14 at softraid0: 256 targets
root on sd0a (50c630c4cfc3b21a.a) swap on sd0b dump on sd0b

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[dd
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: losing ipv6 connectivity after some uptime

Martin Pieuchot
Hey Paul,

Thanks for the report!

On 06/03/17(Mon) 12:13, Paul de Weerd wrote:

> [...]
> This weekend my workstation lost v6 connectivity.  I didn't notice, as
> I wasn't around (social commitments), but my backup script did.
> Investigating this problem, it looks like ndp lost the entry for the
> default gateway:
>
> $ netstat -rnf inet6 | awk '/^default/'  
> default         fe80::260:e0ff:fe52:f96%em0    UG 0     6880     -    56 em0
> $ ndp -an | grep `netstat -rnf inet6 | awk '/^default/ {print $2}'`
> fe80::260:e0ff:fe52:f96%em0          00:60:e0:52:0f:96     em0 expired   I R 3
                                                                              ^^
                                                  That's the key of the problem
>
> Deleting the expired entry doesn't seem very effective:

It *is* effective since it solved your problem.  A cached entry, like
the one referenced by your default route is no longer 'deleted' it is
'flushed'.  In practice it doesn't change much since such entries are
created automagically.  But you found a bug!

Diff below should solve that by resetting the 'asked' counter and allow
our NDP code to generate a new NS.  Just like the delete command does.

> [...]
> What else can I do to further debug this issue?

Next time this happen use tcpdump(8) and filter NS packets.  Try sending
a single packet using ping and see if/when a new NS is sent.


Index: netinet6/nd6.c
===================================================================
RCS file: /cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.205
diff -u -p -r1.205 nd6.c
--- netinet6/nd6.c 3 Mar 2017 08:01:59 -0000 1.205
+++ netinet6/nd6.c 6 Mar 2017 12:02:53 -0000
@@ -834,7 +834,9 @@ nd6_free(struct rtentry *rt, int gc)
  * caches, and disable the route entry not to be used in already
  * cached routes.
  */
- if (!ISSET(rt->rt_flags, RTF_STATIC|RTF_CACHED))
+ if (ISSET(rt->rt_flags, RTF_CACHED))
+ nd6_invalidate(rt);
+ else if (!ISSET(rt->rt_flags, RTF_STATIC))
  rtdeletemsg(rt, ifp, ifp->if_rdomain);
 
  if_put(ifp);

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: losing ipv6 connectivity after some uptime

Paul de Weerd
Hi Martin,

Thanks for the quick reply!

On Mon, Mar 06, 2017 at 01:12:12PM +0100, Martin Pieuchot wrote:
| > Deleting the expired entry doesn't seem very effective:
|
| It *is* effective since it solved your problem.  A cached entry, like
| the one referenced by your default route is no longer 'deleted' it is
| 'flushed'.  In practice it doesn't change much since such entries are
| created automagically.  But you found a bug!
|
| Diff below should solve that by resetting the 'asked' counter and allow
| our NDP code to generate a new NS.  Just like the delete command does.

Thanks for the diff, I will give it a shot.  Since this doesn't happen
frequently, it'll be hard to tell if it's fixed though.

| > [...]
| > What else can I do to further debug this issue?
|
| Next time this happen use tcpdump(8) and filter NS packets.  Try sending
| a single packet using ping and see if/when a new NS is sent.

That makes a lot of sense, and I should've included that information
in my initial report.  For completeness, I tried it on another machine
that has the same behaviour.  I'm running tcpdump on the affected host.

Pinging from another machine to the affected machine:

15:06:34.919375 00:60:e0:52:0f:96 33:33:ff:d9:dd:9d 86dd 86: 20xx:xxxx:xxxx::2 > ff02::1:ffd9:dd9d: icmp6: neighbor sol: who has 20xx:xxxx:xxxx:0:8a53:2eff:fed9:dd9d(src lladdr: 00:60:e0:52:0f:96) [icmp6 cksum ok] (len 32, hlim 255)
15:06:35.943394 00:60:e0:52:0f:96 33:33:ff:d9:dd:9d 86dd 86: 20xx:xxxx:xxxx::2 > ff02::1:ffd9:dd9d: icmp6: neighbor sol: who has 20xx:xxxx:xxxx:0:8a53:2eff:fed9:dd9d(src lladdr: 00:60:e0:52:0f:96) [icmp6 cksum ok] (len 32, hlim 255)
15:06:36.967041 00:60:e0:52:0f:96 33:33:ff:d9:dd:9d 86dd 86: 20xx:xxxx:xxxx::2 > ff02::1:ffd9:dd9d: icmp6: neighbor sol: who has 20xx:xxxx:xxxx:0:8a53:2eff:fed9:dd9d(src lladdr: 00:60:e0:52:0f:96) [icmp6 cksum ok] (len 32, hlim 255)

i.e. neighbor solicitations arrive just fine, the machine is just not
responding.

Pinging from the affected machine to anything on the internet (after
deleting the NDP entry):

15:06:51.269270 88:53:2e:d9:dd:9d 33:33:ff:52:0f:96 86dd 86: 20xx:xxxx:xxxx:0:90dd:36c4:11de:1043 > ff02::1:ff52:f96: icmp6: neighbor sol: who has fe80::260:e0ff:fe52:f96(src lladdr: 88:53:2e:d9:dd:9d) [icmp6 cksum ok] (len 32, hlim 255)
15:06:51.273479 00:60:e0:52:0f:96 88:53:2e:d9:dd:9d 86dd 86: 20xx:xxxx:xxxx::1 > 20xx:xxxx:xxxx:0:90dd:36c4:11de:1043: icmp6: neighbor adv: tgt is fe80::260:e0ff:fe52:f96(RSO)(tgt lladdr: 00:60:e0:52:0f:96) [icmp6 cksum ok] (len 32, hlim 255)
15:06:52.263210 88:53:2e:d9:dd:9d 33:33:ff:52:0f:96 86dd 86: 20xx:xxxx:xxxx:0:90dd:36c4:11de:1043 > ff02::1:ff52:f96: icmp6: neighbor sol: who has fe80::260:e0ff:fe52:f96(src lladdr: 88:53:2e:d9:dd:9d) [icmp6 cksum ok] (len 32, hlim 255)
15:06:52.264879 00:60:e0:52:0f:96 88:53:2e:d9:dd:9d 86dd 86: 20xx:xxxx:xxxx::1 > 20xx:xxxx:xxxx:0:90dd:36c4:11de:1043: icmp6: neighbor adv: tgt is fe80::260:e0ff:fe52:f96(RSO)(tgt lladdr: 00:60:e0:52:0f:96) [icmp6 cksum ok] (len 32, hlim 255)
15:06:53.263234 88:53:2e:d9:dd:9d 33:33:ff:52:0f:96 86dd 86: 20xx:xxxx:xxxx:0:90dd:36c4:11de:1043 > ff02::1:ff52:f96: icmp6: neighbor sol: who has fe80::260:e0ff:fe52:f96(src lladdr: 88:53:2e:d9:dd:9d) [icmp6 cksum ok] (len 32, hlim 255)
15:06:53.269814 00:60:e0:52:0f:96 88:53:2e:d9:dd:9d 86dd 86: 20xx:xxxx:xxxx::1 > 20xx:xxxx:xxxx:0:90dd:36c4:11de:1043: icmp6: neighbor adv: tgt is fe80::260:e0ff:fe52:f96(RSO)(tgt lladdr: 00:60:e0:52:0f:96) [icmp6 cksum ok] (len 32, hlim 255)

i.e. the machine is asking for the address of the default gateway, and
the default gateway is responding just fine, but the answer is
ignored.

Cheers,

Paul

| Index: netinet6/nd6.c
| ===================================================================
| RCS file: /cvs/src/sys/netinet6/nd6.c,v
| retrieving revision 1.205
| diff -u -p -r1.205 nd6.c
| --- netinet6/nd6.c 3 Mar 2017 08:01:59 -0000 1.205
| +++ netinet6/nd6.c 6 Mar 2017 12:02:53 -0000
| @@ -834,7 +834,9 @@ nd6_free(struct rtentry *rt, int gc)
|   * caches, and disable the route entry not to be used in already
|   * cached routes.
|   */
| - if (!ISSET(rt->rt_flags, RTF_STATIC|RTF_CACHED))
| + if (ISSET(rt->rt_flags, RTF_CACHED))
| + nd6_invalidate(rt);
| + else if (!ISSET(rt->rt_flags, RTF_STATIC))
|   rtdeletemsg(rt, ifp, ifp->if_rdomain);
|  
|   if_put(ifp);

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: losing ipv6 connectivity after some uptime

Martin Pieuchot
On 06/03/17(Mon) 15:18, Paul de Weerd wrote:
> Hi Martin,
> [...]
> i.e. the machine is asking for the address of the default gateway, and
> the default gateway is responding just fine, but the answer is
> ignored.

Sadly this information without the output of 'ndp -an' at the time, or
before/after, you're running the ping is useless.

We're trying to understand why the states of the software are not being
correctly updated when packets are being sent and/or received.  Printing
tcpdump(8) output only give us the packets point of view, printing
netstat(8) and ndp(8) outputs give us the states point of view.  We
need both :)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: losing ipv6 connectivity after some uptime

Paul de Weerd
On Mon, Mar 06, 2017 at 03:39:16PM +0100, Martin Pieuchot wrote:
| On 06/03/17(Mon) 15:18, Paul de Weerd wrote:
| > Hi Martin,
| > [...]
| > i.e. the machine is asking for the address of the default gateway, and
| > the default gateway is responding just fine, but the answer is
| > ignored.
|
| Sadly this information without the output of 'ndp -an' at the time, or
| before/after, you're running the ping is useless.

Mea culpa, I had that in my previous mail.  The ndp output doesn't
change while pinging / tcpdumping; not at the frequency with which I
was trying this.

| We're trying to understand why the states of the software are not being
| correctly updated when packets are being sent and/or received.  Printing
| tcpdump(8) output only give us the packets point of view, printing
| netstat(8) and ndp(8) outputs give us the states point of view.  We
| need both :)

ndp -an showed an expired entry, also after deletion.  It wasn't until
after I deleted the same entry many times (took about 20 runs on that
other machine) before things starting working again.  It was basically
the same behavior as what I described in my previous mail: delete the
entry with ndp -d, and it immediately returns as an expired entry.
Running ping didn't change the output of ndp.  Deleting the entry did
not (seem to) delete it, checking immediately after showed it as still
expired.

Here's what I was (repeatedly) doing while pinging:

[weerd@drop] $ ndp -an | grep fe80::260; doas ndp -d fe80::260:e0ff:fe52:f96%iwn0; ndp -an | grep fe80::260
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3
fe80::260:e0ff:fe52:f96%iwn0 (fe80::260:e0ff:fe52:f96%iwn0) deleted
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R

The only change is the number '3' (number of NS probes the node has
sent during the current state, according to ndp(8)) getting dropped
after deletion.  It's back shortly after though.  And then, at some
point (~20 deletions), the 'expired' changes to a couple of seconds of
expiry time and things start working again.

It seems that deleting the ndp entry while things are working fine,
greatly increases my chances of hitting this.  After deleting a couple
more times I got this state:

fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 11s       I R

which then turned into the

fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3

and the non-working situation again.


This is the output of while sleep .1; do ndp -an | grep ^fe80::2; done

fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 1s        I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 1s        I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 1s        I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 1s        I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 1s        I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 1s        I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 1s        I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3

When you see the 3 go to ' ', I delete the entry.  I see 3 neighbor
solicitations (including replies) and the situation is as it was
before. Repeatedly deleting a couple of times finally results in:

fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 3
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 1s        I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 1s        I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 1s        I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 1
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 1s        I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 1s        I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R 2
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 expired   I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 15s       R R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 15s       I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 14s       I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 14s       I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 14s       I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 14s       I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 14s       I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 14s       I R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 15s       R R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 15s       R R
fe80::260:e0ff:fe52:f96%iwn0         00:60:e0:52:0f:96    iwn0 14s       R R

And things are pinging again.  Leaving this running, I see the state
going back to 'expired' quite often, but everything keeps working.
Then deleting the ndp entry again a couple of times, things break.

Delete a few more times, things start working again.  Rinse, lather,
repeat :)

As these are machines I have at home (and they run softraid FDE), I
can't reboot into a new kernel easily to try your diff.  But now that
I have a way of reproducting this issue, I'll be sure to try tonight
and report back.

Thanks!

Cheers,

Paul

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: losing ipv6 connectivity after some uptime

Paul de Weerd
On Mon, Mar 06, 2017 at 04:39:16PM +0100, Paul de Weerd wrote:
| Delete a few more times, things start working again.  Rinse, lather,
| repeat :)
|
| As these are machines I have at home (and they run softraid FDE), I
| can't reboot into a new kernel easily to try your diff.  But now that
| I have a way of reproducting this issue, I'll be sure to try tonight
| and report back.

Home now, so I've given your diff a shot.  It looks like it solves the
issue.  I've been continously removing the NDP entry (without the
sleep .1), and connectivity is not great (hardly surprising), but it
works fine.  I've not been able to reproduce my issue with your diff.

Thanks again Martin!

Cheers,

Paul

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: losing ipv6 connectivity after some uptime

Matthieu Herrb-7
On Mon, Mar 06, 2017 at 07:09:46PM +0100, Paul de Weerd wrote:

> On Mon, Mar 06, 2017 at 04:39:16PM +0100, Paul de Weerd wrote:
> | Delete a few more times, things start working again.  Rinse, lather,
> | repeat :)
> |
> | As these are machines I have at home (and they run softraid FDE), I
> | can't reboot into a new kernel easily to try your diff.  But now that
> | I have a way of reproducting this issue, I'll be sure to try tonight
> | and report back.
>
> Home now, so I've given your diff a shot.  It looks like it solves the
> issue.  I've been continously removing the NDP entry (without the
> sleep .1), and connectivity is not great (hardly surprising), but it
> works fine.  I've not been able to reproduce my issue with your diff.
>
> Thanks again Martin!
>

Hi,

I've been seeing issues similar to those reported by Paul, but
appently only on my laptop using iwm0. Since I've other issues with
IPv6 with my access point (running OpenWRT 15.05.1), I've blaming my
AP and got used to restart the IPv6 connection from time to time.

With this patch the issue seem to be solved for now. So maybe my AP
isn't faulty after all.

Thanks Paul and Martin.
--
Matthieu Herrb

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: losing ipv6 connectivity after some uptime

Alexander Bluhm
In reply to this post by Martin Pieuchot
On Mon, Mar 06, 2017 at 01:12:12PM +0100, Martin Pieuchot wrote:
> Diff below should solve that by resetting the 'asked' counter and allow
> our NDP code to generate a new NS.  Just like the delete command does.

arptfree() calls arpinvalidate() unconditionally.  So I think we
should always call nd6_invalidate() here.

bluhm

> Index: netinet6/nd6.c
> ===================================================================
> RCS file: /cvs/src/sys/netinet6/nd6.c,v
> retrieving revision 1.205
> diff -u -p -r1.205 nd6.c
> --- netinet6/nd6.c 3 Mar 2017 08:01:59 -0000 1.205
> +++ netinet6/nd6.c 6 Mar 2017 12:02:53 -0000
> @@ -834,7 +834,9 @@ nd6_free(struct rtentry *rt, int gc)
>   * caches, and disable the route entry not to be used in already
>   * cached routes.
>   */
> - if (!ISSET(rt->rt_flags, RTF_STATIC|RTF_CACHED))
> + if (ISSET(rt->rt_flags, RTF_CACHED))
> + nd6_invalidate(rt);
> + else if (!ISSET(rt->rt_flags, RTF_STATIC))
>   rtdeletemsg(rt, ifp, ifp->if_rdomain);
>  
>   if_put(ifp);

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: losing ipv6 connectivity after some uptime

Martin Pieuchot
On 06/03/17(Mon) 23:26, Alexander Bluhm wrote:
> On Mon, Mar 06, 2017 at 01:12:12PM +0100, Martin Pieuchot wrote:
> > Diff below should solve that by resetting the 'asked' counter and allow
> > our NDP code to generate a new NS.  Just like the delete command does.
>
> arptfree() calls arpinvalidate() unconditionally.  So I think we
> should always call nd6_invalidate() here.

That should work too.

Index: netinet6/nd6.c
===================================================================
RCS file: /cvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.205
diff -u -p -r1.205 nd6.c
--- netinet6/nd6.c 3 Mar 2017 08:01:59 -0000 1.205
+++ netinet6/nd6.c 7 Mar 2017 13:06:13 -0000
@@ -748,6 +748,8 @@ nd6_free(struct rtentry *rt, int gc)
 
  splsoftassert(IPL_SOFTNET);
 
+ nd6_invalidate(rt);
+
  /*
  * we used to have pfctlinput(PRC_HOSTDEAD) here.
  * even though it is not harmful, it was not really necessary.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: losing ipv6 connectivity after some uptime

Alexander Bluhm
On Tue, Mar 07, 2017 at 02:07:02PM +0100, Martin Pieuchot wrote:
> On 06/03/17(Mon) 23:26, Alexander Bluhm wrote:
> > On Mon, Mar 06, 2017 at 01:12:12PM +0100, Martin Pieuchot wrote:
> > > Diff below should solve that by resetting the 'asked' counter and allow
> > > our NDP code to generate a new NS.  Just like the delete command does.
> >
> > arptfree() calls arpinvalidate() unconditionally.  So I think we
> > should always call nd6_invalidate() here.
>
> That should work too.

OK bluhm@

>
> Index: netinet6/nd6.c
> ===================================================================
> RCS file: /cvs/src/sys/netinet6/nd6.c,v
> retrieving revision 1.205
> diff -u -p -r1.205 nd6.c
> --- netinet6/nd6.c 3 Mar 2017 08:01:59 -0000 1.205
> +++ netinet6/nd6.c 7 Mar 2017 13:06:13 -0000
> @@ -748,6 +748,8 @@ nd6_free(struct rtentry *rt, int gc)
>  
>   splsoftassert(IPL_SOFTNET);
>  
> + nd6_invalidate(rt);
> +
>   /*
>   * we used to have pfctlinput(PRC_HOSTDEAD) here.
>   * even though it is not harmful, it was not really necessary.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: losing ipv6 connectivity after some uptime

Paul de Weerd
In reply to this post by Martin Pieuchot
On Tue, Mar 07, 2017 at 02:07:02PM +0100, Martin Pieuchot wrote:
| On 06/03/17(Mon) 23:26, Alexander Bluhm wrote:
| > On Mon, Mar 06, 2017 at 01:12:12PM +0100, Martin Pieuchot wrote:
| > > Diff below should solve that by resetting the 'asked' counter and allow
| > > our NDP code to generate a new NS.  Just like the delete command does.
| >
| > arptfree() calls arpinvalidate() unconditionally.  So I think we
| > should always call nd6_invalidate() here.
|
| That should work too.

With both this diff and the previous one, I still cannot reproduce the
problem I was experiencing.  I've deleted the ndp entry hundreds of
times but icmp6 packets kept flowing fine.

Thanks :)

Paul

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: losing ipv6 connectivity after some uptime

Matthieu Herrb-7
On Tue, Mar 07, 2017 at 09:44:55PM +0100, Paul de Weerd wrote:

> On Tue, Mar 07, 2017 at 02:07:02PM +0100, Martin Pieuchot wrote:
> | On 06/03/17(Mon) 23:26, Alexander Bluhm wrote:
> | > On Mon, Mar 06, 2017 at 01:12:12PM +0100, Martin Pieuchot wrote:
> | > > Diff below should solve that by resetting the 'asked' counter and allow
> | > > our NDP code to generate a new NS.  Just like the delete command does.
> | >
> | > arptfree() calls arpinvalidate() unconditionally.  So I think we
> | > should always call nd6_invalidate() here.
> |
> | That should work too.
>
> With both this diff and the previous one, I still cannot reproduce the
> problem I was experiencing.  I've deleted the ndp entry hundreds of
> times but icmp6 packets kept flowing fine.
>
> Thanks :)

Same here. Also no more IPv6 connectivity loss with the 2nd patch.

Thanks.
--
Matthieu Herrb

Loading...