You didn't find anything because there's nothing to find. We've always supported upgrading from an older release to a newer release and this time is no different. The only exception to that rule was transitioning from the old embedded to NanoBSD style embedded, but since you couldn't do an in-place upgrade on the old style embedded that was a bit of a moot point.

Well, it does the same thing under VirtualBox. I used 512MBs of RAM, 8GBs disk and two vtnet NICs. This has to be some sort of data loss problem that somehow isn't reproducable on your VM. I wouldn't be using Parallels otherwise but it's so far the only one that offers proper Direct3D 9/10 graphics under Windows guest.

It might be the same root cause as this known issue: https://redmine.pfsense.org/issues/3649

The upgrade.log looks like it is only written to during the first install.  Does anyone know if there are any logs stored during an upgrade?  I don't see any in /var/log or /root or /tmp.  Unless there is some kind of logging I don't know that doing a full restore will really help troubleshoot the issue.

The one that will come out ater today.

#if (__FreeBSD_version > 500000) 299         if (port_access_handle 300             || (port_access_handle = fopen("/dev/io", "rw")) != NULL) { 301                 return i386_set_ioperm(port, 1, 1); 302         } 303         else { 304                 return (-1);    /* Failure */ 305         }; 306 #else 307         return i386_set_ioperm(port, 1, 1); 308 #endif from the link you attached seems what i suggested is about right, use /dev/io

It works for me using an ID, though I use "User FQDN" as the type. My "mobile" config is the same as what we have documented on the doc wiki for mobile IPsec on 2.x, since we are trying to ensure a smooth transition using the same settings as before. The reauth bit looks like the client didn't do what it should. I'm not sure what the server can do there to help, if anything.

Can you show me your config?

Ok. Thanks. Seems like I have to update the trusty old Intel D2500CC then. Currently it manages about 80 Mbit/s throughput on one core.

The challenge, should you wish to accept it, should be very like what was done to make bandwidthd work - https://github.com/pfsense/pfsense-packages/commit/dc690b55fe7b55b767af8461c4735ea4a3a60c3b Define some constants for the various directory paths, set them differently depending on the pfSense version, use them to specify the needed paths in the code.

I confirm that this solved also for me. When I push the new rules from master to slave is working now without problems. I just found only the little problem with the Virtual ip CARP description. When I create Virtual ip is ok, then when i try to modify the description I receved this message " The following input errors were detected: This IP address is being used by another interface or VIP." The only solution thant I found is delete and recreate the Virtual Ip CARP. thank you

@cmb: Steve knows what he's doing See you say that but I'm not sure, based on this thread at least.  ::) Anyway that's much easier and works much better. Takes a long time to update the package list initially though. Thanks. Steve

Firewall Logs on x64 seem to be fixed at least as of May 17 build (without raw log enabled)! [image: Pnmq0Fe.png] Yay! Regards, Sean

Speaking of Mac address, is normal my wan/pppoe have this mac in Status: Interfaces:M 00:00:00:00:00:00? spoof it but same. Ifconfig show em0 with the right mac. @salida thanks for sharing that solution for your situation.

To configure my modem (ppp) i don't use the PPPs advanced settings. For any reason each time o go to interfaces_ppps_edit.php my pen is restarted, i see that in console, and was identified with another port, instead of cuaU0.x changed to cuaU1.x like you are re-plug the pen. I ended using the config in Interface name "interfaces.php?if=opt1" only. This is on the initial 2.2 snaps now i don't know i have to test it.

The squid-dev maintainers probably need to bump that to a newer base version of squid, or make sure it's pointing to the right version file. We won't usually update such things automatically unless the maintainer indicates it's safe, as syntax changes from version to version might lead to breakage.

Try on a current snapshot. I committed a workaround yesterday.