Skip to content

fix(connector): answer connect-time Bandwidth Measure to unblock FreeRDP servers#1465

Open
Greg Lamberson (glamberson) wants to merge 1 commit into
Devolutions:masterfrom
lamco-admin:fix/connect-time-bandwidth-autodetect
Open

fix(connector): answer connect-time Bandwidth Measure to unblock FreeRDP servers#1465
Greg Lamberson (glamberson) wants to merge 1 commit into
Devolutions:masterfrom
lamco-admin:fix/connect-time-bandwidth-autodetect

Conversation

@glamberson

Copy link
Copy Markdown
Contributor

Summary

  • The connector answers only the RTT auto-detect request at connect time and returns nothing for the Bandwidth Measure Stop, on the assumption that skipping it does not stall the sequence.
  • That assumption fails for FreeRDP-based servers: GNOME Remote Desktop blocks in its AWAIT_BW_RESULT state until it receives a Bandwidth Measure Results reply and never proceeds to licensing, so the connection hangs right after the Client Info PDU. Windows servers tolerate the omission, which hid it.
  • Reply to a connect-time BandwidthMeasureStop with a BandwidthMeasureResults PDU. The connector does not run a stateful measurement, so it reports the payload the server sent over a nominal interval; the value is an informational QoS hint and the server proceeds on receipt.

Validation

  • cargo xtask check fmt/lints/tests/typos/locks all pass.
  • New regression test: a connect-time Bandwidth Measure Stop produces a response frame and the auto-detect phase continues.
  • Reproduced and fixed live against gnome-remote-desktop 49: before, the connector stalled after Client Info with grd in AWAIT_BW_RESULT; after, grd proceeds through licensing and DEMAND_ACTIVE to an active session.

Notes

…RDP servers

The connector answered only the RTT auto-detect request at connect time and
returned nothing for the Bandwidth Measure Stop, on the assumption that skipping
it does not stall the sequence. That assumption does not hold for FreeRDP-based
servers: GNOME Remote Desktop blocks in its AWAIT_BW_RESULT state until it
receives a Bandwidth Measure Results reply and never proceeds to licensing, so
the connection hangs after the Client Info PDU. Windows servers tolerate the
omission, which hid the problem.

Reply to a connect-time Bandwidth Measure Stop with a Bandwidth Measure Results
PDU. The connector does not run a stateful measurement, so it reports the payload
the server sent over a nominal interval; the figure is an informational QoS hint
and the server proceeds on receipt.

Adds a regression test that a connect-time Bandwidth Measure Stop produces a
response frame and the auto-detect phase continues.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant