Date: Sat, 8 Jul 2023 09:49:47 +0200 From: FreeBSD User <freebsd@walstatt-de.de> To: Pierre Pronchery <pierre@freebsdfoundation.org> Cc: freebsd-virtualization@freebsd.org, freebsd-current@freebsd.org Subject: Re: CURRENT: bhyve: xfreerdp doesn't support OpenSSL 3 yet. Alternatives? Message-ID: <20230708095014.1ede5bcd@thor.intern.walstatt.dynvpn.de> In-Reply-To: <105d4fa7-8472-6316-fc15-7ba8dd987974@freebsdfoundation.org> References: <20230629163533.4d430fed@thor.intern.walstatt.dynvpn.de> <ded9c3b0-0a26-24aa-131f-d06632a9922f@madpilot.net> <20230629183519.7eff8540@thor.intern.walstatt.dynvpn.de> <be6cc036-958a-4940-88eb-8907fb33ae29@Spark> <105d4fa7-8472-6316-fc15-7ba8dd987974@freebsdfoundation.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Fri, 30 Jun 2023 16:45:52 +0200 Pierre Pronchery <pierre@freebsdfoundation.org> schrieb: My apology for the delay. Shortly after the post here and several patches the problem vanished into t= hin air - alos by using tigervnc as the client and not, as proposed on the FreeBSD Wiki page,= xfreerdp. Thank you very much for helping! Regards oh > Hi everyone, >=20 > I believe I understand where the issue loading OpenSSL's > legacy provider comes from (for MD4 support) and I am currently working=20 > on a fix here: > https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0-providers >=20 > Basically the OpenSSL provider module for legacy algorithms is not built= =20 > correctly, since the switch to OpenSSL 3.0.9 in base. The same goes with= =20 > the FIPS module, where finding an elegant solution is more difficult=20 > than for the legacy one, but I'm getting there. >=20 > Anyway, I will keep updating this branch until it's ready for a pull-up=20 > request, very likely with force-pushes in order to polish the commits=20 > before submission. >=20 > Let me know how it goes! >=20 > Cheers, > -- Pierre >=20 > On 6/29/23 23:56, Dustin Marquess wrote: > > On Jun 29, 2023 at 11:36=E2=80=AFAM -0500, FreeBSD User=20 > > <freebsd@walstatt-de.de>, wrote: > >=20 > > Am Thu, 29 Jun 2023 16:41:51 +0200 > > Guido Falsi <mad@madpilot.net> schrieb: > >=20 > > On 29/06/23 16:35, FreeBSD User wrote: > >=20 > > Hello, > >=20 > > running a recent CURRENT, 14.0-CURRENT #10 > > main-n263871-fd774e065c5d: Thu Jun 29 05:26:55 > > CEST 2023 amd64, xfreerdp (net/freerdp) doesn't working > > anymore on Windows 10 guest in > > bhyve. It seems OpenSSL 3 is the culprit (see the error > > message from xfreerdp below). I > > opened already a PR (see: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272281)= . In a > > very quick response I was informed that recent FreeRDP > > doesn't support OpenSSL 3 yes > > (https://github.com/FreeRDP/FreeRDP/pull/8920). > >=20 > > Checking for HowTo's setting up bhyve guests, I dodn't > > realise any setting for > > alternatives to RDP. As I do not fully understand how bhyve > > passes through its guest's > > framebuffer device/ or native GUI, I'm a bit helpless in > > searching for another solution to > > contact the Windows10 guest from the X11 desktop of the hos= ts. > >=20 > > Trying remmina turns out to be a fail, because in our > > installation libsoup2 and libsoup3 > > are installed both and remmina complains about having both > > symbols, also I realised > > remmina seems to utilize net/freerdb as the RDP backend. > >=20 > > Since I have no clue how to install "blindly" a VNCserver > > within the Windows10 guest, I > > presume VNC is not an option in any way. > >=20 > > Is there any way to access the bhyve guest's native > > graphical interface? As in the PR shown > > above already documented (setup taken from the FreeBSD > > Wiki/bhyve), a framebuffer is > > already configured. > >=20 > > It would be nice if someone could give a hint. > >=20 > >=20 > > I had the same issue, with Windows 10 pro hosts, but the fault = is in > > windows, which, by default, tries to negotiate an ancient > > protocol (NTLM > > using RC4 if I understand correctly). > >=20 > > With modern windows RDP servers there are better protocols > > available, > > you can get them in remmina by forcing "TLS protocolo security" > > in the > > advanced tab, security protocol negotiation (second row). > >=20 > > Doing this (after some experimentation with various options) > > solved the > > issue for me. > >=20 > >=20 > > Thank you very much for the quick response. > >=20 > > net/remmina is not an option on most of my workstations, since some > > required ports install > > libsoup3, and remmina complains about having found libsoup2 symbols > > as well as libsoup3 > > symbols when starting up - and quits. > >=20 > > Since remmina utilises net/freerdp, I was wondering if I could > > enforce TLS security by any > > kind of a switch, and trying the following > >=20 > > xfreerdp /v:192.168.0.128:5900 /u:ohartmann /sec:tls > >=20 > > resulting in > >=20 > > [...] > > [17:58:18:972] [1702:bb812700] [WARN][com.winpr.utils.ssl] - OpenSSL > > LEGACY provider failed to > > load, no md4 support available! > > [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] - > > BIO_read returned an > > error: error:12800067:DSO support routines::could not load the > > shared library > > [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] - > > BIO_read returned an > > error: error:12800067:DSO support routines::could not load the > > shared library > > [17:58:18:973] [1702:bb812700] [ERROR][com.freerdp.core.transport] - > > BIO_read returned an > > error: error:07880025:common libcrypto routines::reason(524325) > > [17:58:18:973] > > [1702:bb812700] [ERROR][com.freerdp.core] - > > transport_read_layer:freerdp_set_last_error_ex > > ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D] > > [17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core.transport] - > > BIO_read returned a > > system error 35: Resource temporarily unavailable > > [17:58:18:981] [1702:bb812700] [ERROR][com.freerdp.core] - > > transport_read_layer:freerdp_set_last_error_ex > > ERRCONNECT_CONNECT_TRANSPORT_FAILED > > [0x0002000D] [17:58:18:981] [1702:bb812700] > > [ERROR][com.freerdp.core] - freerdp_post_connect > > failed > >=20 > >=20 > > My setup is > >=20 > > bhyve -c 4 -m 4G -w -H \ > > -s 0,hostbridge \ > > -s 3,ahci-hd,/pool/home/ohartmann/bhyve/win10/disk_win10.img \ > > -s 5,virtio-net,tap0 \ > > -s 29,fbuf,tcp=3D0.0.0.0:5900,w=3D1920,h=3D1200,vga=3Dio \ > > -s 30,xhci,tablet \ > > -s 31,lpc \ > > -l com1,stdio \ > > -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ > > win10 > >=20 > > and this is a working image setup a couple of weeks ago when VBox > > has been defective on > > CURRENT - should say: it worked once. > >=20 > > I can not interpret the error above. > >=20 > > bhyve is novel to me and I have to admit that I make some capital > > mistakes here - but can't > > find satisfying doucumentation ... > >=20 > > Kind reagrds, > >=20 > > Oliver > >=20 > >=20 > > RDP would be on the guest's IP using port 3389.=C2=A0=C2=A0Port 5900 on= the host's=20 > > IP is bhyve's VNC port, which speaks VNC, not RDP. > >=20 > > If you want to use VNC, try TigerVNC. > >=20 > > -Dustin =20 >=20 --=20 O. Hartmann
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230708095014.1ede5bcd>