HWI
HWI copied to clipboard
enumerate function hangs
I am trying to use the BitBox2 wallet with Sparrow in Windows10 but the enumerate function hangs.
I have debugged the code and the problem appears calling
jade.get_version_info
this ends up calling to
read_cbor_message
that tries to read from a TCP socket
# Throws EOFError on end of stream/timeout/lost-connection etc.
message = cbor.load(self)
and the recv method hangs forever, the EOFError is not thrown
return self.tcp_sock.recv(n)
If I remove Jade from the list of devices to be checked, the bitbox2 is correctly enumerated
Do you know why this happens? Does the socket need to be blocking?
The problem is solved by setting the socket to not blocking, but don't know if that breaks the setup for Jade wallet
self.tcp_sock.setblocking(False)
in the connect
method from jade_tcp.py
cc @JamieDriver
ok, enumeration doesn't block/hang for me (on linux) but I'll certainly look at adding that set-not-blocking call into the underlying python class if it doesn't have any negative impacts.
Ideally we wouldn't even be running this code (looking for a jade 'simulator') outside of running the test suite - but I don't know if that sort of thing is supported.
Thanks for the ping @prusnak
@santochibtc I have updated the jade code to respect the passed timeout at https://github.com/bitcoin-core/HWI/pull/631.
If this change works for you, I'll include it in https://github.com/bitcoin-core/HWI/pull/629 (in fact I'll delay that PR slightly and update to the next jade release version so the above change is included in the api files copied in).
Thanks, I tested #631 and it works with bitbox02, although I get this warnings and errors when it tries to connect with Jade
WARNING:jade:No module named 'requests'
WARNING:jade:Default _http_requests() function will not be available
ERROR:jade:Exception causing JadeAPI context exit.
ERROR:jade:<class 'TimeoutError'>
ERROR:jade:timed out
The execution finishes correctly
OK, that's cool. Many thanks for the report and the testing.
I will look to calm that overly highly-strung logging ;-)
Should be addressed by #629