Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#45858 - [networkmanager-openconnect] Handshake failures
Attached to Project:
Arch Linux
Opened by Diogo Baeder (diogobaeder) - Friday, 31 July 2015, 21:32 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 01 August 2015, 13:07 GMT
Opened by Diogo Baeder (diogobaeder) - Friday, 31 July 2015, 21:32 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 01 August 2015, 13:07 GMT
|
DetailsDescription: I'm having inconsistent failures when using networkmanager-openconnect; sometimes it's unable to complete the handshake to a server when trying to cURL with GET, and sometimes GET works but POST fails if the request body is too big. Using raw openconnect, however, as described in the wiki ( https://wiki.archlinux.org/index.php/OpenConnect#Command_Line ), works just fine for me, so it seems to be an issue specifically related to networkmanager-openconnect
Additional info: * package version(s) $ pacman -Si networkmanager-openconnect Repositório : extra Nome : networkmanager-openconnect Versão : 1.0.2-1 Descrição : NetworkManager VPN integration for openconnect Arquitetura : x86_64 URL : http://www.gnome.org/projects/NetworkManager/ Licenças : GPL Grupos : Nenhum Provê : Nenhum Depende de : networkmanager>=1.0.2 openconnect gtk3 libsecret Depend. opcionais : network-manager-applet: GNOME frontends to NetWorkmanager Conflita com : Nenhum Substitui : Nenhum Tamanho de download : 252,38 KiB Tamanho instalado : 1432,00 KiB Empacotador : Jan Alexander Steffens (heftig) <jan.steffens@gmail.com> Data da compilação : Ter 05 Mai 2015 12:48:24 BRT Validado por : Soma MD5 Soma SHA256 Assinatura * config and/or log files etc. (Not sure what configs I should put here, and not sure where the logs are at.) Steps to reproduce: $ time curl -vI -1 <redacted> * Rebuilt URL to: <redacted> * Trying <redacted>... * Connected to <redacted> (<redacted>) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * Unknown SSL protocol error in connection to <redacted>:443 * Closing connection 0 curl: (35) Unknown SSL protocol error in connection to <redacted>:443 real 3m13.994s user 0m0.017s sys 0m0.007s |
This task depends upon
Here's more information that might be useful to track down what exactly is happening that causes the problem for me. I've tested resolvconf three times:
1- Without any VPN client running;
2- With bare openconnect (using the program directly);
3- With networkmanager-openconnect (which uses openconnect under the hood) - this is the one that makes the handshake fail.
I also tried replacing the executable used by networkmanager-openconnect by my working script, but it just makes the client fail with NetworkManager, so I quit trying to use it this way.
So, here are the resolvconf results, in the order of the three scenarios above (please bear in mind that I redacted information from the company I work for):
$ resolvconf -l; resolvconf -v
# resolv.conf from NetworkManager
# Generated by NetworkManager
search spo.virtua.com.br
nameserver 201.6.2.32
nameserver 201.6.2.152
nameserver 192.168.1.1
DOMAIN=''
SEARCH='spo.virtua.com.br'
NAMESERVERS='201.6.2.32 201.6.2.152 192.168.1.1'
LOCALNAMESERVERS=''
DOMAINS='spo.virtua.com.br:201.6.2.32,201.6.2.152,192.168.1.1'
$ resolvconf -l; resolvconf -v
# resolv.conf from tun0
nameserver <company IP 1>
nameserver <company IP 2>
domain <my company VPN domain>
# resolv.conf from NetworkManager
# Generated by NetworkManager
search spo.virtua.com.br
nameserver 201.6.2.32
nameserver 201.6.2.152
nameserver 192.168.1.1
DOMAIN='<my company VPN domain>'
SEARCH='<my company VPN domain> spo.virtua.com.br'
NAMESERVERS='<company IP 1> <company IP 2> 201.6.2.32 201.6.2.152 192.168.1.1'
LOCALNAMESERVERS=''
DOMAINS='<my company VPN domain>:<company IP 1>,<company IP 2> spo.virtua.com.br:201.6.2.32,201.6.2.152,192.168.1.1'
$ resolvconf -l; resolvconf -v
# resolv.conf from NetworkManager
# Generated by NetworkManager
search <my company VPN domain> spo.virtua.com.br
nameserver <company IP 1>
nameserver <company IP 2>
nameserver 201.6.2.32
# NOTA: o resolvedor da libc não tem suporte a mais do que 3 servidores de nomes.
# Os servidores de nomes listados abaixo podem não ser reconhecidos.
nameserver 201.6.2.152
nameserver 192.168.1.1
DOMAIN=''
SEARCH='<my company VPN domain> spo.virtua.com.br'
NAMESERVERS='<company IP 1> <company IP 2> 201.6.2.32 201.6.2.152 192.168.1.1'
LOCALNAMESERVERS=''
DOMAINS='<my company VPN domain>:<company IP 1>,<company IP 2>,201.6.2.32,201.6.2.152,192.168.1.1 spo.virtua.com.br:<company IP 1>,<company IP 2>,201.6.2.32,201.6.2.152,192.168.1.1'