Reported on the mailing list: UDP connection issues.
Original ticket: #639, see also #1669.
Bisecting:
So the bug comes from the switch to python3.
First, debugging the 3.0 branch with python2 (different regression..):
r24977 is reverted in 24991.
Now, for the python3 bug.
Lots of network debug improvements:
XPRA_LOG_PACKET_TYPE=1
start-new-commands
And UDP improvements:
With a python3 server and packet logging:
process_udp_data: packet sequence 0 : 25159 bytes added to read queue (got final chunk 45, synchronous=True)
and switch to async mode:
accept() enabling asynchronous packet reception
hello
, setting-change
, new-window
, startup-complete
, server-event
clipboard-enable-selections
, set-clipboard-enabled
, clipboard-enable-selections
(?), set_deflate
ping
and we send ping_echo
server-settings
(twice?), set-keyboard-sync-enabled
, udp-control
, configure-window
cursor
, set_deflate
info-request
, configure-window
, map-window
, focus
window-icon
, window-metadata
, info-response
, draw
, ping
, udp-control
On the client side it sometimes failed to receive anything at all, but if it does get something, it always fails when trying to parse the udp-control
packet, with an error like this one:
Error: received uninterpretable nonsense: invalid packet header byte 801000001919913911710011245991111101161141111080672727102192: '3830313030303030' read buffer='801000001919913911710011245991111101161141111080672727102192' (60 bytes) packet no 69 data: '801000001919913911710011245991111101161141111080672727102192'
(not sending the udp-control
packet "fixes" things)
this "fixes" things but is not correct
Fixed in r25007: the code that forces the synchronous
flag to False
for udp-control
packets was duplicating the logic slightly wrong.
Backport to v3.0.x in r25008.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2554