Re: [libvirt] [PATCH] docs: added compiling page and significantly expanded windows page
2010/11/17 Daniel P. Berrange <berrange(a)redhat.com>:
On Wed, Nov 17, 2010 at 02:53:15PM +0100, Matthias Bolte wrote:
> 2010/11/17 Justin Clift <jclift(a)redhat.com>:
> > Also added an additional menu placement for the windows page, in
> > order to attract further potential testers.
> > ---
>
> > + <li>
> > + The working connection types at the moment are very limited. Only
> > + <b>qemu+tcp://</b> is known to work for sure. Anything
using SSH,
> > + such as <b>qemu+ssh://</b>, definitely doesn't work.
Connecting
> > + to ESX servers doesn't yet work either, due to a bug involving
> > + GnuTLS, which should be fixed in the next release.
> > + </li>
>
> Don't blame GnuTLS here. As stated on IRC my initial assumption was
> wrong. The problem is probably not in GnuTLS, as gnutls-cli works
> fine. The problem is in the way libcurl and GnuTLS interact. Therefore
> libvirt's GnuTLS usage is not affected, only libcurl's.
>
> I know how to fix it, but I don't understand in detail yet why it works.
Are you referring to this message ?
"A TLS packet with unexpected length was received"
The place you normally see this is from 'gnutls_handshake()', and it is
an indication that the handshake has been aborted by either the client
or server. Typical problems include bad certificates, bad choice of
encryption ciphers, bad TLS protocol, etc. It is pretty hard to
debug, likely want to turn on the verbose GnuTLS debugging options
in the code, and also verify how the ESX server is configured and
all your certificates
In particular, by default GnuTLS will reject certificates issued by
openssl which default to x509 v1, and thus lack the 'Basic Constraints'
extension from x509 v3.
Daniel
Well, yes that's the problem and it is the handshake. As I can tell
from Wireshark the client sends a RST package directly after the
Client Hello. So this is not certificate related or something like
that.
This problem also occurs with
curl -kv https://www.google.com
and other HTTPS websites. This only happens when curl is compiled with
GnuTLS. curl compiled with OpenSSL or PolarSSL works just fine. Also
this only happens on Windows. I tried to find precompiled curl
binaries that use GnuTLS to check if the problem is in the way I
compile curl, but all binaries I could find use OpenSSL, even the
Fedora mingw32-curl package uses OpenSSL.
I traced the problem down to this libcurl commit
https://github.com/bagder/curl/commit/fcccf9aa0d93c666e8ae31ebdde716cddd6...
from 2006. This commit makes sure that GnuTLS calls send() with the
MSG_NOSIGNAL flag to avoid SIGPIPE. If I revert this commit curl works
just fine with GnuTLS. Also this commit as is has no use on Windows,
because there is no MSG_NOSIGNAL flag for send() on Windows. But this
commit triggers the handshake problem and I didn't understand yet why
it does so.
Matthias