xpra icon
Bug tracker and wiki

Opened 5 weeks ago

Closed 4 weeks ago

Last modified 4 weeks ago

#2554 closed defect (fixed)

UDP broke

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 4.0
Component: network Version: 3.0.x
Keywords: Cc:

Description

Reported on the mailing list: UDP connection issues.

Original ticket: #639, see also #1669.

Bisecting:

So the bug comes from the switch to python3.

Attachments (1)

udp-badfix.patch (1.9 KB) - added by Antoine Martin 4 weeks ago.
this "fixes" things but is not correct

Download all attachments as: .zip

Change History (4)

comment:1 Changed 4 weeks ago by Antoine Martin

Status: newassigned

First, debugging the 3.0 branch with python2 (different regression..):

r24977 is reverted in 24991.


Now, for the python3 bug.

comment:2 Changed 4 weeks ago by Antoine Martin

Lots of network debug improvements:

  • r25001 log all packet types with XPRA_LOG_PACKET_TYPE=1
  • r25003 log both in and out
  • r24998 + r25000 make it possible to skip sending (very large) xdg menu data without disabling start-new-commands
  • r24999 use repr for ellipsized byte data

And UDP improvements:

  • r24995 + r24992: send control packets more slowly, simplify, warnings, etc
  • r25004 + r25005: better debug logging
  • r25006: better re-send request heuristics

With a python3 server and packet logging:

  • we receive the hello packet in about ~46 chunks:
    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
  • we send: hello, setting-change, new-window, startup-complete, server-event
  • we receive: clipboard-enable-selections, set-clipboard-enabled, clipboard-enable-selections (?), set_deflate
  • ping and we send ping_echo
  • we receive server-settings (twice?), set-keyboard-sync-enabled, udp-control, configure-window
  • we send cursor, set_deflate
  • we receive info-request, configure-window, map-window, focus
  • we send 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)

Changed 4 weeks ago by Antoine Martin

Attachment: udp-badfix.patch added

this "fixes" things but is not correct

comment:3 Changed 4 weeks ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

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.

Last edited 4 weeks ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.