On 09.08.2018 06:57, David P. Discher wrote:
> I’m suspecting that IPSec in FreeBSD is not leveraging AESNI on Intel. Is
> this correct ?
IPsec uses crypto(9) framework that works by default without any
acceleration. You need to load aesni(4) kernel module to enable
acceleration. Also, you need
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228108
--- Comment #10 from Andrey V. Elsukov ---
(In reply to dpd from comment #9)
> This change breaks ICMP ECHO (pings) to the receiving end of peer to peer
> /30 of the IPsec tunnel between FreeBSD and Juniper JunOS on their SRX
> products.
09.08.2018 10:57, David P. Discher wrote:
> I’m suspecting that IPSec in FreeBSD is not leveraging AESNI on Intel. Is
> this correct ?
>
> A small system, with an Atom C2758 and AESNI can hit 940-950 Mbps on a 1g
> copper link SCPing a file with Chiper=aes256-gcm. SSH/OpenSSL automatically
I’m suspecting that IPSec in FreeBSD is not leveraging AESNI on Intel. Is this
correct ?
A small system, with an Atom C2758 and AESNI can hit 940-950 Mbps on a 1g
copper link SCPing a file with Chiper=aes256-gcm. SSH/OpenSSL automatically
uses AESNI if available. (Side Note, loading
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
Mark Linimon changed:
What|Removed |Added
Keywords||IntelNetworking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
Michael changed:
What|Removed |Added
CC||m.mu...@spam-fetish.org
--- Comment #1
Hi,
I have logged it as a bug with a possible patch:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229807
Regards
John
On 8 July 2018 at 09:46, John Hay wrote:
> Hi All,
>
> I have a small ntp server (PC Engines APU), with an ipv6 subnet on lo0
> with route6d to advertise it. A few
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229384
--- Comment #11 from Kajetan Staszkiewicz ---
The fix is mentioned in my message dated 2018-08-03 15:36:02 UTC. Please stop
fixating on the fact that I have patched kernel and start reading my messages
*thoroughly* instead.
The issue
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230465
Charles Goncalves changed:
What|Removed |Added
CC||n...@freebsd.org
--
You are
On a firewall machine I use FreeBSD 10.4-STABLE #0 r331239. I run
ipfw/natd as a security guard for my production FTP server. That works
fine for many years. But now one of my customers runs his ftp clients in
a not very stable environment, so sometimes a few packets are
lost. Thats ok and TCP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225927
--- Comment #12 from commit-h...@freebsd.org ---
A commit references this bug:
Author: ae
Date: Wed Aug 8 16:09:29 UTC 2018
New revision: 337460
URL: https://svnweb.freebsd.org/changeset/base/337460
Log:
MFC r336405:
Move invoking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209682
--- Comment #16 from commit-h...@freebsd.org ---
A commit references this bug:
Author: ae
Date: Wed Aug 8 16:09:29 UTC 2018
New revision: 337460
URL: https://svnweb.freebsd.org/changeset/base/337460
Log:
MFC r336405:
Move invoking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228802
--- Comment #25 from h...@restart.be ---
I try with 12.0-CURRENT r336112 and patch from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229644
The throughput regression is still there
--
You are receiving this mail because:
You are on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229384
--- Comment #10 from Vinícius Zavam ---
(In reply to Kajetan Staszkiewicz from comment #9)
good that you really took it personal (although that was not the intention).
the idea was/is to have the closest scenario to reproduce any panic
14 matches
Mail list logo