@johnkeates: I think you may have seen this on a tweet somewhere about vale and netmap in conjunction with the microFW for a theoretical pps improvement. once the network driver in _u_fw has netmap support, sure.

@phil.davis: The code fixups that I could see have been merged into master for 2.4. The warnings would happen if you put invalid stuff into Range "From" or "To" and press Save. e.g. put "1000" instead of "::1000". So try that on any system with the latest 2.4-DEVELOPMENT snapshot. Thanks for the info on the changes. I never made any changes to the ipv6 range values. The default values for are ::1000 and ::2000, which are what I'm using.

This time does look better :-) I've upgraded a couple of my FreeBSD boxes to 11, so far so good.

I executed the commands referenced in the other thread and it cleared the problem. It's no longer saying there is an update. I guess I'll find out next time there is a new snapshot whether the problem is actually fixed.

Good catch. I'll report that on the feedback hub, for what good that will do.

xmlrpc sync has changed in 2.4, for the moment there errors are 'by design' or change thereof.. Once https://github.com/pfsense/pfsense/pull/3141 is pulled ill try and see if i can fix some of the packages using config synchronisation..

@johnkeates: PHP module is the way to go. I had a quick browse on GitHub/pfSense but couldn't find it there, is the current module hosted elsewhere? https://github.com/pfsense/FreeBSD-ports/tree/devel/devel/php56-pfSense-module/files

Never mind.  Posted that before realizing that is an interfaces address.

Oh dear, is it only the time dimension that is the problem. I wonder if it managed to restore all 3 dimensions of space  ;)

Could i also set my needed uart hints in /boot/loader.conf.local instead of in device.hints in 2.4? hint.uart.0.disabled="1" hint.uart.1.disabled="1" analog to: " echo "hint.acpi.0.disabled="1"" >> /boot/loader.conf.local " https://doc.pfsense.org/index.php/Boot_Troubleshooting

It was a matter of how to determine which profile is used for any given inbound connection. IPsec does not have distinct "ports" for each server like OpenVPN so it has to differentiate based on the information it can see before the connection is negotiated. So the P1 would have to differ enough that it could tell the two apart. For something like IKEv2 there isn't a good way to do that. Maybe it could use identifiers, but clients are very picky about identifiers. I'm not sure a different CA/Cert is enough either.

@jimp: Was that the only change required? Nothing changed in the Pear mail library? If so that looks easy enough to include if you create a PR with it. Yup.  That's all I changed. As for submitting a PR for it. Don't know where the pfSense pear source is. Don't want the liability of this on my shoulders. 2a) Don't know enough about pear mail to know what ramification may lurk or how reliable at insuring a TLS connection may be, or the possibility of it preventing one.  etc. 2b) Like I said in previous post.  Not adequately tested.

+1 for this

I get this too.

I just installed it on windows 2012R2 hyper-v. I used default settings all the way. (The partition setting default was DOS, so I just used it. No problems at all with the installation.

to avoid adding more custom patches on ports, in this case pear-Net_IPv6 I've added our own copies of _bin2Ip and _ip2Bin. If upstream accept to make these methods public, and probably rename them, we can revert my commit and rename calls to proper function. Thanks! https://github.com/pfsense/pfsense/commit/de6457345617a6518e58f3ebafa706948534b11a