[libvirt] [PATCH] docs: added compiling page and significantly expanded windows page

[Matthias Bolte]

2010/11/17 Daniel P. Berrange <berrange at redhat.com>:
> On Wed, Nov 17, 2010 at 03:42:18PM +0100, Matthias Bolte wrote:
>> 2010/11/17 Daniel P. Berrange <berrange at redhat.com>:
>> > On Wed, Nov 17, 2010 at 02:53:15PM +0100, Matthias Bolte wrote:
>> >> 2010/11/17 Justin Clift <jclift at 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/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