Crash report!!!!
-
-
Backtrace:
db:1:pfs> bt Tracing pid 0 tid 100013 td 0xfffff80001974740 kdb_enter() at kdb_enter+0x33/frame 0xfffffe00c59ed370 panic() at panic+0x43/frame 0xfffffe00c59ed3d0 vm_fault() at vm_fault+0x15cc/frame 0xfffffe00c59ed4f0 vm_fault_trap() at vm_fault_trap+0xb0/frame 0xfffffe00c59ed540 trap_pfault() at trap_pfault+0x1d6/frame 0xfffffe00c59ed5a0 calltrap() at calltrap+0x8/frame 0xfffffe00c59ed5a0 --- trap 0xc, rip = 0xffffffff84451b37, rsp = 0xfffffe00c59ed670, rbp = 0xfffffe00c59ed6f0 --- fq_codel_enqueue() at fq_codel_enqueue+0x137/frame 0xfffffe00c59ed6f0 dummynet_io() at dummynet_io+0x26f/frame 0xfffffe00c59ed740 pf_dummynet_route() at pf_dummynet_route+0x3b9/frame 0xfffffe00c59ed830 pf_route() at pf_route+0x28e/frame 0xfffffe00c59ed910 pf_test() at pf_test+0xe28/frame 0xfffffe00c59edac0 pf_check_in() at pf_check_in+0x27/frame 0xfffffe00c59edae0 pfil_mbuf_in() at pfil_mbuf_in+0x38/frame 0xfffffe00c59edb10 ip_input() at ip_input+0x3aa/frame 0xfffffe00c59edb70 netisr_dispatch_src() at netisr_dispatch_src+0x22c/frame 0xfffffe00c59edbc0 ether_demux() at ether_demux+0x149/frame 0xfffffe00c59edbf0 ether_nh_input() at ether_nh_input+0x36d/frame 0xfffffe00c59edc50 netisr_dispatch_src() at netisr_dispatch_src+0xaf/frame 0xfffffe00c59edca0 ether_input() at ether_input+0x69/frame 0xfffffe00c59edd00 iflib_rxeof() at iflib_rxeof+0xc46/frame 0xfffffe00c59ede00 _task_fn_rx() at _task_fn_rx+0x72/frame 0xfffffe00c59ede40 gtaskqueue_run_locked() at gtaskqueue_run_locked+0x14e/frame 0xfffffe00c59edec0 gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc2/frame 0xfffffe00c59edef0 fork_exit() at fork_exit+0x7f/frame 0xfffffe00c59edf30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00c59edf30 --- trap 0, rip = 0, rsp = 0, rbp = 0 ---config_aqm Unable to configure flowset, flowset busy! config_aqm Unable to configure flowset, flowset busy! config_aqm Unable to configure flowset, flowset busy! panic: vm_fault_lookup: fault on nofault entry, addr: 0xfffffe0103234000 cpuid = 2 time = 1715514190 KDB: enter: panicSo that's a completely different panic.
What exactly did you change? -
@stephenw10 Limiters settings
-
Right but what did you actually change? Added the limiter entirely?
-
@stephenw10 Changed limits and flows figures
-
Hmm, was anything logged? Any alert shown other than the crash?
Did it crash immediately when you saved those changes?
-
- None
- None
- Yes
-
Hmm, it is repeatable?
We'd need to replicate it locally to dig further so steps to reproduce would help a lot.
-
@stephenw10 Idk, will it help, that what I found i sys.log. That was on next reboot after crash
2024-05-12 19:25:14.079708+03:00 check_reload_status 643 Reloading filter
2024-05-12 19:25:15.115594+03:00 php-fpm 592 /rc.newwanip: rc.newwanip: Info: starting on igc1.
2024-05-12 19:25:15.115937+03:00 php-fpm 592 /rc.newwanip: rc.newwanip: on (IP address: 192.168.10.1) (interface: LAN[lan]) (real interface: igc1).
2024-05-12 19:25:15.401258+03:00 kernel - config_aqm Unable to configure flowset, flowset busy!
2024-05-12 19:25:15.602269+03:00 kernel - config_aqm Unable to configure flowset, flowset busy!
2024-05-12 19:25:15.602325+03:00 kernel - config_aqm Unable to configure flowset, flowset busy!
2024-05-12 19:25:16.004364+03:00 kernel - config_aqm Unable to configure flowset, flowset busy!
2024-05-12 19:25:16.004547+03:00 kernel - config_aqm Unable to configure flowset, flowset busy!
2024-05-12 19:25:16.216719+03:00 php-fpm 592 /rc.newwanip: The command '/sbin/route -n6 get 'default' 2>/dev/null | /usr/bin/egrep 'flags: <.PROTO.>'' returned exit code '1', the output was ''
2024-05-12 19:25:17.425245+03:00 php-fpm 592 /rc.newwanip: Resyncing OpenVPN instances for interface LAN.
2024-05-12 19:25:17.471028+03:00 php-fpm 592 /rc.newwanip: Creating rrd update script
2024-05-12 19:25:19.496269+03:00 php-fpm 592 /rc.newwanip: Netgate pfSense Plus package system has detected an IP change or dynamic WAN reconnection - 192.168.10.1 -> 192.168.10.1 - Restarting packages.
2024-05-12 19:25:19.496416+03:00 check_reload_status 643 Starting packages
2024-05-12 19:25:19.500231+03:00 check_reload_status 643 Reloading filter
2024-05-12 19:25:19.500275+03:00 check_reload_status 643 Reloading filter
2024-05-12 19:25:20.534000+03:00 php-fpm 87873 /rc.start_packages: Restarting/Starting all packages.
2024-05-12 19:25:20.829266+03:00 kernel - config_aqm Unable to configure flowset, flowset busy!I think will remove Limiters as full of bugs
-
@stephenw10 said in Crash report!!!!:
further so steps to reproduce would help a lot
Steps , what I did
Untick all offloads (Limiters were already) , than switch off back all offloads get first crash. After reboot changed some settings in Limiters as above in my post, get second crash. Next step remove Limiters and waiting now third crash. -
And just resaving the Limiters again did not reproduce the crash?
-
@stephenw10 Sorry, already removed Limiters and making state resetting's
-
@stephenw10 said in Crash report!!!!:
Hmm, backtrace is unusually long
It's a routing loop. The OpenVPN traffic is being routing into the OpenVPN tunnel. Sooner or later we run out of stack and crash.
It's a bug in if_ovpn that it doesn't discard this traffic, but it's also a configuration error. Once the bug is fixed the tunnel still won't work.
-
@kprovost said in Crash report!!!!:
but it's also a configuration error.
What do you mean, in my configuration error? Or OpenVPN have error itself?
-
@Antibiotic You've somehow configured your system so that the OpenVPN tunnelled traffic goes down the OpenVPN tunnel.
-
Check the routing table in Diag > Routes. Is your default route getting set to the OpenVPN gateway?
Make sure the system default gateway is set to the WAN gateway in Sys > Routing > Gateways.
-
-
Hmm, seems like you don't have a default route there for some reason. Try resaving the system default gateway and then recheck the routing table.
-
-
Ok you should be good.
Do you see the OpenVPN server IPs there as static routes?
Those /1 routes you see there are being pushed to you by the VPN providers. I would disable those clients from accepting routes like that. You don't need that if you;re policy routing traffic across them.
