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

Using wrong part of the result to check compatible version #3738

Open
ben221199 opened this issue May 21, 2024 · 0 comments
Open

Using wrong part of the result to check compatible version #3738

ben221199 opened this issue May 21, 2024 · 0 comments

Comments

@ben221199
Copy link
Contributor

Dear,

When analyzing the code and writing my own hub, I struggled with the server.version method. In LBRY a request of server.version looks like {"method":"server.version","id":58,"jsonrpc":"2.0","params":["0.113.0","0.113.0"]} and a response looks like {"jsonrpc":"2.0","result":["0.107.0","0.113.0"],"id":47}. At first glance, it doesn't look compatible with the server.version of Electrum, but it is.

First the request. Electrum defines server.version(client_name, protocol_version), where client_name is the name of the client and protocol_version is the supported version or range of supported versions of the client. When looking at the code at https://github.com/lbryio/hub/blob/ebcc6e508660f72fe11d308ae4031971b5fbf782/hub/herald/session.py#L1688, this is indeed the case. The LBRY request is fully compatible with the Electrum request, so it is also possible to send a request like {"method":"server.version","id":58,"jsonrpc":"2.0","params":["LBRY Desktop 1.0.0","0.113.0"]} or {"method":"server.version","id":58,"jsonrpc":"2.0","params":["LBRY Desktop 1.0.0",["0.113.0","0.113.0"]]}.

Then the response. Electrum defines it as returning [server_software_version, protocol_version], where server_software_version is the name of server and protocol_version is the chosen protocol version by the server to communicate with. Looking at https://github.com/lbryio/hub/blob/ebcc6e508660f72fe11d308ae4031971b5fbf782/hub/herald/session.py#L1695 and https://github.com/lbryio/hub/blob/ebcc6e508660f72fe11d308ae4031971b5fbf782/hub/herald/session.py#L1723, it indeed returns 2 variables.

Now we take a look at the following code:

if tuple(int(piece) for piece in response[0].split(".")) < self.network.MINIMUM_REQUIRED:

Note the response[0]. Why does this client code check for the first variable? The protocol information is in the second variable. I assume that response[1] is the right solution.


Also, some logging (note line 106):

2024-05-21 21:34:42,756 ERROR    lbry.wallet.network:219: wallet server connection loop crashed
Traceback (most recent call last):
  File "lbry\wallet\network.py", line 216, in loop_task_done_callback
  File "lbry\wallet\network.py", line 321, in network_loop
  File "lbry\wallet\network.py", line 304, in connect_to_fastest
  File "lbry\wallet\network.py", line 106, in ensure_server_version
  File "lbry\wallet\network.py", line 106, in <genexpr>
ValueError: invalid literal for int() with base 10: 'LBRYum Hub 1'
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