I made some configuration changes on my hyper-v server. It's using Intel I350 NIC for WAN and LAN. I updated to the latest version of the Intel driver. I also disabled VMQ. Neither change made any difference. I'm still seeing the same error in the log and ipv6 is not working.
Uhm that's bad, i was a bit lazy with backing up the config (because pfsense is sooo stable, of course :) ) The only one i could use is from 2016 and i've changed a lot in the meantime. So my bad. I will try to be patient or use a router for the meantime.
Thanks for the reply Jim. Sounds like this is pretty far off. I guess for now I'll just make a simple script and cron entry to scrub every now and then and dump the results into syslog.
Just wanted to note I submitted a bug to request some joy on this: https://redmine.pfsense.org/issues/8492
It's been helpful to have workarounds but they range from inconsistently effective to tedious.
+100500 for this feature.
this is very and very useful feature.
because here, in russia, we suffer from our f*ucked up government… and ipsec one of the fastest solution to build bridges between countries.
and this is needed to allow our "whitelisted" traffic to stay in russia.
Known issue. Been fixed for a while. https://redmine.pfsense.org/issues/8391
Easily fixed by editing the rule and fixing the protocol, then click save, then apply.
I added a note and closed out the ticket for you.
We now require a cross-reference between Redmine issues and PRs for submissions, so we can catch things like this, but this was merged just before we started doing that.
Hello LemonParty1
It seems we are doing the same thing but for different reasons. Anyway, I see you renamed the firewall to GNS, but taking a closer look to your log file, it seems you forgot to rename one of the build.conf lines to GNS, cause it is still showing "MyFirewall" as the PIBA-NL wiki is showing.
Not sure if you already figured it out, but if you don't, try it again renaming all fields to "GNS" as you did to the other fields/lines.
I could generate a brand new ISO file with a different name. It took me a week to understand everything, but it's now much more clear to me.
I didn't try to generate a RELEASE ISO file yet, just a DEVELOPMENT. Let me know if you could finally finish your compilation.
Meybe we can exchange good information.
Regards
Fabricio.
STARTTLS works. The UI is a bit misleading, though. The "Enable SMTP over SSL/TLS" checkbox really means
If checked, use SMTP/S
If unchecked, use STARTTLS
To use office365, you'll need the following settings:
E-Mail Server: smtp.office365.com
SMTP Port of E-Mail Server: 587
(Unchecked)
From e-mail address: The email address associated with your account
Notification E-Mail address: Whereever you want the notification to go
Notification E-Mail auth username: The same email address as the From e-mail Address (your login email address)
Notification E-Mail auth password: Your account password
Notification E-Mail auth mechaniasm: LOGIN
It's important to note that the FROM address and the Auth Username must be identical. Failure to make them the same will result in an error message saying you're not permitted to send as address.
Thanks for the info, I'm glad to see a project that I supported coming of age. The team has worked very hard for years, I'm excited for what the future holds for pfsense. I for one am thankful for what information you have released and will wait patiently for more news to come.
Ideally anything dealing with FreeBSD-ports should happen on a FreeBSD system at some point (either directly or in a secondary capacity) because then you have access to tools like portlint which can check the port structure to ensure it's complete and correct before committing changes, for example it will flag problems with the formatting or content of the Makefile.
I also found myself with this problem, which I was able to fix with this fix : https://github.com/freebsd/freebsd/commit/6884a6e482ca6effa702761a1e3fa98bb6946c30#diff-49d9a861ee932d5b656eb20466f2a292
But other problems have occurred. :-[
I had not had this problem with the RC version, which it was in "FreeBSD 11.0", so I put a compilation environment under this version, and compilation to work.
I therefore conclude that the development team forgot to add a "BRANCH RELENG_2_4_0" on this repository: https://github.com/pfsense/FreeBSD-src
The "Main repository for pfSense" is also unusable because it refers to a "BRANCH" that is missing: https://github.com/pfsense/pfsense/blob/RELENG_2_4_0/tools/builder_defaults.sh#L108
Can someone tell us about this omission ?
Thank you !
As far as I'm aware, we have no intention of adding any wifi features like that. AP features belong in an AP. FreeBSD is great, but it does not lend itself well to being an AP.
Jimp is right, this type of monitoring needs a lot of manual configuration because on many systems the readings are nonsensical unless adjusted properly using information from the manufacturer. For example some of the AMD CPUs give you negative values and you're supposed to know the reference temperature used to calculate the real temperature as reference+reported. On such systems the only out of the box reliable CPU temperature is the one show in BIOS setup.
Such reporting system would work out of the box only on a small number of systems where the calibration values are known.
