Hi folks!
I prepared this thread as a community contributed gathering place for anyone out there who is running Opnsense on any of the PCEngines APU2/3/4 boards. Since Opnsense 20.7 is a big jump from the old FreeBSD/HardenedBSD 11.x to the new FreeBSD/HardenesBSD 12.1, I expect many compatibility, driver, and performance issues. So I definitely resist upgrading. I let others share their experience first :)
- what Coreboot BIOS you are currently using? Did Core Performance Boot (CPB), the Watchdog, PCIE energy saving, AMDTEMP CPU temperature sensor driver, APULED driver, CPU sysctls gone after Coreboot upgrade, and other recent features broke anything in your firewall?
- are you planning to compare the speed benchmark before 20.7 upgrade and after 20.7 upgrade? E.g. WAN throughput, VPN throughput, OpenSSL -EVP (AES-NI) speed test etc.
- Any igb NIC driver issues observed? Manual sysctl / tuned config file entries?
- ECC functions properly with the new 12.1 BSD? How can you prove it really works?
- does the new 12.1 BSD firmware boot-time microcode update works now properly? How can you prove?
- dmidecode output under 12.1 BSD versus dmidecode under 11.x BSD shows correct ACPI entries, RAM ECC-capable flag(s), RAM module speed vs bus speed reporting discrepancy, etc?
- the infamous terrible PPPoE performance has any improvement, or still limited to 200-400 Mbit max on a 1Gbit fibre WAN + NAT + pf?
And any other issues that are not obvious catch, if you dont have a proper testing checklist after every upgrade performed ("it works for me fine after the update" is a clear sign of no checklist used).
In short, i am on 20.7 with my apu4, it works (migrated - not a fresh install)
Ruggerio
Yep, same for me, also migrated (no checklists, no tests, sorry it just works). I am seeing slightly lower load average, much higher memory usage. Coreboot is v4.12.0.3.
apu2d4 here, full install on ssd.
I needed to disable circular logs in order to make firewall live logs work properly.
Other than that it works great for me so far.
My bios is v4.12.0.2. I have disabled the watchdog because when enabled (60s), it would reboot right away. Maybe 60s is not enough?
My (pppoe) internet is just 50mbit so I dont have any performance issues.
Edit: I did a clean install using the importer. Previous version was 20.1
Seccessfuly migration of an apu4c4 with instlled coreboot v4.12.0.3 from OPNsense 20.1.9_1 without any problem.
Before i upgrade the second one in the cluster, i will observe the upgraded one for 24-48h. After it is working during this time properly i will upgrade the second one also to OPNsense 20.7.
Successful upgraded: apu1
Coreboot: v4.9.0.3
This old lady works like a charm.
apu.2c4 successful fresh install OPNsense-20.7-OpenSSL-serial-amd64 on msata 128 go
don't work with sd card anymore
coreboot build 20203007 ( v4.12.0.3 )
Hello,
Upgrade of an apu4c4 from OPNsense 20.1.9 to OPNsense 20.7 then from coreboot v4.12.0.2 to coreboot v4.12.0.3 without any problem.
Regards,
Hi, I suffer this error codes, when I Install 20.7 on a APU2C4 machine:
2020-08-04T18:13:01 kernel: mmc0: Card at relative address 22964 failed to select
2020-08-04T18:13:01 kernel: mmc0: Card at relative address 22964 failed to select
2020-08-04T18:13:01 kernel: mmc0: CMD7 failed, RESULT: 1@Darkopnsense wrote that it does not work with a SD card anymore but with Msata, did you suffer the same problem?
There is only a SD card slot offered in my Varia router but I found some Sata Slots, i guess, inside it, which are empty. But I do not know how to install the OS with Msata this way... kind of clueless at the moment. Any ideas how to fix it?
Quote from: dju on August 05, 2020, 12:36:02 AM
apu.2c4 successful fresh install OPNsense-20.7-OpenSSL-serial-amd64 on msata 128 go
don't work with sd card anymore
coreboot build 20203007 ( v4.12.0.3 )
Hello @hirschferkel,
In my experience your Msata disk is defective.
I have already had the case.
Either you change the disk, or you do a new installation by reformatting (pending the death of your disk)
Regards,
I use a SD card and I installed a fresh 20.1 nano image on the card and it runs perfect again.
Problems will only appear, when I try to install 20.7 on that same SD card. So I did not have any experience with Msata, as I do not have any idea how to install OPNsense with Msata?...
best
Quote from: Darkopnsense on August 05, 2020, 10:05:33 AM
Hello @hirschferkel,
In my experience your Msata disk is defective.
I have already had the case.
Either you change the disk, or you do a new installation by reformatting (pending the death of your disk)
Regards,
Hello,
OPNsense installation on an mSATA:
Create a USB key with the OPNsense image.
APU off
Insert the usb key with OPNsense on the APU
Connect an APU serial cable from the apu to your pc
Start PUTTY
Power up your APU
Follow the instructions in PUTTY
Regards,
apu2 So far it runs without problems,
(https://i.postimg.cc/2LDw46nQ/11.png) (https://postimg.cc/2LDw46nQ)
(https://i.postimg.cc/Yvszd81q/38.png) (https://postimg.cc/Yvszd81q)
Regards 8)
I have 2 APU2C4 running here, both on coreboot v4.0.30. No issues so far
I've observed a lesser WAN speed on my APU2:
https://forum.opnsense.org/index.php?topic=9264.msg83684#msg83684
Quote from: 4r7ur on August 05, 2020, 05:52:10 PM
I have 2 APU2C4 running here, both on coreboot v4.0.30. No issues so far
You are running
1) legacy 4.0.x BIOS versus the mainline 4.10+ BIOS, and
2) you are behind the latest (4.0.32 is the latest, contains watchdog and PCIE addressing issues)
Sorry to hijack this thread, but what does the watchdog feature actually do?
Actually all problems with
https://forum.opnsense.org/index.php?topic=7645.msg34941#msg34941
kernel ath0: stuck beacon; resetting (bmiss count 4)
Are gone, now. So it was actually a software problem of OPNsense.
https://forum.opnsense.org/index.php?topic=13792.msg64395#msg64395
Aug 26 00:33:29 kernel: pflog0: promiscuous mode enabled
Aug 26 00:33:29 kernel: pflog0: promiscuous mode disabled
Aug 26 00:32:32 kernel: pflog0: promiscuous mode enabled
These problems are history, too... without changing anything in settings.
Updated today to 20.7.2
Sofar it seems I hit the syslog-ng defect, its unable to start, triggering manually results in service coredump. Hence no logs are available under System \ Logging :(
Would be worthy to mentio in the release notes before people push the update button carelessly.
Sure, syslog-ng dlsym() crash was fixed. If you see another one just put in a qualified report and we shall solve it. That said, we expect you ran the workarounds other people shared already?
Judging from your other activity you have a lot of problems with OPNsense in general?
Cheers,
Franco
Quote from: franco on September 06, 2020, 03:03:30 PM
Sure, syslog-ng dlsym() crash was fixed. If you see another one just put in a qualified report and we shall solve it. That said, we expect you ran the workarounds other people shared already?
Judging from your other activity you have a lot of problems with OPNsense in general?
Cheers,
Franco
I was upgrading from 20.1.9 to 20.7.2, and saw the release notes said something about a resolved syslog-ng crash that I wasnt aware . As I did not look for it specifically: if that was fixed among otber fixed things, I did not check each of them whether any of them may still be unfixed. The release notes doesnt have known issues section, so I dont know what to expect. So if you say there is something wrong with syslong-ng on 20.7, then it seems I need to investigate. Adding a "known issues" section to release announcements could improve the experience for upgrades. You can call it "afterupdate-things-to-be-aware" if you dont like to call problematic things as "Known issues". But something should be there to make people aware, that not everything is perfectly working
On twitter I saw explicitly mentioning @opnsense that there are no major upgrade issues with 20.7. Having syslog-ng break just after upgrade is still suspicious for me. At least now I know I have to look after this. Maybe I have some new syslogng problem, maybe its the same as others had.
I agree with Ricardo.
There should be a "known issues" section with update infos.
I also ran into the syslog-ng issue, just to find out it was known, but nobody actually cared to tell others, that this happening.
How about a dynamic update info when pressing the update button, that contains that "known issue" section?
Knowingly letting people run into an issue that's known and hoping for them to find a solution on the forums seems to be quite a poor solution...
Cheers
Juri
Yes, poor, average, convenient, appropriate, cost effective, free, limited liability, limited warranty. It is all the same.
Since you two agree now you only have to agree which one of you curates that list. ;)
In general there is a bug tracker that tracks open bugs: https://github.com/opnsense/core/issues?q=is%3Aopen+is%3Aissue+milestone%3A21.1+label%3Abug
We fixed 2 syslog-ng issues, if you see a third I'm still happily awaiting your detailed report.
Cheers,
Franco
@Franco
That was no offence, just a feedback :)
I am quite new to OPNsense and would be willing to assist in curating that info, but am not sure if I'm ready for it, since I'm an OPNsense user only since a few weeks.
But back to the point: I think it would be already of great help, if near the top of the update notice, a sticky note says: IMPORTANT: Please consult open bugs list, prior to updating.
There should be a link to github bug tracker.
That what probably already suffice, what do you think?
I'm not sure. We can't really tell people what to do and what not to do. Some complain about having to do (so many) updates, but the truth is they just can avoid pressing the update button. ;)
And as for reading what we write specifically... let's say it can be difficult for any number of reasons: time, language, context, larger version jumps, plugin use and other local complications.
We try to pack all release-relevant information into the releases notes and that includes current issues that a lot of people are struggling with, see the netmap information in 20.7.2 for example.
Syslog-ng had issues for sure, but so much that it kept crashing people's deployments completely so we have to weigh importance and for this reason syslog-ng did not meet the bar for inclusion.
A number of workarounds existed prior to 20.7.2 and if you need personal assistance there is also commercial things to be considered.
All of this is no substitute to test locally and roll back if you really need to. Snapshots and backups are great.
I know that people see their issues first and would like to not deal with them and ask us to be super up front and direct for every small issue, but this is neither done intentionally nor do we not work on fixes in the background in the scope of what impact is relevant for whom.
To circle back, a known issues section is more for something permanent that is unlikely to change for a longer period, not as transient bug. First releases of a major version are always a little noisy and if persistent issues emerge we shall document and report on them properly. So far we seem to be on a good standing for syslog-ng on 20.7.2.
Cheers,
Franco
Quote from: franco on September 07, 2020, 09:54:54 AM
I'm not sure. We can't really tell people what to do and what not to do. Some complain about having to do (so many) updates, but the truth is they just can avoid pressing the update button. ;)
And as for reading what we write specifically... let's say it can be difficult for any number of reasons: time, language, context, larger version jumps, plugin use and other local complications.
We try to pack all release-relevant information into the releases notes and that includes current issues that a lot of people are struggling with, see the netmap information in 20.7.2 for example.
Syslog-ng had issues for sure, but so much that it kept crashing people's deployments completely so we have to weigh importance and for this reason syslog-ng did not meet the bar for inclusion.
A number of workarounds existed prior to 20.7.2 and if you need personal assistance there is also commercial things to be considered.
All of this is no substitute to test locally and roll back if you really need to. Snapshots and backups are great.
I know that people see their issues first and would like to not deal with them and ask us to be super up front and direct for every small issue, but this is neither done intentionally nor do we not work on fixes in the background in the scope of what impact is relevant for whom.
To circle back, a known issues section is more for something permanent that is unlikely to change for a longer period, not as transient bug. First releases of a major version are always a little noisy and if persistent issues emerge we shall document and report on them properly. So far we seem to be on a good standing for syslog-ng on 20.7.2.
Cheers,
Franco
@jassonmc: Welcome to the opensense community :D
Quote from: Ricardo on September 08, 2020, 11:46:29 AM
Quote from: franco on September 07, 2020, 09:54:54 AM
I'm not sure. We can't really tell people what to do and what not to do. Some complain about having to do (so many) updates, but the truth is they just can avoid pressing the update button. ;)
And as for reading what we write specifically... let's say it can be difficult for any number of reasons: time, language, context, larger version jumps, plugin use and other local complications.
We try to pack all release-relevant information into the releases notes and that includes current issues that a lot of people are struggling with, see the netmap information in 20.7.2 for example.
Syslog-ng had issues for sure, but so much that it kept crashing people's deployments completely so we have to weigh importance and for this reason syslog-ng did not meet the bar for inclusion.
A number of workarounds existed prior to 20.7.2 and if you need personal assistance there is also commercial things to be considered.
All of this is no substitute to test locally and roll back if you really need to. Snapshots and backups are great.
I know that people see their issues first and would like to not deal with them and ask us to be super up front and direct for every small issue, but this is neither done intentionally nor do we not work on fixes in the background in the scope of what impact is relevant for whom.
To circle back, a known issues section is more for something permanent that is unlikely to change for a longer period, not as transient bug. First releases of a major version are always a little noisy and if persistent issues emerge we shall document and report on them properly. So far we seem to be on a good standing for syslog-ng on 20.7.2.
Cheers,
Franco
@jassonmc: Welcome to the opensense community :D
Very in-depth, thoughtful and helpful comeback. ¯\_(ツ)_/¯
I have an old APU1 up and running. Had some incident during the upgrade (it only upgraded base/kernel and not the rest), but with some help in another topic here (Thanks, Franco), that could be easily fixed.
Regards,
Ralph
Quote from: franco on September 08, 2020, 09:27:25 PM
Quote from: Ricardo on September 08, 2020, 11:46:29 AM
Quote from: franco on September 07, 2020, 09:54:54 AM
I'm not sure. We can't really tell people what to do and what not to do. Some complain about having to do (so many) updates, but the truth is they just can avoid pressing the update button. ;)
And as for reading what we write specifically... let's say it can be difficult for any number of reasons: time, language, context, larger version jumps, plugin use and other local complications.
We try to pack all release-relevant information into the releases notes and that includes current issues that a lot of people are struggling with, see the netmap information in 20.7.2 for example.
Syslog-ng had issues for sure, but so much that it kept crashing people's deployments completely so we have to weigh importance and for this reason syslog-ng did not meet the bar for inclusion.
A number of workarounds existed prior to 20.7.2 and if you need personal assistance there is also commercial things to be considered.
All of this is no substitute to test locally and roll back if you really need to. Snapshots and backups are great.
I know that people see their issues first and would like to not deal with them and ask us to be super up front and direct for every small issue, but this is neither done intentionally nor do we not work on fixes in the background in the scope of what impact is relevant for whom.
To circle back, a known issues section is more for something permanent that is unlikely to change for a longer period, not as transient bug. First releases of a major version are always a little noisy and if persistent issues emerge we shall document and report on them properly. So far we seem to be on a good standing for syslog-ng on 20.7.2.
Cheers,
Franco
@jassonmc: Welcome to the opensense community :D
Very in-depth, thoughtful and helpful comeback. ¯\_(ツ)_/¯
I have to admit, that one wasnt my most helpful and constructive post. But sometimes it gets effective, though..
Anyway, to be ontopic:
would be really useful, if there was a page, dedicated to main releases e.g. one for 20.7, a separate one for 21.1, another one for 21.7 and so on, that tracks the most serious / showstopper upgrade-related bugs in that release branch. A simple table, nothing fancy. That describes what is the issue (e.g. Syslog-ng fails after upgrade to 20.7.0), when inside that release branch it was introduced (e.g upgrade from 20.1.x to 20.7.0), how to workaround (e.g. run from CLI: kill syslog-ng), when it was fixed (e.g. upgrade to 20.7.1). And you put a link to the release notes, that says: for any late-breaking upgrade info, check this known issues.
Just to chime in here, I'm running 20.7.4 (just updated to it last night) on an APU2 and it's working ok. In in the USA and have Charter/Spectrum for my WAN and it keeps dropping randomly at times. I usually have to go into the web GUI and renew the GW lease. I haven't been able to figure out what's going on here.
I've got the 4gb RAM APU2 with three GigE ports, no Wifi at all, it's just a router and that's it. I'm using a 64Gb mSATA SSD as my boot device, but I've only got 32gb partitioned and even less in use. I figure that's a great way to keep up longevity as the wear leveling should keep things going nicely.
I syslog to my main home machine, and I still don't see messages in the logs when the gateway goes down.
Any suggestions on how to debug this better? Can I reset the WAN DHCP from the console so I can watch for errors? It's driving me nuts since a reboot tends to fix up the problem right away.
This system has been ugpraded from older releases, so maybe I really need to do a fresh 20.7.4 install on a wiped system. Should I try to save off the config and restore it? Or should I just re-enter all my local firewall rules (just a couple for NAT'ing some devices on the inside) and local DNS entries? It would be nice if there was a way to export/import a list of entries all at once.
John
Hi,
just an idea here:
Quote from: l8gravely on November 16, 2020, 05:43:57 PM
Any suggestions on how to debug this better? Can I reset the WAN DHCP from the console so I can watch for errors? It's driving me nuts since a reboot tends to fix up the problem right away.
Why don't you use monit to check for the connection?
You could for example create a connection test to any IP available from the firewall and in case it is not reachable you could initiate a reload afer let's say 5 missed attemts and initiate a reboot afer 15 attempts.
Thats the way I monitor my internet connection.
amichelf
I have an APU2 4 GB. I always update to latest mainline BIOS and latest Opnsense, at most with one week delay. I have Ziggo 500 down 40 up. The APU2 is in the DMZ of my modem/router.
I have installed Sensei. No big problems that I could report.
I just recently upgraded my old APU1 running 20.7.<recent> to an APU4d4 because I keep getting drops of my WAN connection, it's like the DCHP times out and the router can't renew it properly. I'm working along and suddenly things freeze and I can't work, or my kids come yelling that the Wifi is down. Heh.
So I goto Interfaces -> Overview -> igb3 and hit the 'renew' button. Which usually works, but not always. I might have to hit it multiple times.
I log via syslog to my main home system which is on 24x7, so can anyone give good suggestions for what to look for in the logs to help diagnose this problem? It's really frustrating when the kids are in school, or us parent's are on conference calls.
Here's a snippet from my log:
opnsense[32236]: /usr/local/etc/rc.configure_interface: The command '/sbin/dhclient -c '/var/etc/dhclient_wan.conf' -p '/var/run/dhclient.igb3.pid' 'igb3'' returned exit code '15', the output was 'dhclient 41052 - - Starting delete_old_states() dhclient 44642 - - Comparing IPs: Old: 66.189.75.104 New: dhclient 47831 - - Removing states from old IP '66.189.75.104' (new IP '') 0 states cleared killed 0 src nodes from 1 sources and 0 destinations DHCPREQUEST on igb3 to 255.255.255.255 port 67 DHCPREQUEST on igb3 to 255.255.255.255 port 67 DHCPREQUEST on igb3 to 255.255.255.255 port 67 DHCPDISCOVER on igb3 to 255.255.255.255 port 67 interval 2 DHCPDISCOVER on igb3 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on igb3 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on igb3 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on igb3 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on igb3 to 255.255.255.255 port 67 interval 19'
Dec 1 11:50:30 gw dhclient[3571]: Starting delete_old_states()
It looks like it's a failure to properly renew the WAN DHCP client IP address for some reason. Has anyone else seen this issue? Any suggestions on what I can do to make it work better?
Yup, give it a static lease. That means no bridge mode for your modem, use DMZ.
Has anyone experienced lower than expected AES / VPN troughput recently?
I did a measurement on my APU2, and it performs significantly worse, than 2 years earlier:
openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 11056362 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 5231233 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 1850707 aes-128-cbc's in 3.05s
Doing aes-128-cbc for 3s on 1024 size blocks: 505589 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 64769 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 32500 aes-128-cbc's in 3.01s
OpenSSL 1.1.1d-freebsd 10 Sep 2019
built on: reproducible build, date unspecified
options:bn(64,64) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 58967.26k 111599.64k 155497.35k 172574.38k 176862.55k 177032.31k
--> approx. 172Mbit/sec traffic using 1024bytes blocks (measurement repeated multiple times, router is lightly loaded, 80+% idle)
Earlier (Opnsense 18.x, OpenSSL 1.0.2k-freebsd 26 Jan 2017): it was higher:
openssl speed -elapsed -evp aes-128-cbc
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 109850.66k 157501.93k 194130.64k 205928.11k 210187.46k
--> around 205-210 Mbit/sec
Thats quite a big steady 20% degradation.
The correct binary to check is (and always was) /usr/local/bin/openssl
Cheers,
Franco
Quote from: franco on December 03, 2020, 07:56:48 PM
The correct binary to check is (and always was) /usr/local/bin/openssl
Cheers,
Franco
Did you spot any mistake?
This is what I get with my apu2e4:
root@hush:~ # openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 15080231 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 7226969 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 2525328 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 570466 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 73644 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 36643 aes-128-cbc's in 3.00s
OpenSSL 1.1.1d-freebsd 10 Sep 2019
built on: reproducible build, date unspecified
options:bn(64,64) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 80427.90k 154175.34k 215494.66k 194719.06k 201097.22k 200119.64k
Guys, for the love of the Gods please use /usr/local/bin/openssl ;)
# which openssl
/usr/bin/openssl
Cheers,
Franco
Slightly better:
root@hush:~ # /usr/local/bin/openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 11289033 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 5595084 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 256 size blocks: 2235362 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 690092 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 89374 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 44699 aes-128-cbc's in 3.00s
OpenSSL 1.1.1h 22 Sep 2020
built on: Tue Oct 20 22:46:58 2020 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) blowfish(ptr)
compiler: cc -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -O2 -pipe -DHARDENEDBSD -fPIE -fPIC -fstack-protector-all -fno-strict-aliasing -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_THREAD_SAFE -D_REENTRANT -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 60208.18k 119051.76k 190750.89k 235551.40k 244050.60k 244116.14k
Quote from: franco on December 04, 2020, 08:31:25 AM
Guys, for the love of the Gods please use /usr/local/bin/openssl ;)
# which openssl
/usr/bin/openssl
Cheers,
Franco
1) For the love of god, why do you guys deploy 2 different openssl versions on the same opnsense without describing this trapmine?
2) In my case, it didnt give better results:
~ # /usr/local/bin/openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 10431991 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 5030317 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 1792666 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 505478 aes-128-cbc's in 3.02s
Doing aes-128-cbc for 3s on 8192 size blocks: 64928 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 32502 aes-128-cbc's in 3.00s
OpenSSL 1.1.1h 22 Sep 2020
built on: Tue Oct 20 22:46:58 2020 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) blowfish(ptr)
compiler: cc -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -O2 -pipe -DHARDENEDBSD -fPIE -fPIC -fstack-protector-all -fno-strict-aliasing -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_THREAD_SAFE -D_REENTRANT -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 55637.29k 107313.43k 152974.17k 171642.52k 177296.73k 177504.26k
Well, you should know that APUs are now considered low-end hardware. So be content with that it offers. For the home user (hobbyist) it is a perfect box. But it is not suitable for very demanding tasks.
FWIW, I ran the same command on my APU2D4
~ # /usr/local/bin/openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 16220482 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 64 size blocks: 7941393 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 2918949 aes-128-cbc's in 3.02s
Doing aes-128-cbc for 3s on 1024 size blocks: 816008 aes-128-cbc's in 3.02s
Doing aes-128-cbc for 3s on 8192 size blocks: 105686 aes-128-cbc's in 3.02s
Doing aes-128-cbc for 3s on 16384 size blocks: 52871 aes-128-cbc's in 3.02s
OpenSSL 1.1.1h 22 Sep 2020
built on: Tue Oct 20 22:46:58 2020 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) blowfish(ptr)
compiler: cc -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -O2 -pipe -DHARDENEDBSD -fPIE -fPIC -fstack-protector-all -fno-strict-aliasing -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_THREAD_SAFE -D_REENTRANT -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 86284.54k 169416.38k 247793.06k 277087.57k 286356.08k 286507.81k
Coreboot: v4.13.0.1
Core Performance Boost - Currently Enabled
I'm the only one on the system so I set:
vm.pmap.pti = 0
hw.ibrs_disable = 0
among some other optimization settings
I don't remember when Meltdown mitigation and Spectre V2 mitigation was introduced.
We know that mitigating these issues in the O/S causes a performance "hit". I just don't know how much.
My APU2D4 is for my home network and all inbound traffic is disabled. So, disabling the mitigation was an acceptable risk for me in order to get best performance.
According to AMD, their CPUs are not vulnerable to the Meltdown vulnerability. So, it should be safe to disable Meltdown mitigation, vm.pmap.pti = 0
Yup, on my APU2C4:
/usr/local/bin/openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 13947948 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 7114424 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 2589608 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 733300 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 93373 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 45467 aes-128-cbc's in 3.00s
OpenSSL 1.1.1h 22 Sep 2020
built on: Tue Oct 20 22:46:58 2020 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) blowfish(ptr)
compiler: cc -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -O2 -pipe -DHARDENEDBSD -fPIE -fPIC -fstack-protector-all -fno-strict-aliasing -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_THREAD_SAFE -D_REENTRANT -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 74389.06k 151774.38k 220979.88k 250299.73k 254970.54k 248310.44k
Another round:
/usr/local/bin/openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 15874993 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 7012502 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 2832566 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 772744 aes-128-cbc's in 3.01s
Doing aes-128-cbc for 3s on 8192 size blocks: 103137 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 52408 aes-128-cbc's in 3.00s
OpenSSL 1.1.1h 22 Sep 2020
built on: Tue Oct 20 22:46:58 2020 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) blowfish(ptr)
compiler: cc -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -O2 -pipe -DHARDENEDBSD -fPIE -fPIC -fstack-protector-all -fno-strict-aliasing -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_THREAD_SAFE -D_REENTRANT -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 84666.63k 149600.04k 241712.30k 263078.19k 281632.77k 286217.56k
Quote from: Ricardo on December 04, 2020, 09:30:12 PM
1) For the love of god, why do you guys deploy 2 different openssl versions on the same opnsense without describing this trapmine?
I'm not sure if you are intentionally hard to work with or that it is just what it is.
FreeBSD requires an embedded base system OpenSSL library for bootstrap reasons, but this version cannot be changed on the fly without reinstalling the whole base system. That's why we use a package on top to allow quick updates and also the possibility to use LibreSSL.
This information isn't new and certainly not rocket science. Failure to learn from past threads which have plenty of information on the subject is on the individual user.
Cheers,
Franco
Quote from: franco on December 06, 2020, 09:30:59 AM
Quote from: Ricardo on December 04, 2020, 09:30:12 PM
1) For the love of god, why do you guys deploy 2 different openssl versions on the same opnsense without describing this trapmine?
I'm not sure if you are intentionally hard to work with or that it is just what it is.
FreeBSD requires an embedded base system OpenSSL library for bootstrap reasons, but this version cannot be changed on the fly without reinstalling the whole base system. That's why we use a package on top to allow quick updates and also the possibility to use LibreSSL.
This information isn't new and certainly not rocket science. Failure to learn from past threads which have plenty of information on the subject is on the individual user.
Cheers,
Franco
All I can do, if I am in doubt of something, first I use the docs search function:
https://docs.opnsense.org/search.html?q=openssl&check_keywords=yes&area=default
It didnt help me to find your quoted sentence, which you suggest should be general public knowledge:
"FreeBSD requires an embedded base system OpenSSL library for bootstrap reasons, but this version cannot be changed on the fly without reinstalling the whole base system. That's why we use a package on top to allow quick updates and also the possibility to use LibreSSL."
Othwerwise you may add forum sticky permalinks into the docs articles, where it is written once already. Searching for "openssl" string under forum returns too many results, not rational to find that 1 statement.
"Failure to learn from past threads which have plenty of information on the subject is on the individual user."
No comment on this, we dont understand or willing to accept the others point of view.
This is not a OPNsense related thing.
The location of custom software outside of base system comes from the way FreeBSD works using ports.
Further information on this topic:
https://www.freebsd.org/doc/handbook/dirstructure.html
https://www.freebsd.org/doc/handbook/ports.html#ports-synopsis