Random reboots pfSense 2.1.5 VM [SOLVED]
-
Because that's a re-install anyway.
-
Yea, I'll give x64 another try. But I don't know when I can have that service window.
Now i crashed again. And yet again this seems to be related to OpenVPN.
I had a OpenVPN connection @ 09.45, just seconds after it crashed. So this must be OpenVPN related.
Should I open a ticket?EDIT: And again - OpenVPN connection @ 10.12, crash just right after..
-
did you enable hardware crypto by any chance?
i vaguely remember I once tried this setting on esxi and it resulted in "fatal trap xxx"
-
did you enable hardware crypto by any chance?
i vaguely remember I once tried this setting on esxi and it resulted in "fatal trap xxx"
Yep, HW Crypto enabled (BSD Cryptodev engine).
Disable it now, hope it helps.But i love HW decryption :(
Lets see the result.
-
I think we can mark this as solved for now ;D
Since HW-crypto for OpenVPN was turned off, I've not had a single reboot.I'd call this a bug.
Thanks all!
-
What crypto hardware were you using (or trying to use)? Is ESXi presenting some virtual hardware to the OS the it thinks it can use with the crypto framework?
I don't think you've lost anything. ;)
Steve
-
This just seem to have started again.
And I'm not ready to do a 2.2 upgrade just yet. Seems to be too many IPSec related issues, and IPSec is very important here.Can't find anything related to the reboots this time, see log 9.48 is the last entry before reboot:
Jan 30 11:47:24 kernel: Features2=0x80802001 <sse3,cx16,popcnt,hv>Jan 30 11:47:24 kernel: Features=0x1783fbff <fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse,sse2,htt>Jan 30 11:47:24 kernel: Origin = "AuthenticAMD" Id = 0x100f91 Family = 10 Model = 9 Stepping = 1
Jan 30 11:47:24 kernel: CPU: AMD Opteron
Processor 6128 (1999.86-MHz 686-class CPU)
Jan 30 11:47:24 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
Jan 30 11:47:24 kernel: root@pf2_1_1_i386.pfsense.org:/usr/obj.i386/usr/pfSensesrc/src/sys/pfSense_SMP.8 i386
Jan 30 11:47:24 kernel: FreeBSD 8.3-RELEASE-p16 #0: Mon Aug 25 08:25:41 EDT 2014
Jan 30 11:47:24 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
Jan 30 11:47:24 kernel: The Regents of the University of California. All rights reserved.
Jan 30 11:47:24 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
Jan 30 11:47:24 kernel: Copyright (c) 1992-2012 The FreeBSD Project.
Jan 30 11:47:24 syslogd: kernel boot file is /boot/kernel/kernel
Jan 30 09:48:59 lighttpd[35746]: (connections.c.137) (warning) close: 13 Connection reset by peer</fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse,sse2,htt></sse3,cx16,popcnt,hv> -
Did you ever try a 64bit install?
Steve
-
Try, yes. But didn't get WAN-access to work so reverted to x86 after 45mins.
But I still havn't been able to find anything that should relate to random reboots on x86 FreeBSD on x86 compatible hardware and x86 compatible hypervisor. -
Try, yes. But didn't get WAN-access to work so reverted to x86 after 45mins.
In a different VM I'm guessing? Sounds like the usual circumstance when changing MAC on WAN NIC, upstream ARP cache needs flushed (or modem rebooted if cable or DSL service).
But I still havn't been able to find anything that should relate to random reboots on x86 FreeBSD on x86 compatible hardware and x86 compatible hypervisor.
The only circumstance where I'm aware of that happening is where the OS in the VM is 32 bit, but the VM is set to 64 bit at the hypervisor level.
Regardless, you're best off with 64 bit. Guessing you just need to make sure to either keep the WAN MAC the same, or do whatever you need to do for your type of Internet service to switch the MAC.
-
Yes, new VM ofc. I talked to my ISP before i tried to change last time about the ARP Cache and they told me "You can just change firewall, nothing needs to be done from our side".
This VM is ofc set to x86 on hypervisor, and i hate spoofing L2 adresses - wich also - regarding to ISP shouldn't matter.
-
who said anything about spoofing mac - if you change the mac of the device connected to the modem. You quite often have to power cycle the modem to clear its old cache and work with the new mac. Or you can do what I do and use the same mac on your different copies of your pfsense vm (never on at the same time) but this allows to keep the same public IP. This allows me to test with different versions, etc. Even if playing with different distro I set the mac the same on the wan interface so I keep the public IP.
