Re: guacamole and accessibility features

[Weston Thayer]

Hi Florian,

We actually use Guacamole under the hood at Assistiv Labs, so have given
this a lot of thought. The limitations at
https://assistivlabs.com/accessibility should translate to Guacamole.

At a high level, Guacamole is very good at streaming remote audio. For
connections to Windows over RDP, it mostly works out of the box. Audio is
also supported on Linux or VNC connections (and even macOS with some
hacking), but requires some setup on the remote machine with pulseaudio
https://guacamole.apache.org/doc/gug/configuring-guacamole.html#audio-support-via-pulseaudio

The Windows Remote Audio service is automatically created when an RDP
session starts. Note that this service is disabled by default on Windows
Server, it can be enabled via PowerShell. With it disabled, starting NVDA
or JAWS will not result in any sound. I can't remember if starting Narrator
would enable it automatically, that would be nice. Another quirk — if you
happen to start NVDA before connecting via RDP (say in a startup script),
audio actually won't work when you do connect (or at least this used to be
the case) because the Remote Audio device wasn't present. You can fix this
by installing a virtual sound card or waiting until after starting an RDP
session to boot NVDA.

I don't have much experience with how a local screen reader behaves with
the Guacamole web interface unfortunately. The key thing once you enter a
session is to make sure the input sink (captures all keyboard input) has
focus. It could probably be a role=application, but I think it's either a
normal textbox or perhaps aria-hidden=true today.

Even though the approach of remote A/V streaming is prone to latency by
nature, we had found Guacamole to be quite fast, but nowhere near as fast
as a local screen reader. Best case latency might be 150-200ms between
entering a keystroke and the start of audio output in response (don't quote
me on that).

Getting a refreshable braille display working would be an interesting
challenge. I don't believe the RDP protocol has support for this kind of
device passthrough.

https://nvdaremote.com/ is a cool alternative to A/V streaming. It connects
a local and remote NVDA instance over its own network socket, just
transmitting NVDA commands and output. So it should be much, much faster
and I believe supports braille displays.

Hope that helps,

On Tue, Apr 30, 2024 at 10:51 AM David Lomas 
wrote:

> We’re using RDP with Guacamole and bi-directional sound. I don’t think the
> remote host even needs a sound card, depending on the RDP server. In MS, a
> virtual audio device called Remote Audio is created and that’s what the
> remote apps see as the default sound output. I’ve not tried it with screen
> readers, but no reason why that wouldn’t work as far as I can tell.
>
> On Tue, 30 Apr 2024 at 18:13, Florian Beijers 
> wrote:
>
>> Hi,
>>
>> I had a quick browse through the manual but wasn't able to definitively
>> get an answer to this question.
>> I am looking into the accessibility of Guacamole-hosted virtual machines.
>> These are used a lot in various IT-related training platforms (INE, THM,
>> etc.) and therefore are pretty prevalent in places where people who are
>> dependent on accessibilityfeatures might find them.
>> For some context, screen readers (and various other assistive tech) work
>> directly with the APIs of the OS that hosts them in order to work. They
>> have practically zero access to screens that bypass, or ignore, these APIs,
>> which is the case in almost all forms of RDP, VNC, or other mechanisms that
>> provide a video feed of a remote machine. THis covers Guacamole, through no
>> fault of anyone. That is just how this stuff works.
>> What I am wondering about is primarily to what degree Guacamole supports
>> audio throughput from a remote machine. Because a screen reader on the
>> local host can't read the remote host, the only recourse is to start a
>> screen reader on the remote host in order to make the remote machine
>> accessible to screen reader users, at least up to a point.
>> I have brought this up with some of the earlier-mentioned providers and
>> got some pushback, basically expressing uncertainty if Guacamole is even
>> able to reliably transfer audio from the remote host to the browser window.
>> So that is essentially my question.
>> Is this possible? And if so, are there any gotchas one should be aware
>> of? I'm aware of things like making sure the audio service is running on
>> the remote host or making sure the remote host has a soundcard configured
>> to output through, but it there something that needs to be explicitly set
>> up on the Guacamole end?
>>
>> Thanks a lot,
>> Florian
>>
>>

Re: Major bug message log in guacd 1.5.4

[Weston Thayer]

Hmm, I'd try openssl 1.0.2, but I don't see an alpine repository for it.
Not quite sure how to go about building from source. I'd already tried
downgrading FreeRDP (although there could be an interaction there).

I suppose another approach would be to start a bisect of guacd commits
between 1.5.3 and 1.5.4. Seems possible to automate...

On Thu, Jan 25, 2024 at 1:17 AM Vieri  wrote:

>  On Wednesday, January 24, 2024 at 11:38:35 PM GMT+1, Nick Couchman <
> vn...@apache.org> wrote:
>
> > CentOS 7
> > freerdp-libs 2.1.1-5.el7_9
> > openssl-devel 1.0.2k-26.el7_9
>
>
> I'm using:
> openssl 1.1.1l
> freerdp 2.4.1
>
> In my case, guacd 1.5.3 works flawlessly whereas 1.5.4 fails.
>
> -
> To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> For additional commands, e-mail: user-h...@guacamole.apache.org
>
>

Re: Major bug message log in guacd 1.5.4

[Weston Thayer]

I am repro'ing with the Docker image (slightly customized, otherwise I
would've shared repro steps, working on that), so that helps.

I did some research. alpine:3.17.6 through alpine:3.18.5 appear to all have
the same version of openssl1.1-compat-dev
<https://github.com/apache/guacamole-server/blob/a575af63ef5b4c8b1804999f211ebeb270992b5a/Dockerfile#L45>
(1.1.1u-r1). I'm checking with `apk add --no-cache --simulate
openssl1.1-compat-dev`, let me know if that's not to be trusted for some
reason. No surprise that it repros when the image is built with something
older, like alpine:3.18.2.

Nick, even though you can't reproduce it, could you share your openssl
version?

On Wed, Jan 24, 2024 at 11:00 AM Barnhart, Steven 
wrote:

> Would be worth using the docker versions and seeing if is present in them
> as that is then easy to point to dependencies not being updated.
>
> –Steve
> ------
> *From:* Weston Thayer 
> *Sent:* Wednesday, January 24, 2024 1:58:14 PM
> *To:* user@guacamole.apache.org 
> *Subject:* Re: Major bug message log in guacd 1.5.4
>
> Running with Nick's theory that it could be something to do with OpenSSL,
> could folks who have reproduced it by upgrading ONLY guacd from 1. 5. 3 to
> 1. 5. 4 share their OpenSSL versions? Since I can easily reproduce this, I
> can employ some
> Running with Nick's theory that it could be something to do with OpenSSL,
> could folks who have reproduced it by upgrading ONLY guacd from 1.5.3 to
> 1.5.4 share their OpenSSL versions? Since I can easily reproduce this, I
> can employ some trial & error testing to try and identify the key variable.
>
> On Wed, Jan 24, 2024 at 9:15 AM Vieri  wrote:
>
>
>
> On Wednesday, January 24, 2024 at 04:01:52 PM GMT+1, Nick Couchman <
> vn...@apache.org> wrote:
>
> > When I say "underlying system" - I mean that I'm not running Docker
> containers, I'm installing natively on CentOS7,
> > and when I upgraded from 1.5.3 to 1.5.4, I did not update any of the
> other dependencies (FreeRDP, SSH, kernel, openSSL, etc.).
> > This indicates that the issue isn't guacd itself, but some issue between
> guacd + FreeRDP and possibly some
> > underlying library (OpenSSL) that is causing the leakage.
>
> Same here.
> I am NOT using docker containers.
> As I said, absolutely nothing has changed except for guacd 1.5.4 -> 1.5.3.
> No other dependency has been updated or changed. OpenSSL is exactly the
> same. All other libs are exactly the same. FreeRDP is left untouched.
>
> So it could be what you mentioned earlier: guacd 1.5.4 might be using
> something in FreeRDP that 1.5.3 wasn't.
> Assuming it's FreeRDP that's leaking.
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> For additional commands, e-mail: user-h...@guacamole.apache.org
>
>

Re: Major bug message log in guacd 1.5.4

[Weston Thayer]

Running with Nick's theory that it could be something to do with OpenSSL,
could folks who have reproduced it by upgrading ONLY guacd from 1.5.3 to
1.5.4 share their OpenSSL versions? Since I can easily reproduce this, I
can employ some trial & error testing to try and identify the key variable.

On Wed, Jan 24, 2024 at 9:15 AM Vieri  wrote:

>
>
> On Wednesday, January 24, 2024 at 04:01:52 PM GMT+1, Nick Couchman <
> vn...@apache.org> wrote:
>
> > When I say "underlying system" - I mean that I'm not running Docker
> containers, I'm installing natively on CentOS7,
> > and when I upgraded from 1.5.3 to 1.5.4, I did not update any of the
> other dependencies (FreeRDP, SSH, kernel, openSSL, etc.).
> > This indicates that the issue isn't guacd itself, but some issue between
> guacd + FreeRDP and possibly some
> > underlying library (OpenSSL) that is causing the leakage.
>
> Same here.
> I am NOT using docker containers.
> As I said, absolutely nothing has changed except for guacd 1.5.4 -> 1.5.3.
> No other dependency has been updated or changed. OpenSSL is exactly the
> same. All other libs are exactly the same. FreeRDP is left untouched.
>
> So it could be what you mentioned earlier: guacd 1.5.4 might be using
> something in FreeRDP that 1.5.3 wasn't.
> Assuming it's FreeRDP that's leaking.
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> For additional commands, e-mail: user-h...@guacamole.apache.org
>
>

Re: Re: Major bug message log in guacd 1.5.4

[Weston Thayer]

 No such process
2024-01-12 11:24:34 guacd[1]: DEBUG:All child processes for connection
"$003920a5-932f-44c4-8279-8c37378990ab" have been terminated.

Is there another dependency that's worth testing an image built to match
your version?

On Fri, Jan 12, 2024 at 12:10 AM michael böhm  wrote:

> Hello,
>
> I can confirm Weston's observations. I could reproduce it by connecting 59
> times to to an RDP desktop with SSH enabled. On the 60th attempt it did not
> work anymore (I might have got the count wrong by 1, so it could have very
> well also been after the 58th attempt).
>
> On the failing attempts there is the following in docker host's dmesg:
>
> [Fri Jan 12 08:54:09 2024] guacd[2454882]: segfault at 8 ip
> 7fe9c9b5a7a2 sp 7fe9c6c4b0b8 error 4 in
> ld-musl-x86_64.so.1[7fe9c9b18000+4c000]
> [Fri Jan 12 08:54:09 2024] Code: e8 ef 16 00 00 31 c0 5a c3 31 c0 c3 b8 16
> 00 00 00 c3 b9 0a 00 00 00 31 c0 48 89 fa f3 ab 48 85 f6 74 04 8b 06 89 02
> 31 c0 c3 <8b> 07 83 e0 0f 74 07 31 f6 e9 15 00 00 00 ba 10 00 00 00 f0 0f b1
> [Fri Jan 12 08:54:40 2024] guacd[2455844]: segfault at 8 ip
> 7fe9c9b5a7a2 sp 7fe9c6c4b0b8 error 4 in
> ld-musl-x86_64.so.1[7fe9c9b18000+4c000]
> [Fri Jan 12 08:54:40 2024] Code: e8 ef 16 00 00 31 c0 5a c3 31 c0 c3 b8 16
> 00 00 00 c3 b9 0a 00 00 00 31 c0 48 89 fa f3 ab 48 85 f6 74 04 8b 06 89 02
> 31 c0 c3 <8b> 07 83 e0 0f 74 07 31 f6 e9 15 00 00 00 ba 10 00 00 00 f0 0f b1
> [Fri Jan 12 08:55:10 2024] guacd[2456174]: segfault at 8 ip
> 7fe9c9b5a7a2 sp 7fe9c6c620b8 error 4 in
> ld-musl-x86_64.so.1[7fe9c9b18000+4c000]
> [Fri Jan 12 08:55:10 2024] Code: e8 ef 16 00 00 31 c0 5a c3 31 c0 c3 b8 16
> 00 00 00 c3 b9 0a 00 00 00 31 c0 48 89 fa f3 ab 48 85 f6 74 04 8b 06 89 02
> 31 c0 c3 <8b> 07 83 e0 0f 74 07 31 f6 e9 15 00 00 00 ba 10 00 00 00 f0 0f b1
> [Fri Jan 12 08:55:40 2024] guacd[2456750]: segfault at 8 ip
> 7fe9c9b5a7a2 sp 7fe9c6c620b8 error 4 in
> ld-musl-x86_64.so.1[7fe9c9b18000+4c000]
> [Fri Jan 12 08:55:40 2024] Code: e8 ef 16 00 00 31 c0 5a c3 31 c0 c3 b8 16
> 00 00 00 c3 b9 0a 00 00 00 31 c0 48 89 fa f3 ab 48 85 f6 74 04 8b 06 89 02
> 31 c0 c3 <8b> 07 83 e0 0f 74 07 31 f6 e9 15 00 00 00 ba 10 00 00 00 f0 0f b1
> [Fri Jan 12 08:56:42 2024] guacd[2457875]: segfault at 8 ip
> 7fe9c9b5a7a2 sp 7fe9c6c620b8 error 4 in
> ld-musl-x86_64.so.1[7fe9c9b18000+4c000]
> [Fri Jan 12 08:56:42 2024] Code: e8 ef 16 00 00 31 c0 5a c3 31 c0 c3 b8 16
> 00 00 00 c3 b9 0a 00 00 00 31 c0 48 89 fa f3 ab 48 85 f6 74 04 8b 06 89 02
> 31 c0 c3 <8b> 07 83 e0 0f 74 07 31 f6 e9 15 00 00 00 ba 10 00 00 00 f0 0f b1
> [Fri Jan 12 08:58:39 2024] guacd[2460389]: segfault at 8 ip
> 7fe9c9b5a7a2 sp 7fe9c6c620b8 error 4 in
> ld-musl-x86_64.so.1[7fe9c9b18000+4c000]
> [Fri Jan 12 08:58:39 2024] Code: e8 ef 16 00 00 31 c0 5a c3 31 c0 c3 b8 16
> 00 00 00 c3 b9 0a 00 00 00 31 c0 48 89 fa f3 ab 48 85 f6 74 04 8b 06 89 02
> 31 c0 c3 <8b> 07 83 e0 0f 74 07 31 f6 e9 15 00 00 00 ba 10 00 00 00 f0 0f b
>
> guacd's docker logs on a failing connection:
>
> guacd[1]: INFO:Creating new client for protocol "rdp"
> guacd[1]: INFO:Connection ID is "$d39d01e0-5101-4d79-bd8d-a8620c389efa"
> guacd[1800]: WARNING:FreeRDP initialization may fail: Writability of
> the current user's home directory ("/home/guacd") could not be determined:
> Read-only file system
> guacd[1800]: INFO:    No security mode specified. Defaulting to security
> mode negotiation with server.
> guacd[1800]: INFO:Resize method: display-update
> guacd[1800]: INFO:No clipboard line-ending normalization specified.
> Defaulting to preserving the format of all line endings.
> guacd[1800]: INFO:User "@ad5b9532-c914-4fc0-be0f-3e7a247157c7" joined
> connection "$d39d01e0-5101-4d79-bd8d-a8620c389efa" (1 users now present)
> guacd[1800]: ERROR:SSH handshake failed.
> guacd[1]: INFO:Connection "$d39d01e0-5101-4d79-bd8d-a8620c389efa"
> removed.
>
> More info on my environment in my thread in this mailing list on Tuesday,
> January 9, 2024 8:03:04 PM GMT+1.
>
> I added a nightly "docker restart guacd" cronjob to the host as a quick
> workaround.
>
> Best wishes
>
> Michael
> *Gesendet:* Freitag, 12. Januar 2024 um 02:42 Uhr
> *Von:* "Nick Couchman" 
> *An:* user@guacamole.apache.org
> *Betreff:* Re: Major bug message log in guacd 1.5.4
> On Thu, Jan 11, 2024 at 5:42 PM Weston Thayer 
> wrote:
>
>> Overall. Our test is just 1 user re-connecting to the same VM over RDP
>> over and over.
>>
>
> Thanks for clarifying. FWIW, I'm running Guacamole 1.5.4 (native
> build/install), on CentOS 7 (FreeRDP 2.2.0), and I've gone way past the
> 58th successive connection without hitting this issue.
>
> -Nick
>
>>
>>
>> - To
> unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional
> commands, e-mail: user-h...@guacamole.apache.org

Re: Major bug message log in guacd 1.5.4

[Weston Thayer]

Overall. Our test is just 1 user re-connecting to the same VM over RDP over
and over.

On Thu, Jan 11, 2024 at 2:36 PM Nick Couchman  wrote:

> On Thu, Jan 11, 2024 at 5:13 PM Weston Thayer 
> wrote:
>
>> We can reliability reproduce it with the Docker image at
>> https://github.com/apache/guacamole-server/commit/94a755c90a7511969884774dbca2ef2ab5958ba6
>> on the 58th connection in the guacd container's lifetime. A bit annoying to
>> reproduce manually, but you could write a little test script.
>>
>>
> The 58th concurrent connection, or the 58th overall connection?
>
> -Nick
>

Re: Major bug message log in guacd 1.5.4

[Weston Thayer]

We can reliability reproduce it with the Docker image at
https://github.com/apache/guacamole-server/commit/94a755c90a7511969884774dbca2ef2ab5958ba6
on the 58th connection in the guacd container's lifetime. A bit annoying to
reproduce manually, but you could write a little test script.

On Thu, Jan 11, 2024 at 2:08 PM Mauricio Silveira
 wrote:

> Anyone out there Rebuilt the docker image using FreeRDP 2.10.0 and is
> able to state it is stable now?
>
> When using official docker image, the error started 5-7 days after
> container restart ( restarting guacamole-server container fixes the
> issue immediately ).
>
> I've rebuild guacamole-server docker image with FreeRDP 2.10.0 and got
> it running on January 9th.
>
> If you don´t see a reply to this thread from me in the next 10 days,
> this means it worked. ( or I might reply stating it is fixed )
>
>
>
> On 1/2/24 15:31, Michael Jumper wrote:
> > While the issue may correlate with the release of 1.5.4, keep in mind
> > that the log message in question is coming from FreeRDP regarding
> > memory that FreeRDP itself manages, and it is reporting what FreeRDP
> > identifies as a possible bug *in itself*. See:
> >
> > https://lists.apache.org/thread/9xws51d32h6mqz35d9odh2kwnl04g8p9
> >
> > If you suspect this is not the case, then you would need to eliminate
> > FreeRDP as a possible cause by rebuilding the 1.5.4 guacd image
> > against the same version of FreeRDP used by 1.5.3 (using the
> > "WITH_FREERDP" build arg). The version of FreeRDP available at the
> > time 1.5.3 was released was "2.10.0".
> >
> > Pointing to the 1.5.3 image does not just roll back to a previous
> > version of Guacamole; it rolls back to the previous version of
> > *everything available at the time*, including FreeRDP.
> >
> > - Mike
> >
> > On 1/2/24 06:28, Anders Fogh Eriksen wrote:
> >> We just tried rolling back to 1.5.3 and that fixes our issue.
> >>
> >> It seems like 1.5.4 contains a lot of changes related to memory
> >> management:
> >> https://github.com/apache/guacamole-server/compare/1.5.3...1.5.4#
> >> 
> >>
> >> On 2024/01/02 13:46:06 Vieri wrote:
> >>  >
> >>  > From the OP it seems that guacamole 1.5.3 did not have this issue,
> >> but it is yet to be confirmed.
> >>  >
> >>  >
> >>  >
> >>  > -
> >>  > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> >>  > For additional commands, e-mail: user-h...@guacamole.apache.org
> >>  >
> >>  >
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> > For additional commands, e-mail: user-h...@guacamole.apache.org
> >
>
> -
> To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> For additional commands, e-mail: user-h...@guacamole.apache.org
>
>