[winswitch] Random connection drops in browser client

Antoine Martin antoine at nagafix.co.uk
Wed Dec 9 05:56:36 GMT 2020


On 08/12/2020 23:24, Michael Cronenworth via shifter-users wrote:
> On 11/30/20 11:29 PM, Antoine Martin via shifter-users wrote:
>> Does this also occur if you connect a regular python client to the same
>> session?
> 
> I have not tried it yet, so I installed the 4.0.5 Windows client. After
> a few minutes the thick client also disconnects. In this instance I was
> using Firefox and randomly left and right clicking on the redhat.com web
> page and eventually it disconnected the client. The server log shows
> similar messages as the HTML5 client.
> 
>> Can you try to run your server with --debug=network and post the last
>> few messages just before the client disconnection message?
> 
> HTML 5 client (wss connection):
> With network debugging enabled I am seeing the client request a
> disconnect. Then the server times out on the reconnect and a second
> reconnect establishes.
> 
(..)
> 2020-12-08 07:37:36,007 client has requested disconnection: server
> shutdown (client connection lost)
(..)
> Python client (wss connection):
> The logs say the client requested a disconnect. The client doesn't
> auto-reconnect like the HTML5 client does so the log ends.
(..)
> 2020-12-08 08:45:21,085 client has requested disconnection: server
> shutdown (client connection lost)
I believe that the "client connection lost" messages shown here can only
come from a proxy server. Are you running via a proxy server?
And if so, have you tried without? The proxy server log may well have
the details you need (run "-d proxy" to get more verbose messages).

And perhaps your server process uses "--exit-with-client" and it then
terminates.
My guess is that something external is severing the connection (the OS
or a firewall) and then what happens in the xpra server is expected.

We have sessions running for days at a time, and those connections don't
drop.

Cheers,
Antoine

> ...
> 
>> That's quite odd. The "websocket closed" event can only come from 3
>> places:
>> * the server sending a "close" message (which would include a reason)
>> * a protocol error in the HTML5 client (also includes a message)
>> * the browser tears it down unceremoniously
>>
>> Only the last one would not include a "reason" message.
>> Applying this patch will now include more details:
>> http://xpra.org/trac/changeset/28048/xpra
>> You can either apply it by hand or use the copy found here:
>> http://xpra.org/html5/connect.html
>>
>> Other things worth trying:
>> * use a tunnel to ensure that the websocket traffic isn't modified
>> * use wireshark to inspect the last few packets before the connection
>> drops (you should be able to see which end is closing first)
>>
> 
> I have not tried this patch yet, or a packet capture, but I will if you
> think it is worth pursuing.
> 
> Thank you,
> Michael
> 
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> https://lists.devloop.org.uk/mailman/listinfo/shifter-users




More information about the shifter-users mailing list