pfSense+ 23.01 on SG4860 - crashes when want to save a xml backup
-
Hi folks !!!
As Im putting on the subject my SG4860 Netgate appliance, with pfSense+ 23.01 crash when wants to download a .xml backup from the webgui.
Have we some other way to copy the .xml file to take a backup of that ?
Accessing via scp to the file system the confing.xml is the config file that we download from Diagnostics -> Backup & Restore -> Backup & Restore ?
Here I put the terminal cli log of the crash. If you see the all dump with the restart included, please go to here
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 0000.00.00 00:00:00 =~=~=~=~=~=~=~=~=~=~=~= FreeBSD/amd64 (fw-pfsense) (ttyu1) Netgate SG-4860 - Serial: 1104180143 - Netgate Device ID: 9b0f1d4745ce87fe6116 *** Welcome to Netgate pfSense Plus 23.01-RELEASE (amd64) on fw-pfsense *** INET_Fibertel (wan) -> igb4 -> v4/DHCP4: 000.000.000.000/00 LAN_USERS (lan) -> igb0 -> v4: 192.168.0.0/24 INET_Telecentro (opt1) -> igb5 -> v4/DHCP4: 000.000.000.000/00 LAN_SERVERS (opt2) -> igb1 -> v4: 192.168.0.0/24 INET_GSM (opt3) -> ue0 -> v4/DHCP4: 000.000.000.000/00 0) Logout (SSH only) 9) pfTop 1) Assign Interfaces 10) Filter Logs 2) Set interface(s) IP address 11) Restart webConfigurator 3) Reset webConfigurator password 12) PHP shell + Netgate pfSense Plus tools 4) Reset to factory defaults 13) Update from console 5) Reboot system 14) Disable Secure Shell (sshd) 6) Halt system 15) Restore recent configuration 7) Ping host 16) Restart PHP-FPM 8) Shell Enter an option: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x1c8 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff81318330 stack pointer = 0x0:0xfffffe00107dc140 frame pointer = 0x0:0xfffffe00107dc140 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 = 0 (if_io_tqg_1) rdi: fffff80237b86c98 rsi: 1c8 rdx: 3c rcx: 3c r8: fffff80237b86ad0 r9: 1 rax: fffff80237b86c98 rbx: 3c rbp: fffffe00107dc140 r10: fffffe008ecc36d0 r11: fffffe00107dc4f0 r12: 68 r13: fffff80152c94b00 r14: fffff80237b86c00 r15: 6 trap number = 12 panic: page fault cpuid = 1 time = 1680171832 KDB: enter: panic [ thread pid 0 tid 100013 ] Stopped at kdb_enter+0x32: movq $0,0x27bd313(%rip) db:0:kdb.enter.default> textdump set textdump set db:0:kdb.enter.default> capture on db:0:kdb.enter.default> run pfs db:1:pfs> bt Tracing pid 0 tid 100013 td 0xfffffe0011ff6000 kdb_enter() at kdb_enter+0x32/frame 0xfffffe00107dbf00 vpanic() at vpanic+0x182/frame 0xfffffe00107dbf50 panic() at panic+0x43/frame 0xfffffe00107dbfb0 trap_fatal() at trap_fatal+0x409/frame 0xfffffe00107dc010 trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00107dc070 calltrap() at calltrap+0x8/frame 0xfffffe00107dc070 --- trap 0xc, rip = 0xffffffff81318330, rsp = 0xfffffe00107dc140, rbp = 0xfffffe00107dc140 --- memmove_erms() at memmove_erms+0x30/frame 0xfffffe00107dc140 m_pullup() at m_pullup+0x19f/frame 0xfffffe00107dc180 ipfw_chk() at ipfw_chk+0x1082/frame 0xfffffe00107dc3c0 ipfw_check_frame() at ipfw_check_frame+0x13c/frame 0xfffffe00107dc4a0 pfil_run_hooks() at pfil_run_hooks+0x97/frame 0xfffffe00107dc4e0 ether_output_frame() at ether_output_frame+0x94/frame 0xfffffe00107dc510 ether_output() at ether_output+0x66a/frame 0xfffffe00107dc5a0 ip_output_send() at ip_output_send+0xde/frame 0xfffffe00107dc5e0 ip_output() at ip_output+0x1345/frame 0xfffffe00107dc6e0 tcp_default_output() at tcp_default_output+0x1d2b/frame 0xfffffe00107dc8b0 tcp_output() at tcp_output+0x10/frame 0xfffffe00107dc8d0 tcp_do_segment() at tcp_do_segment+0x3164/frame 0xfffffe00107dc9a0 tcp_input_with_port() at tcp_input_with_port+0x100d/frame 0xfffffe00107dcb00 tcp_input() at tcp_input+0xb/frame 0xfffffe00107dcb10 ip_input() at ip_input+0x229/frame 0xfffffe00107dcb70 netisr_dispatch_src() at netisr_dispatch_src+0x2a6/frame 0xfffffe00107dcbc0 ether_demux() at ether_demux+0x144/frame 0xfffffe00107dcbf0 ether_nh_input() at ether_nh_input+0x353/frame 0xfffffe00107dcc50 netisr_dispatch_src() at netisr_dispatch_src+0xb9/frame 0xfffffe00107dcca0 ether_input() at ether_input+0x69/frame 0xfffffe00107dcd00 iflib_rxeof() at iflib_rxeof+0xbdb/frame 0xfffffe00107dce00 _task_fn_rx() at _task_fn_rx+0x72/frame 0xfffffe00107dce40 gtaskqueue_run_locked() at gtaskqueue_run_locked+0x15d/frame 0xfffffe00107dcec0 gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc3/frame 0xfffffe00107dcef0 fork_exit() at fork_exit+0x7e/frame 0xfffffe00107dcf30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00107dcf30
It is me Ruben
Bootable Computaci贸n - Argentina.
pfSense/Netgate Certificate Partner
Pardon for my English - I am not an English speaker.
Thanks a lot for yours invaluable time. -
@bootable I have a sg4860 on 23.01, and I just ran through doing all kinds of iterations of backup of the config.
with extra data, with rrd, with encryption, all or just part of a the config, etc. I am not seeing any issues..
-
Hi @johnpoz, well with the previus version of pfSense+I had no issues with any function.
Its start when I update to 23.01
The crazy thing is if I access to the webgui via my publica IP (behind a NAT and a rule that permit access only from some hosts) I can download the backup via webgui with out problem.
Other thing that I see that does not works like before, is the limiters, but that is a topic for other post !.
It is me Ruben
Bootable Computaci贸n - Argentina.
pfSense/Netgate Certificate Partner
Pardon for my English - I am not an English speaker.
Thanks a lot for yours invaluable time. -
@bootable so your saying the problem is only if you hit your lan side IP of the gui from lan side. If you hit your wan (publicIP) from the lan side it all works? Yeah that seems maybe coincidental with it just not failing all the time? I for sure can not think of anything off the top of my head were what IP you hit would come into play?
via my publica IP (behind a NAT and a rule that permit access only from some hosts)
What is this about a nat? Accessing your wan IP, lets say public of 1.2.3.4 from a lan side device lets say 192.168.1.100 wouldn't need to be natted at all.. Pfsense is directly connected to this 192.168.1 network - why would it be natted to your 1.2.3.4 address?
-
That backtrace is quite close to this, so I suspect the fix there would correct it:
https://redmine.pfsense.org/issues/13938You can get that fix through the System Patches package, it's in the built-in Recommended Patches list.
Remember: Upvote with the 馃憤 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
Hi @johnpoz, yes that right, exactly, but the last 20 time that I tried via local LAN IP, goes direct to to the dump, thats the weird.
-
Hi @jimp I will try it, thanks !!
