Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UDP broke #2554

Closed
totaam opened this issue Jan 17, 2020 · 4 comments
Closed

UDP broke #2554

totaam opened this issue Jan 17, 2020 · 4 comments
Labels

Comments

@totaam
Copy link
Collaborator

totaam commented Jan 17, 2020

Reported on the mailing list: UDP connection issues.

Original ticket: #639, see also #1669.

Bisecting:

  • 3.0.6 bad
  • r24990 bad, python3
  • r18000 OK, python2
  • r21000 OK, python2
  • 23000 OK, python2
  • r23820 (3.0.0) OK, python2 - bad with python3

So the bug comes from the switch to python3.

@totaam
Copy link
Collaborator Author

totaam commented Jan 19, 2020

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

24977 is reverted in 24991.


Now, for the python3 bug.

@totaam
Copy link
Collaborator Author

totaam commented Jan 19, 2020

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)

@totaam
Copy link
Collaborator Author

totaam commented Jan 19, 2020

2020-01-19 13:33:11: antoine uploaded file udp-badfix.patch (1.9 KiB)

this "fixes" things but is not correct

@totaam
Copy link
Collaborator Author

totaam commented Jan 19, 2020

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 25008.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant