Hi, On Dec/30/2019, Daniel Lenski wrote: > On Sat, Dec 28, 2019 at 1:53 PM Carles Pina i Estany <carles@xxxxxxxx> wrote: > > I'm using openconnect from Debian (Debian package version 8.02-1) > > connecting to a Cisco AnyConnect. I'm using NetworkManager but I'm happy > > to use the command line if this would help. > > > > I see that openconnect uses about 35 to 40% of CPU (measured with top) > > in my 4 cores laptop. > > 35-40% of a *single* core, I presume? What CPU? I assume it's What I see (based on 'top') is the 100% of a single core CPU. This is on a "Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz" with 'aes' in the flags. I've checked again now, the openconnect process is now usually less than 25% of my CPU usage (I understand that this is likely to be 100% on this 4-cores CPU). It stays on 24%, 23%, 25%, 25.6% occasionally The other day I did see more than 25% CPU usage for an openconnect (is it ever using more than one thread? or it was me miss-reading, top miss-reading, etc.?) of total CPU usage. > something relatively modern featuring the AES hardware acceleration > (e.g. http://wikipedia.org/wiki/Special:Search/AES-NI). You should be > able to verify the CPU features with `cat /proc/cpuinfo | grep aes`, > and `gnutls-cli --benchmark-ciphers` should show much higher > throughput for AES-based ciphers. 'aes' in the CPU flags: yes, confirmed, it's there gnutls-cli: I didn't have the Debian package gnutls-cli installed. Just done it and the output is is: Checking AEAD ciphers, payload size: 16384 AES-128-GCM 2.31 GB/sec AES-128-CCM 0.36 GB/sec CHACHA20-POLY1305 0.30 GB/sec Checking cipher-MAC combinations, payload size: 16384 SALSA20-256-SHA1 0.22 GB/sec AES-128-CBC-SHA1 0.26 GB/sec AES-128-CBC-SHA256 131.16 MB/sec Checking MAC algorithms, payload size: 16384 SHA1 0.38 GB/sec SHA256 195.19 MB/sec SHA512 0.21 GB/sec Checking ciphers, payload size: 16384 3DES-CBC 20.24 MB/sec AES-128-CBC 0.58 GB/sec SALSA20-256 0.43 GB/sec NULL 18.49 GB/sec My openconnect connection was: Established DTLS connection (using GnuTLS). Ciphersuite (DTLS0.9)-(RSA)-(AES-256-CBC)-(SHA1). I can't see any AES-256 being benchmarked there and I can't see how to tell gnutls-cli --benchmark-ciphers to test this, do you know if this is possible at all? > > The internet connection or even the upload speed to the other side is > > higher if no OpenConnect is used. > > What is the alternative to using OpenConnect which you are comparing > against? Cisco's official AnyConnect client for *Linux*? Or its client > for *Windows*? I did a few tests: a) AnyConnect client for Linux: output is a big higher (instead of 7 or 8 MB/s was more like 9 or 10 MB/s if I remember correctly. Also with one core CPU at 100%) b) Upload to the destination network (not the same host because for this I need the VPN) without any VPN it's way faster (about 25 MB/s which is more or less the connection speed of one of the sides) > > Any MTU that might help? (e.g. I see that my wlan0 has mtu 1500 and vpn0 > > is mtu 1200), or some othe rideas? > > Incorrect MTU could lead to fragmentation or packet loss which affects > VPN bandwidth or latency… but shouldn't have much of an effect on CPU > usage (OpenConnect's CPU usage should be pretty small, and doubling it > due to high fragmentation should still be small). I'm pretty sure (see some comments later in this email) that the CPU usage is the problem. I was wondering how to reduce the need of CPU to make it faster :-) > Are you experiencing packet loss with the OpenConnect connection, or > just lower-than-expected bandwidth? no packet loss > > any way to verify that DTLS is being used and parameters? (using > > Anyconnect is faster, and DTLS is used there) (it's about 20% to 40% > > faster... but sometimes it gets disconnected) > > Error: any valid prefix is expected rather than "dev". > > > > The connection works, the speed is similar. DTLS seems enabled. > > > > I'll play with some settings (e.g. disabling compression, dtls-ciphers, > > etc.). If I get anything better I'll pass it here. > > The log excerpt you sent (“Established DTLS connection (using GnuTLS). > Ciphersuite (DTLS0.9)-(RSA)-(AES-256-CBC)-(SHA1).”) shows that DTLS is > being used, with the bog-standard cipher configuration for older Cisco > servers. There's no compression option allowed by the server here; > compression would be indicated in this line if present. > `--dtls-local-port` is also not relevant here: it's unnecessary unless > you're behind some kind of router/middlebox that might limit the ports > on which you can send UDP packets. I can't think of a plausible way in > which such a middlebox would lead to high CPU usage, in any case. Thanks for all the information and specially for the dtls-local-port information - I thought that maybe it was to receive UDP packets and that a NAT on the internet router on the VPN client side would have helped (but I never tried this). Because I'm uploading lots of data and because I wanted to test this what I did is to setup a VirtualBox with a minimal system, use bridge network, connect VirtualBox using openconnect and also start uploading data using rclone. I'm monitoring the wlan0 on the host system (using qnetload, sorry for the "spam" but just in case this is useful: https://github.com/cpina/qnetload ) Using Linux+openconnect+rclone: I had upload speeds as I said of around 7 or 8 MB/s and total CPU usage around 25% (openconnect seemed to use 100% of one CPU) Using Linux+openconnect+rclone+VirtualBox (and inside openconnect+rclone): my total CPU usage is 50% and the upload speed is 15 or 17 MB/s. I "guess" that it's not a network problem, and for what I know about rclone and the object storage on the other side there are no bandwidth limits. VirtualBox was my easy way to have two opeconnect running at the same time. I thought of having two openconnect with vpn0 and vpn1 and somehow deal with routing in my host machine (I think that I could tag packets based on the application and route them differently) but I thought that for the experiment VirtualBox would be easier for me. Any ideas (e.g. how to benchmark AES-256-CBC to make sure that gnutls is able to do this) are welcome :-) Thanks very much for the answers, -- Carles Pina i Estany _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
