[core] Fixed version rejection for HSv4 caller #2010
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ethouris
added
[core]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #2008 (although maybe partially)
The problem: HSv4 connection procedure didn't predict rejection on minimum version.
The problem with HSv4 version is that the connection is fully made in UDT terms, and HSREQ extension will be sent later as an extended message, and at this time it's way too late to decide about rejection. Therefore the full version check is impossible to be implemented for HSv4 clients.
However it's possible to reject any HSv4 clients if the minimum version is set to the version that supports HSv5, that is, 1.3.0. The rule is that if a client supports HSv5, it must use HSv5 connection method, if the other party accepts it. This means that the HSv5 listener must respond with HSv5 if it supports it, and then the caller cannot use HSv4 against a listener that reports HSv5.
The fix then simply rejects, as a listener, any caller that tries to use HSv4, if the minimum version is 1.3.0 or higher. Of course, if the minimum version is set 1.2.3, then clients using 1.2.0 version will be accepted - this rejection isn't possible to be implemented.
Also, the rejection of HSv4 clients uses SHUTDOWN message instead of rejection handshake because HSv4 versions don't have the rejection hadnshake handling properly implemented and consider themselves connected upon reception of a handshake, even if it contains error code. During the tests it has been found out that the HSv4 clients stubbornly stay connected even after reception of SHUTDOWN during the handshake, but at least then an attempt to send fails.