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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]