2010/11/17 Daniel P. Berrange <berrange@xxxxxxxxxx>: > 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 > Ah, the missing errno handling is the problem. When I use the same WSAGetLastError() to errno translation as GnuTLS in libcurl's custom send/recv functions then it works. Removing the call to gnutls_transport_set_lowat makes no difference. Thank you for this hint :) Matthias -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list