Bug #7611
closed
Diagnostics/Routes ipv6 ( netstat ), causes kernel panic
Added by Pi Ba almost 7 years ago. Updated almost 5 years ago.
0%
Description
Diagnostics/Routes ipv6 ( netstat ), causes kernel panic
Several crashdumps uploaded past few hours.. (my ip ends with .219)
After disabling/enabling my wan interface and then visiting the diagnostics/routes page the IPv4 routes show on the page, but the IPv6 part stays empty while pfSense crashes in the background..
Updated by Pi Ba almost 7 years ago
For easiest reproduction ive found the following settings:
Gif interface with parent:wan ,gifremote: 4.4.4.4 ,giftunnellocal: 44::44 ,giftunnelremote: 44::44
Its not assigned to any OPT interface and both wan and lan have ipv6 set to none.
At first it works, but after disabling/enabling the connection of the virtual nic, visiting the diagnostics/routes will cause a panic.
Updated by Jim Pingle almost 7 years ago
- Status changed from New to Feedback
- Priority changed from High to Low
I can't seem to reproduce this as stated. I have a system with a GIF tunnel and I can disable/enable its WAN (it's a VM, so disconnect/unplug, essentially) and it recovers fine, routes are still there. There must be some other component to your system configuration at play here.
The crash does look like it's having trouble loading a sysctl:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x0
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80da6d59
stack pointer = 0x28:0xfffffe004e2c2520
frame pointer = 0x28:0xfffffe004e2c2670
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 88201 (netstat)
db:0:kdb.enter.default> show pcpu cpuid = 0 dynamic pcpu = 0xaf0200 curthread = 0xfffff80030bb2500: pid 88201 "netstat" curpcb = 0xfffffe004e2c2cc0 fpcurthread = 0xfffff80030bb2500: pid 88201 "netstat" idlethread = 0xfffff800042e3000: tid 100003 "idle: cpu0" curpmap = 0xfffff80013304138 tssp = 0xffffffff82a1eb10 commontssp = 0xffffffff82a1eb10 rsp0 = 0xfffffe004e2c2cc0 gs32p = 0xffffffff82a25368 ldt = 0xffffffff82a253a8 tss = 0xffffffff82a25398 db:0:kdb.enter.default> bt Tracing pid 88201 tid 100583 td 0xfffff80030bb2500 sysctl_dumpentry() at sysctl_dumpentry+0xf9/frame 0xfffffe004e2c2670 rn_walktree() at rn_walktree+0x70/frame 0xfffffe004e2c26a0 sysctl_rtsock() at sysctl_rtsock+0x1c2/frame 0xfffffe004e2c28b0 sysctl_root_handler_locked() at sysctl_root_handler_locked+0xbf/frame 0xfffffe004e2c28f0 sysctl_root() at sysctl_root+0x1cd/frame 0xfffffe004e2c2970 userland_sysctl() at userland_sysctl+0x1c4/frame 0xfffffe004e2c2a20 sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe004e2c2ad0 amd64_syscall() at amd64_syscall+0x4ce/frame 0xfffffe004e2c2bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe004e2c2bf0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8013c9a0a, rsp = 0x7fffffffe998, rbp = 0x7fffffffe9d0 ---
I see some traces of CARP in the message buffer from the crash, and routing errors that would appear to be related more to CARP (or the CARP transition):
<5>em0: link state changed to UP <6>em0: promiscuous mode enabled <6>carp: 2@em0: INIT -> BACKUP (initialization complete) <6>carp: 1@em0: INIT -> BACKUP (initialization complete) <6>carp: 1@em0: BACKUP -> INIT (hardware interface up) <6>carp: 1@em0: INIT -> BACKUP (initialization complete) <5>gif3: link state changed to DOWN <5>gif3: link state changed to UP <7>ifa_maintain_loopback_route: deletion failed for interface em0: 3 <7>ifa_maintain_loopback_route: deletion failed for interface em0: 3 <7>ifa_maintain_loopback_route: deletion failed for interface em0: 3 <6>carp: 2@em0: BACKUP -> INIT (hardware interface up) <6>carp: 2@em0: INIT -> BACKUP (initialization complete) <7>ifa_maintain_loopback_route: deletion failed for interface em0: 3 <7>ifa_maintain_loopback_route: deletion failed for interface em0: 3 <7>ifa_maintain_loopback_route: deletion failed for interface em0: 3 <6>carp: 1@em0: BACKUP -> INIT (hardware interface up) <6>carp: 1@em0: INIT -> BACKUP (initialization complete) <6>carp: 1@em0: BACKUP -> INIT (hardware interface up) <6>carp: 1@em0: INIT -> BACKUP (initialization complete) <7>ifa_maintain_loopback_route: deletion failed for interface em0: 3 <7>ifa_maintain_loopback_route: deletion failed for interface em0: 3 <7>ifa_maintain_loopback_route: deletion failed for interface em0: 3 <6>carp: 1@em0: BACKUP -> INIT (hardware interface up) <6>carp: 1@em0: INIT -> BACKUP (initialization complete) <6>carp: 1@em0: BACKUP -> INIT (hardware interface up) <6>carp: 1@em0: INIT -> BACKUP (initialization complete) <5>gif3: link state changed to DOWN <5>gif3: link state changed to UP <6>carp: 2@em0: BACKUP -> MASTER (master timed out)
Can you try it on a bare system or remove/disable some parts of that configuration to see if there is some other required component to reproduce the problem?
It does look like an OS-level issue but if we can reliably reproduce it then it's much more likely to be fixed.
Updated by Pi Ba almost 7 years ago
Ok new repro with a fresh virtual install on virtualbox of pfSense-CE-2.4.0-BETA-amd64-20170615-0858.iso with 1 bridged nic.
Assign em0 to wan, wait for it to boot.
Login to webgui, skip the wizard, configure a gif interface with 4.4.4.4 44::44 44::44 and save.
Visit diagnostics/routes, and keep the page open.
Disable/enable the virtual nic, wait 30 seconds and it panics by the page refresh.
Filename: /var/crash/textdump.tar.0 ddb.txt06000014000013120543555 7075 ustarrootwheeldb:0:kdb.enter.default> run lockinfo db:1:lockinfo> show locks No such command db:1:locks> show alllocks No such command db:1:alllocks> show lockedvnods Locked vnodes db:0:kdb.enter.default> show pcpu cpuid = 1 dynamic pcpu = 0xfffffe00b97ee200 curthread = 0xfffff8001bc72500: pid 38732 "netstat" curpcb = 0xfffffe0050218cc0 fpcurthread = 0xfffff8001bc72500: pid 38732 "netstat" idlethread = 0xfffff800042e2a00: tid 100004 "idle: cpu1" curpmap = 0xfffff8000561e138 tssp = 0xffffffff82a1eb78 commontssp = 0xffffffff82a1eb78 rsp0 = 0xfffffe0050218cc0 gs32p = 0xffffffff82a253d0 ldt = 0xffffffff82a25410 tss = 0xffffffff82a25400 db:0:kdb.enter.default> bt Tracing pid 38732 tid 100549 td 0xfffff8001bc72500 sysctl_dumpentry() at sysctl_dumpentry+0xf9/frame 0xfffffe0050218670 rn_walktree() at rn_walktree+0x70/frame 0xfffffe00502186a0 sysctl_rtsock() at sysctl_rtsock+0x1c2/frame 0xfffffe00502188b0 sysctl_root_handler_locked() at sysctl_root_handler_locked+0xbf/frame 0xfffffe00502188f0 sysctl_root() at sysctl_root+0x1cd/frame 0xfffffe0050218970 userland_sysctl() at userland_sysctl+0x1c4/frame 0xfffffe0050218a20 sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe0050218ad0 amd64_syscall() at amd64_syscall+0x4ce/frame 0xfffffe0050218bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0050218bf0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8013c9a0a, rsp = 0x7fffffffe998, rbp = 0x7fffffffe9d0 ---
Updated by
Updated by Jim Pingle over 6 years ago
I can only seem to reproduce this when the same address is used as both the "GIF tunnel local address" and "GIF tunnel remote address", which does not make any sense as a configuration.
Granted, I wouldn't expect it to panic, but why should that be considered a valid configuration?
We can add input validation to prevent the incorrect settings from being used, but otherwise, if you can replicate that panic on FreeBSD it should be submitted directly to them in a PR at https://bugs.freebsd.org/bugzilla/
Updated by Jim Pingle almost 5 years ago
- Status changed from Feedback to Not a Bug