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

Xpra Proxy no longer working with 0.14.2 #658

Closed
totaam opened this issue Aug 22, 2014 · 8 comments
Closed

Xpra Proxy no longer working with 0.14.2 #658

totaam opened this issue Aug 22, 2014 · 8 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Aug 22, 2014

Issue migrated from trac ticket # 658

component: server | priority: critical | resolution: fixed

2014-08-22 21:37:46: sschnitzer created the issue


Hello,

running "xpra proxy", "xpra start" (both CentOS 7), and "xpra attach" (on Win7), I was able to connect using version 0.13.8.
However, using the same setup with 0.14.2, the server gives me the following error:

2014-08-22 22:20:00,850 invalid_header(Protocol(SocketConnection(('127.0.0.1', 31001) - ('127.0.0.1', 59099))), "hello: {'named_cursors': 1, 'pango.version': '1.29.4', 'xkbmap_layout': 'de', 'proxy.python.full_ver"...)
2014-08-22 22:20:00,850 will process ui packet gibberish
2014-08-22 22:20:00,850 Received uninterpretable nonsense from Protocol(SocketConnection(('127.0.0.1', 31001) - ('127.0.0.1', 59099))): invalid packet format, not an xpra client?
2014-08-22 22:20:00,850  data: "hello: {'named_cursors': 1, 'pango.version': '1.29.4', 'xkbmap_layout': 'de', 'proxy.python.full_ver"...
2014-08-22 22:20:00,851 Disconnecting client Protocol(SocketConnection(('127.0.0.1', 31001) - ('127.0.0.1', 59099))): invalid packet format, not an xpra client?

From what I got until now, the server fails in xpra/net/protocol.py in the line "if read_buffer[0] not in ("P", ord("P")):"
If a client connects directly (i.e., without proxy), a prefix of 8 Bytes is sent which begins with a "P" (0x50) character. However, the proxy does not seem to forward these 8 bytes. The server then checks if the first byte is a "P". However, it is an "h" (from "hello:...") and therefore fails.

Thanks in advance for any help!
Stephan

@totaam
Copy link
Collaborator Author

totaam commented Aug 23, 2014

2014-08-23 02:43:02: totaam changed priority from major to critical

@totaam
Copy link
Collaborator Author

totaam commented Aug 23, 2014

2014-08-23 02:43:02: totaam changed owner from antoine to sschnitzer

@totaam
Copy link
Collaborator Author

totaam commented Aug 23, 2014

2014-08-23 02:43:02: totaam edited the issue description

@totaam
Copy link
Collaborator Author

totaam commented Aug 23, 2014

2014-08-23 02:43:02: totaam commented


Sorry about that, r7420 should fix this. (r7421 is also worth having)

Does that work for you?

Will backport both to v0.14.x and make a new release.

@totaam
Copy link
Collaborator Author

totaam commented Aug 23, 2014

2014-08-23 04:10:50: totaam changed status from new to closed

@totaam
Copy link
Collaborator Author

totaam commented Aug 23, 2014

2014-08-23 04:10:50: totaam changed resolution from ** to fixed

@totaam
Copy link
Collaborator Author

totaam commented Aug 23, 2014

2014-08-23 04:10:50: totaam commented


Backport to v0.14.x in 7422, feel free to re-open if I've missed anything.

@totaam totaam closed this as completed Aug 23, 2014
@totaam
Copy link
Collaborator Author

totaam commented Aug 23, 2014

2014-08-23 11:22:11: sschnitzer commented


It works after I applied both, r7420 and r7421.
Thanks!

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

No branches or pull requests

1 participant