kernel qat fatal error & kernel qat device reset wq
-
Ok, well it's clearly attaching correctly.
I don't think rolling back to 23.05 would make any difference here. It would be more useful to try upgrading to 23.09-Beta.
Did the tunnel bandwidth actually increase after you installed the card? Does it actually seem to be working despite the unexpected error processes?
Are there errors shown in the system logs?
I don't think that bug applies to this specifically. It's a more general report for QAT in 23.09. Even so it still works as expected for OpenVPN in DCO mode.
Steve
-
Ok, I won’t roll back. I may try the beta later tonight.
The bandwidth increase alot. Before I was only getting around 3-400Mbps on an average speedtest and now i am getting a consistent 850-900 both ways. That is maxing my connection.
There is nothing in the System logs of note and I am also not using OpenVPN in DCO mode. PIA does not support DCO.
If I never saw this error, I would be none the wiser, but I did! Ahhhhh. Bloody OCD is going kill me :)
Thank you for your time on this
-
DCO mode only applies to the end where it's set. It doesn't have to be set both ends. So I would expect you could use it.
Using DCO the kernel mode crypto framework can use QAT directly giving a significant increase in performance. I actually surprised you're seeing that sort of boost without DCO to be honest.
Switching to DCO uses QAT completely differently. It may eliminate those error processes.
Steve
-
Ok,
Quick question... Does QAT work in user space. Yes or No? and then elaborate if possible
Skimming the below thread I am unclear. Still reading.
https://forum.netgate.com/topic/183123/23-09d-is-qat-broken/60?_=1697919695106In my current setup I have my tunnels setup with gateways for firewall routing purposes. Using DCO loses this ability I believe??? I may be wrong?
I am a notice so please be kind
-
As far as I'm aware QAT is not used in user space because there is no longer a dev crypto engine that OpenSSL can use to access it. It's possible OpenSSL can use it directly though I'm not aware of that. I know it can use AES-NI directly but that is an instruction set not actually a hardware device.
Using DCO does not prevent you assigning an interface and getting a gateway etc. I use that here on multiple tunnels.
Steve
-
@stephenw10
Strange, Everytime I enable it on my tunnels they go down and wont connect. I put that down to PIA. But as your said before it didnt matter that they dont support it. I must have something else wrong somewhere then. -
There are some things it doesn't support:
https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/dco.html#limitationsIf PIA is using a different cipher or you are connecting over TCP it will fail.
-
Nope, I am 100% using the correct settings. I have double and tripple checked that. then checked again after a coffee.
Just seens this in the log though, after enabling DCO on PIA tunnel....
Oct 24 15:38:26 openvpn 27424 OPTIONS ERROR: server pushed compression settings that are not allowed and will result in a non-working connection. See also allow-compression in the manual. Oct 24 15:38:26 openvpn 27424 Compression or compression stub framing is not allowed since data-channel offloading is enabled.Can you recommend another VPN provider I can try?
-
Oh there we go compression is not compatible with DCO. Hmm, I don't see that on our docs for some reason though. I'll try to add that.
I don't know of any off hand but I'd bet there are some because using DCO allows them to pass far more clients with whatever hardware they have. You might even ask PIA support. They might have some servers running DCO already that obviously wouldn't have compression enabled.
Steve
-
Hi Steve,
THanks for all your help on this but im giving up. Ripped the card out and sticking with previous setup. Going setup a dev box to play with as trying to do this between meetings on Teams is not easys and there.
I am going to look at going down the wireguard route instead and keep openvpn just for the dialin stuff as I need it to use radius.
