Messages

Yup, I have disabled Turbo, and I still get 1 Gigabit downloads through Zenarmor.

I have all 10Gb+ internally and ZA just did not work at all. I stopped paying after they paywalled multi core outside my home sub and switched to Unifi. They have no issues IPS/IDS at line speed, turns out you can just not support companies who ride us to enterprise then stop supporting the users who got them there. That said I know no enterprise who would actually use this, it's too much for small businesses and doesn't offer nearly as much as actual enterprise offerings in this space.

I have the same chip and I get 3Gbps MAX out of a 10Gb connection so it may just be the chip though its a fast chip...old.

I locked intel5 prior to upgrading so I wouldn't lose the kernel

intel5 running, no issues that I can see so far. Mellanox (igb)

As a note, this only occurred when trying to upgrade from the base image that's installed to the latest patch.

Edit. Going over the logs it looked like the issue was either ZFS corruption which could be RAM or SSD. I replaced with another SSD and same issue so I replaced the ram and stressed tested it with what caused the last few crashes (loading large geoip ranges and any large firewall alias). After loading everything, I've had no crashes so I'm thinking I just had bad RAM.

Stood up a system and keep getting these crashes, either the box will freeze up and not load anything while passing internet or it will force reboot.

Fatal trap 9: general protection fault while in kernel mode
cpuid = 7; apic id = 07
instruction pointer   = 0x20:0xffffffff81093ab1
stack pointer           = 0x28:0xfffffe01136c0780
frame pointer           = 0x28:0xfffffe01136c08d0
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      = 86082 (python3.11)
rdi: fffffe000ba53a78 rsi: fffffe000ba53a78 rdx: ffbff803d1de3558
rcx: 0000000000000000  r8: fffff803e86e7000  r9: 0000000000000078
rax: 0000000000000000 rbx: fffffe0000000000 rbp: fffffe01136c08d0
r10: fffff8000e22dd38 r11: fffff803e86e7000 r12: 0000000000000028
r13: fffff8000e22dd38 r14: fffffe000ba53a40 r15: 80000001caa78405
trap number      = 9
panic: general protection fault
cpuid = 7
time = 1729201319
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01136c04c0
vpanic() at vpanic+0x131/frame 0xfffffe01136c05f0
panic() at panic+0x43/frame 0xfffffe01136c0650
trap_fatal() at trap_fatal+0x40b/frame 0xfffffe01136c06b0
calltrap() at calltrap+0x8/frame 0xfffffe01136c06b0
--- trap 0x9, rip = 0xffffffff81093ab1, rsp = 0xfffffe01136c0780, rbp = 0xfffffe01136c08d0 ---
pmap_remove_pages() at pmap_remove_pages+0x6b1/frame 0xfffffe01136c08d0
exec_new_vmspace() at exec_new_vmspace+0x235/frame 0xfffffe01136c0930
exec_elf64_imgact() at exec_elf64_imgact+0x61b/frame 0xfffffe01136c09f0
kern_execve() at kern_execve+0x795/frame 0xfffffe01136c0d80
sys_execve() at sys_execve+0x56/frame 0xfffffe01136c0e00
amd64_syscall() at amd64_syscall+0x100/frame 0xfffffe01136c0f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe01136c0f30
--- syscall (59, FreeBSD ELF64, execve), rip = 0x8242cc69a, rsp = 0x83d5f7358, rbp = 0x83d5f73d0 ---
KDB: enter: panic
panic.txt0600003014704302247  7134 ustarrootwheelgeneral protection faultversion.txt0600007514704302247  7540 ustarrootwheelFreeBSD 14.1-RELEASE-p2 stable/24.7-n267758-4ad7ad40bc77 SMP

Same issue here, clean install.

Nope, still an issue with a clean install.

same error here.

Same, full lockup after some time with a clean install.

not to piggyback this but you are correct uninstalling and deleting that config does NOT remove the config, I still have old bouncers after reinstall even with a supposed clean uninstall.

If you happen to have breezeline there are multiple people in Columbus Ohio area with ISP related issues and of course they will always tell you there isn't an issue. Just FYI your ISP is ALWAYS lying to you, always assume ISP issue. I'll say this looks a lot like just that, I'd always suggest disabling all v6 in WAN interface.

I have leases marked abandoned that I can't delete. I don't know why. They are set to expire, so I believe they will go away then.

Still a bug though since that's unexpected behavior + it worked on the previous release, glad to see I'm not the only one

Bump

DHCP leases that are active dynamic and dynamic in-active cannot be deleted, the only error I see is this:

10.10.10.1 gateway.mydomain.com - [05/Aug/2023:19:33:06 -0400] "POST /api/dhcp/leases/delLease/10.0.10.10 HTTP/1.1" 400 84 "https://gateway.mydomain.com/ui/dhcpv4/leases" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Safari/605.1.15"

Edit: Same results when not using the custom domain, i.e. direct to IP of OPNSense