[winswitch] Update for Xpra running Wireshark in Docker container

Wed Oct 16 15:51:55 BST 2019

I was able to solve most issues now, the SSH error went away after I used a trusted certificate.

I still have issues with DPI settings (see section at the end) and would be glad to receive some hints how to make DPI work.

The offset issue is also still open and I responded in the ticket I created.

I added an Acknowledgement section to the README asking to support the Open Source projects which the Docker Image is built from:
https://github.com/ffeldhaus/docker-wireshark#acknowledgements <https://github.com/ffeldhaus/docker-wireshark#acknowledgements>

Thanks for all your help!
Florian

> Am 14.10.2019 | KW 42 um 18:00 schrieb Florian Feldhaus <florian.feldhaus at gmail.com>:
> 
> Thanks for responding to my new questions, but I had an update at the end regarding the resolution / DPI issues. Can you have a look at that?
> 
>> Am 14.10.2019 | KW 42 um 14:07 schrieb Antoine Martin <antoine at nagafix.co.uk <mailto:antoine at nagafix.co.uk>>:
>> 
>> On 14/10/2019 18:36, Florian Feldhaus wrote:
>>> Thanks a lot for your input, very helpful. I have a few follow up
>>> questions inline, but first let me ask 2 new questions:
>>> 
>>> Is there a way to donate to XPRA? I’d be glad to donate myself and refer
>>> users of my Docker container to donate to the XPRA project as it
>>> wouldn’t be possible without the great job you are doing. I couldn’t
>>> find anything on the XPRA or Winswitch sites.
>> That's good idea, I'll try to set something up after I inquire about the
>> legal constraints of it.
> 
> Let me know once you have any information on donating and I’m happy to point to it and donate myself.
> 
>>> When using the HTML5 client, I have consistently problems with multiple
>>> OS (checked Linux and Mac OS) regardless of resolution with Firefox and
>>> Chrome when maximizing Wireshark and then trying to use the scrollbar on
>>> the right side. It seems that the cursor is generally off to the left in
>>> this situation. If I make the Wireshark window a bit smaller than
>>> maximized, everything is still fine. I couldn’t find any ticket on this.
>>> Is this a known issue? Otherwise I’ll open a ticket.
>> Please do.
>> Sounds like the browser window is slightly too small.
> 
> I created ticket http://xpra.org/trac/ticket/2444 <http://xpra.org/trac/ticket/2444> for this.
> 
>>>> Am 12.10.2019 | KW 41 um 05:26 schrieb Antoine Martin via
>>>> shifter-users <shifter-users at lists.devloop.org.uk <mailto:shifter-users at lists.devloop.org.uk>
>>>> <mailto:shifter-users at lists.devloop.org.uk <mailto:shifter-users at lists.devloop.org.uk>>>:
>>>> 
>>>> On 11/10/2019 22:04, Florian Feldhaus via shifter-users wrote:
>>>>> 2019-10-11 13:54:10,301 started command 'wireshark' with pid 45
>>>>> 2019-10-11 13:54:10,303 Warning: cannot watch for application menu
>>>>> changes without pyinotify:
>>>>> 2019-10-11 13:54:10,303  No module named 'pyinotify'
>>>> Not needed unless you want the client to be able to start new commands
>>>> using a menu GUI.
>>>> Be aware than since v3, users can start new commands when connected to
>>>> the server. Use "start-new-commands=no" to disable this capability.
>>> 
>>> Is there a way to completely disable the XPRA menu in the HTML5 client?
>>> It is not needed in my case and could be confusing for users.
>>> 
>>>>> 2019-10-11 13:54:10,497 xpra is ready.
>>>>> 2019-10-11 13:54:10,499 xpra GTK3 X11 version 3.0-r24095 64-bit
>>>>> 2019-10-11 13:54:10,550 2.0GB of system memory
>>>>> 2019-10-11 13:54:11,327  uid=1000 (wireshark), gid=1000 (wireshark)
>>>>> 2019-10-11 13:54:11,328  running with pid 1 on Linux Debian testing
>>>>> bullseye
>>>>> 2019-10-11 13:54:11,330  connected to X11 display :0 with 24 bit colors
>>>>> 2019-10-11 13:54:29,256 Error: wss request failure
>>>>> 2019-10-11 13:54:29,256  for client 172.17.0.1:39794:
>>>>> 2019-10-11 13:54:29,256  request:
>>>>> 'ü1ÿD5a>Gä•®Ç(’ñÑŠ3èÀ–lÝYCEò DÔ©Ì¸ôþñÿÆŸ˜ó{}÷3Œ'o—
>>>>> Åšð"ššÀ+À/À,À0Ì©Ì¨ÀÀœ/5'
>>>>> 2019-10-11 13:54:29,256  [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3
>>>>> alert certificate unknown (_ssl.c:2508)
>>>> SSL client misconfiguration?
>>> 
>>> I followed the exact steps in
>>> https://xpra.org/trac/wiki/Encryption/SSL <https://xpra.org/trac/wiki/Encryption/SSL> and still have the issue. I
>>> have lots of these log entries, but will retry with a trusted
>>> certificate. One thing I found out is, that when I open the HTML5 client
>>> in a Browser it is asking for a client certificate. I do have client
>>> certificates installed, but don’t want to use them and click on cancel.
>>> Could it be, that client certificates are causing this error?
>>> 
>>>>> When I use this on a large display (5K), I often get very blurred
>>>>> output when a lot of Network packages are analyzed. That is probably
>>>>> expected, but the blurry images sometimes stay for several seconds
>>>>> and sometimes are not refreshed at all with a clear picture.
>>>> Some applications are known to refresh their windows regularly, even
>>>> when nothing has actually changed on screen, this causes problems with
>>>> xpra's builtin heuristics which then keep the picture quality lower
>>>> than desired to try to keep up with the updates.
>>>> Otherwise, the picture is always eventually refreshed with a lossless
>>>> one pretty quickly.
>>>> 
>>>> Also, be aware that I don't have a 5K display so this has never been
>>>> tested with windows that big - so some things may need tweaking to
>>>> improve the experience.
>>>> For a start, we there is a known issue with the html5 client on macos
>>>> hi-dpi displays:
>>>> https://xpra.org/trac/ticket/2410 <https://xpra.org/trac/ticket/2410>
>>>> 
>>>>> I tested this on a local computer with more or less unlimited
>>>>> bandwidth. I tried to modify the encoding settings via xpra.conf, but
>>>>> it seems they had no effect. I checked the information at
>>>>> https://xpra.org/trac/wiki/Encodings/Debugging
>>>>> <https://xpra.org/trac/wiki/Encodings/Debugging> but I wasn’t able to
>>>>> fix this myself. Are there any hints for high quality encoding?
>>>> The best way would be to just add a new hint so we map wireshark to a
>>>> "text" mode:
>>>> https://xpra.org/trac/browser/xpra/trunk/src/content-type
>>>> https://xpra.org/trac/browser/xpra/trunk/src/content-type/50_class.conf
>>>> 
>>>> Alternatively, you should be able to get pixel perfect screen updates
>>>> just by increasing the "min-quality" parameter.
>>> 
>>> I added a hint for Wireshark to be mapped to text mode and the quality
>>> is perfect now. Even if a lot of packages are analyzed, only approx.
>>> 500KB/s of bandwidth are used to deliver the updates to the client! Can
>>> we add Wireshark to the official 50_class.conf or should I just do it
>>> for my docker deployment?
>>> 
>>> I still get a lot of DPI errors, even when connecting with devices with
>>> lower resolutions on Linux:
>>> 2019-10-14 08:30:02,461 DPI set to 20 x 21 (wanted 96 x 96)
>>> 2019-10-14 08:30:02,463  you may experience scaling problems, such as
>>> huge or small fonts, etc
>>> 2019-10-14 08:30:02,463  to fix this issue, try the dpi switch, or use a
>>> patched Xorg dummy driver
>>> 2019-10-14 08:30:02,485 sent updated screen size to 1 client: 1664x896
>>> (max 8192x4096)
>>> 
>>> I tried to manually set dpi=96 in the xpra.conf but that didn’t seem to
>>> have an effect. I checked the information about Xdummy
>>> here https://xpra.org/trac/wiki/Xdummy <https://xpra.org/trac/wiki/Xdummy> but it seems that is already used
>>> by default. Output of "cat /usr/local/etc/xpra/conf.d/55_server_x11.conf
>>> | tail -n1“:
>>> # Selecting virtual X server:
>>> xvfb = /usr/lib/xorg/Xorg -noreset -novtswitch -nolisten tcp +extension
>>> GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile
>>> ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -configdir
>>> ${XDG_RUNTIME_DIR}/xpra/xorg.conf.d/$PID -config /etc/xpra/xorg.conf
>>> 
>>> How can I verify if all required packages are installed and how do I
>>> solve the DPI issues?
> 
> Can you have a look at the section above from my last mail?
> 
> Thanks
> Florian