Citrix Receiver (net/citrix_ica)

Is anyone using this without difficulty?

For me, most things become almost completely non-responsive immediately after the application starts.

Whilst the content of the Ctirix Receiver window appears to be frozen, if untouched, I can force momentary refreshes by repeatedly clicking in the blue area. Eventually the drop-down at the head of the window becomes not only clickable but usable, then I can switch to windowed mode, however:
  • more time passes before other applications become usable.
An example:

1628741158800.png
  • the Citrix Receiver icon has not yet appeared in the KDE Plasma panel to the left
  • the panel at the top, which normally hides automatically, has not hidden itself and appears to overhang the Citrix Receiver interface
– in this case, the system was generally unusable for around six minutes.

Note, this is not an issue with Plasma.

Gut feeling, given the click-to-refresh behaviour:
  • maybe an issue with NVIDIA graphics, which I'm using temporarily
– I'll review after I move my boot disk from an HP ZBook 17 G2 <https://forums.freebsd.org/threads/81493/> to an HP EliteBook 8570p with AMD graphics (Thames [Radeon HD 7550M/7570M/7650M]).

FreeBSD 14.0-CURRENT.
 
Last edited:
Also, when nvidia-modeset was in use: during the stuck period, a switch away from ttyv8 (Control-Alt-F2) then back resulted in a grey screen for the X session; no GUI (maybe just a movable pointer).

I'll review after I move my boot disk from an HP ZBook 17 G2 <https://forums.freebsd.org/threads/81493/> to an HP EliteBook 8570 with AMD graphics (Thames [Radeon HD 7550M/7570M/7650M]).

The same problems with radeonkms as with nvidia-modeset.

Maybe fewer minutes to wait for applications to respond normally but still, there's the period during which the X session feels almost completely stuck.
 
Yes, when I ran it today, it was *SLOW* as you indicated; however, I hadn't had that bad of an experience before. It was usable, but not that bad. My gripes with it were that the audio was choppy, the microphone wasn't picked up, and it was a little less responsive and used more CPU than chrome by itself.

The only thing that comes to mind is that something changed for the worse on FreeBSD 13 and citrix ica. Perhaps a tool like strace will be needed to see what is going on with the system.

But yes, I felt your pain this morning when I ran the desktop client, it was far worse than my gripes before.
 
it was *SLOW* as you indicated

For me, it's not slowness of Citrix Receiver (one thing).

It's like the entire X session becomes almost unusable – almost zero response to keyboard input (I can't use the keyboard to switch from one application to another, and so on).

In this situation, the system does respond to Control-Alt-F2 (takes me to ttyv1).
 
Yes, I tried that again, it was completely unusable. I didn't dig too much into it this am when I tried, but yes, it is completely useless now and aside from switching back to the console, the only other option that worked for me was patiently waiting to kill the command-line process via ctrl+c. When you run wfica, can you put strace (I think I might be thinking of linux, perhaps dtrace) in front of it and write the output and error to a file? That might shed some light as to what is going on.

Your above comment says FreeBSD 14, uh, I assume you mean 13, right?
 
Truly:

FreeBSD 14.0-CURRENT.

That's the context, however I'm not seeking help for this version of FreeBSD.

The opening post was to discover, before reporting a bug, whether anyone else has problem with net/citrix_ica (on any version of FreeBSD), which seems to be true – I assume that you're on 13.0-RELEASE-p3.

I'll set Firefox to not always Use Citrix Receiver then attempt a trace. If this proves difficult, I might remake the attempt in a virtual machine.

Additional observations

Sometimes (rarely), the bug does not occur, or is far less troublesome. From the moment of appearance of the application window, there's content with motion (the spinning asynchronous progress indicator, which I guess is presented by the server) – no need for me to click repeatedly to refresh the content of the window. I have not yet gained a sense of what's different before a non-troublesome start of the application.

When there is trouble, I discovered what might be an alternative method of refreshing the content:
  • without clicking, hold the pointer in an area of the screen that would normally trigger an action in Plasma.
For me, the two main areas are a relatively tall strip to the left (Show Desktop) and a relatively narrow strip at the top (the auto-hiding panel that I mentioned in the opening post). A shot of the blue top strip whilst not running Citrix Receiver:

1629179704964.png


– that's whilst pointing fractionally below the area that triggers appearance of the panel.

If I point at the absolute top of the screen during a troublesome start of Citrix Receiver: there's rapid flickering of the blue strip (overlaying the default full screen mode of the Citrix Receiver window), and it's as if for each flicker, there's a refresh of content within the window.

… patiently waiting to kill the command-line process via ctrl+c. …

Comparably: with htop in ttyv1 it seemed that processes such as firefox and wfica would not die in response to signals 15 (SIGTERM) and 9 (SIGKILL). I might ask, "For killing, is any signal more aggressive than SIGKILL?" however I suspect that in retrospect, I was simply encountering long waiting periods before successful deaths in ttyv8.

Side note

{link removed ?} – archived but not resolved. I didn't mention this earlier because I vaguely recall (from much earlier) that the appearance of this warning has no perceptible impact on usability of Citrix Receiver.
 
Last edited:
attempt a trace. If this proves difficult,

I half-expected this to happen …

With truss wfica x ⋯--.ica there came a point, after a few minutes, where things in ttyv8 were completely stuck – with the content of the application window not completely rendered, so I could not bring down the palette to switch to windowed mode. The white pointer alone was movable, and neither wfica nor truss died in response to SIGKILL signals from htop in ttyv1.

I could switch to and fro and get the movable white pointer, but I suspected that the X.Org session had become useless. Sure enough, after sleeping the computer ( acpiconf -s 3 at ttyv1) then waking and switching to ttyv8, there was this:

1629186019104.png


Ignoring the white pointer: this pattern is typical of problems involving DRM (radeonkms with this hardware), which I have not seen for a very long time.

service sddm restart succeeded, graphics returned to normal.
 
… something changed for the worse on FreeBSD 13 and …

Superior versions of DRM:
  • graphics/drm-fbsd12.0-kmod currently corresponds to Linux 4.16 DRM
  • graphics/drm-fbsd13-kmod currently corresponds to Linux 5.4.92 DRM.
tOsYZYny please, what's your graphics hardware and software?

Here, at the time of writing: AMD Thames [Radeon HD 7550M/7570M/7650M] {link removed ? link provider grahamperrin is dead} with radeonkms (Linux 5.4.92 DRM) and x11-drivers/xf86-video-ati 19.1.0_4,1.
 
Last edited:
configmgr

/usr/local/bin/wfcmgr

When you run this, are Reconnect … options greyed out?

2021-08-17 09:09 wfcmgr, full screen.png

If greyed out:
  1. quit
  2. install ftp/linux-c7-curl
  3. re-run wfcmgr
  4. prefer Windowed for desktops
  5. save and close
  6. start a desktop.
Does it start windowed? Or full screen (ignoring the apparently saved preference)?
 
Last edited:

FreeBSD bug {link removed ? link provider grahamperrin is dead}

After installing linux-c7-curl, it becomes possible to apparently save a preference for windowed desktops:

1629746890215.png

– however the one remote desktop that I use starts full screen, not windowed.

In the shot above:

Code:
% /usr/local/bin/wfcmgr
Gtk-Message: 20:26:12.295: Failed to load module "appmenu-gtk-module"
/usr/local/ICAClient//util/storebrowse: /lib/libcurl.so.4: no version information available (required by /usr/local/ICAClient//util/storebrowse)
Gtk-Message: 20:26:12.767: Failed to load module "appmenu-gtk-module"
/usr/local/ICAClient//util/storebrowse: /lib/libcurl.so.4: no version information available (required by /usr/local/ICAClient//util/storebrowse)
Gtk-Message: 20:26:13.017: Failed to load module "appmenu-gtk-module"
/usr/local/ICAClient//util/storebrowse: /lib/libcurl.so.4: no version information available (required by /usr/local/ICAClient//util/storebrowse)
Gtk-Message: 20:26:13.135: Failed to load module "appmenu-gtk-module"
/usr/local/ICAClient//util/storebrowse: /lib/libcurl.so.4: no version information available (required by /usr/local/ICAClient//util/storebrowse)
Gtk-Message: 20:26:13.245: Failed to load module "appmenu-gtk-module"

Code:
% pkg provides /lib/libcurl.so.4
Name    : linux-c7-curl-7.29.0_12
Desc    : Tool for transferring files with URL syntax (Linux CentOS 7.9.2009)
Repo    : FreeBSD
Filename: compat/linux/usr/lib/libcurl.so.4.3.0
          compat/linux/usr/lib/libcurl.so.4

Name    : curl-7.78.0
Desc    : Command line tool and library for transferring data with URLs
Repo    : FreeBSD
Filename: usr/local/lib/libcurl.so.4.7.0
          usr/local/lib/libcurl.so.4
Name    : curl-7.78.0
Desc    : Command line tool and library for transferring data with URLs
Repo    : poudriere
Filename: usr/local/lib/libcurl.so.4.7.0
          usr/local/lib/libcurl.so.4
% pkg info -x curl-7.78.0 linux-c7-curl-7.29.0_12
curl-7.78.0
linux-c7-curl-7.29.0_12
% file usr/local/lib/libcurl.so.4
usr/local/lib/libcurl.so.4: cannot open `usr/local/lib/libcurl.so.4' (No such file or directory)
% file /usr/local/lib/libcurl.so.4
/usr/local/lib/libcurl.so.4: symbolic link to libcurl.so.4.7.0
% file /compat/linux/usr/lib/libcurl.so.4
/compat/linux/usr/lib/libcurl.so.4: symbolic link to libcurl.so.4.3.0
%
 
Last edited:
Recent observations

If I touch nothing after the client starts – if, say, I go to the kitchen and make a cup of tea – then (touching the client for the first time) after around three minutes, it's as if things were paused for the duration. The asynchronous progress indicator begins rotating/spinning, as if the connection began a moment (not minutes) ago.

For me, the two main areas are a relatively tall strip to the left (Show Desktop) and a relatively narrow strip at the top (the auto-hiding panel that I mentioned in the opening post). A shot of the blue top strip whilst not running Citrix Receiver:

If I rest the pointer against one of those two (KDE Plasma) areas, to trigger the flickering, then things progress. Slowly.

Generally: no matter how fast I try to push things, I sense that it has become more difficult to force appearance of the Citrix 'palette' that's normally top centre.

… strace (I think I might be thinking of linux, perhaps dtrace) ?…

Found, whilst working on something else: {link removed ?}
 
Last edited:
I had some interest in attempting to update the port to the latest version, do you think that might help? I would just try a version bump, see if it builds and then pray it runs. There is probably more to it than that.

I'd like to run citrix workspace directly because hopefully perhaps my microphone would be picked up so I have a better user experience working remotely.

Citrix Workspace for HTML5 (light version) works great, but I think the area it lacks is the feeling of latency and devices working natively. The latency issue is apparent whenever I switch windows to something drastically different from the current screen. It seems that the native apps must be caching that information so it can more easily switch with less data needing to be sent over the wire.
 
I had some interest in attempting to update the port to the latest version, do you think that might help?

I think so. Thanks!

… HTML5 (light version) …

That's no longer an option for the service that I use.

Generally: no matter how fast I try to push things, I sense that it has become more difficult to force appearance of the Citrix 'palette' that's normally top centre.

Sometimes more difficult, sometimes not.

My most recent run was relatively easy to start, but that's probably because I have not restarted the OS for a while:

Code:
root@mowa219-gjp4-8570p-freebsd:~ # date ; uptime
Sat Oct 23 00:56:12 BST 2021
12:56AM  up 3 days,  2:21, 5 users, load averages: 0.54, 0.48, 0.63
root@mowa219-gjp4-8570p-freebsd:~ #

– and the previous run was within this period.
 
I gave it a quick try - trying to update to the latest version of Citrix Workspace.

1. I manually symlinked libsecret from /usr/local/lib to /usr/lib to make it visible to wfica
2. After attempting to launch wfica, it complains that the library is 64-bit

The original citrix appears to be the 32-bit version, I will have to modify the port to be 64 bit and see what happens. The installer wants to start a daemon and create a user for logging, that seems wasteful.

If I put this on github, would you collaborate on this to get it going? I haven't a clue what I'm doing and this isn't going to be quick or easy.

Also, I noticed that the patch files remove USB support so I have a feeling that for me, quite a bit would be involved to get either webcam or microphone support.

Would it help to ask Citrix for some assistance if we could get through to their engineering team?
 
?… If I put this on github, would you collaborate on this to get it going?

Happily.

{link removed ? link provider grahamperrin is dead}

I haven't a clue what I'm doing and this isn't going to be quick or easy. …

I'm not a developer, so I'm comparably clueless :)

If you have not already done so, install misc/freebsd-doc-en to get:
  • /usr/local/share/doc/freebsd/en/books/porters-handbook/book.pdf
  • /usr/local/share/doc/freebsd/en/books/porters-handbook/book.html
– {link removed ?} is 404; and a local installation of the single-page HTML book will load faster than {link removed ?}.

Would it help to ask Citrix for some assistance if we could get through to their engineering team?

From FreshPorts: "… Any concerns regarding this port should be directed to the FreeBSD Ports mailing list via ports@…" so maybe best to write there first.

Re: {link removed ?} I used Google to seek posts from the former maintainer, as far as I can tell there's nothing from him in recent years. {link removed ?} may be the most recent regarding Citrix.

{link removed ?} and more recent {link removed ?} … seeking Citrix finds nothing more than the three bugs that are found via the FreshPorts page.



I wondered whether Wine would be an option.

{link removed ?}
  • no Workspace
  • {link removed ?} doesn't look good.
 
Last edited:
The Citrix client is a closed-source Linux binary. Sometimes, the port worked for me, sometimes, it didn't. I got fed up and use Citrix only on my Windows VM now for quite a while ?‍♂️

BTW, I heard from colleagues that the horror with "trusted certificates" is also present when running it natively on Linux. We have a "nickname" for the whole mess at work: Shitrix.
 
How is the performance of the client through virtualbox and do your media devices work (microphone, speakers)? If so, then perhaps I'll follow suit and do that.
 
Well, I'm not using virtualbox, the windows machine is running in bhyve, hosted on my server. I never had windows "bare metal" on that machine, so can't tell for sure, but I'd assume performance is close to native. Audio works via net/freerdp, I even used MS Teams on it before this started working correctly in chromium on FreeBSD.
 
Interesting - well, for me audio is broken / staticy over Citrix Workspace for HTML5 either when using chromium or firefox. In chromium, my mic is not picked up so I cannot use teams easily, I have to use the callback function which adds another hiccup to joining calls.

I'm confused though, if you're using Citrix Workspace in Windows, why would you use freerdp (Ah, to connect to your virtual instance)? Wouldn't you be using the Citrix Workspace app to do all of that? Additionally, the mic has to be picked up by Citrix Workspace, right?
 
Ok, I guess I didn't describe my setup precisely enough ;)

I have a server. It's in my basement. It hosts quite a few jails AND bhyve VMs. One of these VMs is a Windows machine.

I also have a desktop (which is now used a lot for remote working). For quite some time, I used this citrix port on it. It never worked too well, and sometimes, it didn't work at all. That's why I now gave up and use Citrix only on Windows.

To access my Windows machine from my desktop, I use FreeRDP. Remote audio is working fine with that.

I never tried audio through citrix, but if it's working fine on Windows in general, I see no reason why it shouldn't work in my case.

edit: You could of course use bhyve to run Windows locally as well. Maybe audio would already work that way (while using VNC to display the VM's "graphical console"), I don't know. If it doesn't work, you could still use FreeRDP to access your local VM; with that, audio should work.
 
tOsYZYny sorry for the recent lack of attention here.

For me, most things become almost completely non-responsive immediately after the application starts.

Before I forget: I found comparable symptoms a few days ago whilst doing something with Wine. I can't remember what, exactly, I might have taken a screenshot …
 
Thanks for all the help - I think the bottom line is that for reasonable performance with a working audio setup, I have to run the native workspace app (Windows/Mac). I had difficulty with audio on Ubuntu and the HTML5 version really struggles to play audio (high CPU load and cracking).

My 'one' gripe with Citrix Workspace for HTML5 is that if I were to restart my remote desktop, logout, or disconnect, I would be unable to reconnect immediately or even after a reasonable time (to allow WIndows to restart). If I use a native windows box with Citrix Workspace, I get right in.

I think the Bhyve solution is the best way to go to avoid additional hardware. I will explore that route if my laptop request doesn't come through and document that here.
 
… Citrix doesn't recognize FreeBSD as an Operating System ….

1712298255655.png

meine if there's a web interface to .ica files, try setting your browser user-agent string to a single word (for the site that detects the device as unsupported):

Linux

For me, until some time ago, that sufficed.

This week I discovered that an agent override is no longer required. YMMV.
 
Back
Top