[winswitch] Update for Xpra running Wireshark in Docker container

Florian Feldhaus florian.feldhaus at gmail.com
Thu Oct 17 15:17:18 BST 2019


Am 16.10.2019 | KW 42 um 19:06 schrieb Antoine Martin <antoine at nagafix.co.uk>:
> 
> (snip)
>> 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?
> That's odd, a default SSL configuration does not require any client
> certificates.
> Most browsers will just reject self-signed server certificates, though
> some will allow them when connection to "localhost“.

If I use a certificate from a trusted CA, I do not get the SSL errors from XPRA, but with the default certificate created during installation, I do see the error SSLV3_ALERT_CERTIFICATE_UNKNOWN. Is it worth creating a ticket for that?

In Chrome I’m getting asked for a client certificate, in Firefox I don’t get asked. After adding ssl-client-verify-mode=none to xpra.conf I don’t get asked for a client certificate in any browser.

>>>> 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?
> Please submit the change so that other xpra users can benefit.
> 
> This applies to all the applications I do not have time to test.
> We should be able to grow those hint files though crowdsourcing.

Can you help me get started? I checked out the code via svn but I’m not allowed to commit with my username ffeldhaus to trunk. I admit, I’ve not used SVN in a decade and may have done something wrong. This is what I tried:
Florians-MBP-3:content-type florianfeldhaus$ svn commit -m "Mapped Wireshark to text in 50_class.conf for better display quality"
Authentication realm: <https://xpra.org:443> Xpra SVN Repository
Username: ffeldhaus
Password for 'ffeldhaus': ****************

svn: E175013: Commit failed (details follow):
svn: E175013: Access to '/svn/Xpra/!svn/me' forbidden

>> 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)
> There were no patched dummy driver "xserver-xorg-video-dummy" packages
> for Debian "bullseye" yet.
> I have just pushed some DEBs to the stable repository. Try updating your
> system and it should install over the default one. (untested)
> This should solve your DPI problems.
> Alternatively, you could switch to Xvfb.
> 
> Bear in mind that development distributions like Debian Testing often
> have ABI breakage before their release. So this build may break at some
> point in the future. If it does, let me know and I'll push another rebuild.
> 
>> 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?
> If you followed the installation instructions, you should have all the
> default packages installed already.

This is indeed fixed now with the availability of xserver-xorg-video-dummy. Thanks a lot! I need to use bullseye as Buster does not contain Wireshark 3.X and I didn’t want to build Wireshark manually.

Cheers
Florian




More information about the shifter-users mailing list