Crash report!!!!

[stephenw10]

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: panic

So that's a completely different panic.
What exactly did you change?

[Antibiotic]

@stephenw10 Limiters settings

[stephenw10]

Right but what did you actually change? Added the limiter entirely?

[Antibiotic]

@stephenw10 Changed limits and flows figures

[stephenw10]

Hmm, was anything logged? Any alert shown other than the crash?

Did it crash immediately when you saved those changes?

[Antibiotic]

@stephenw10 '

1. None
2. None
3. Yes

[stephenw10]

Hmm, it is repeatable?

We'd need to replicate it locally to dig further so steps to reproduce would help a lot.

[Antibiotic]

@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

[Antibiotic]

@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.

[stephenw10]

And just resaving the Limiters again did not reproduce the crash?

[Antibiotic]

@stephenw10 Sorry, already removed Limiters and making state resetting's

[kprovost]

@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.

[Antibiotic]

@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?

[kprovost]

@Antibiotic You've somehow configured your system so that the OpenVPN tunnelled traffic goes down the OpenVPN tunnel.

[stephenw10]

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.

[Antibiotic]

@stephenw10 That , what I have . Is this incorrect?

[stephenw10]

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.

[Antibiotic]

@stephenw10 said in Crash report!!!!:

Try resaving the system default gateway

Did now!

[stephenw10]

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.

[Antibiotic]

@stephenw10 said in Crash report!!!!:

I would disable those clients from accepting routes like that

What do you mean, what better to disable?