On Wed, Nov 17, 2010 at 03:42:18PM +0100, Matthias Bolte wrote: > 2010/11/17 Daniel P. Berrange <berrange@xxxxxxxxxx>: > > On Wed, Nov 17, 2010 at 02:53:15PM +0100, Matthias Bolte wrote: > >> 2010/11/17 Justin Clift <jclift@xxxxxxxxxx>: > >> > 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/fcccf9aa0d93c666e8ae31ebdde716cddd6b4482 > > 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. I'm not convinced that they should be calling 'gnutls_transport_set_lowat' so try removing that. Also, I think they might have broken the errno handling. The gnutls push/pull funcs are returned to return '-1' and set 'errno' upon failure. The windows send/recvmsg functions don't set errno though, and you need to use WSAGetLastError() instead. If you don't set custom push/pull funcs GNUTLs does the WSAGetLastError() -> errno conversion itself. So their custom push/pull functions probably need to manually set 'errno' based on WSAGetLastError() values, unless some other part of the curl code already takes care of that Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list