Sign transaction error: session not found #247
Comments
|
Try different USB cable, different port, etc. This is not a bug in Suite, but in communication with the device. |
|
could also be a Bridge problem. in that case, using web suite + webusb resolved the problem |
|
Hello, Suite: 21.12.2 EDIT: I can confirm WebUSB (thrught web based suite) works fine. So it's just in bridge most recent interesing log from verbose bridge calls during signature: |
|
Thanks, reopening |
|
I have also found a similar, maybe related, case trezor/connect#948 |
|
I tried to reproduce this issue in the recent version of Suite (22.1.1 e7262e5) but I wasn't successful yet. Nonetheless, I will be monitoring this issue and as soon as I find something, I will add it here. |
|
I tried to reproduce this issue throughout the past month on various versions of Suite and I wasn't successful. |
|
Problem still persist on latest suite, trezord and Trezor One firmware Trezor suite: 22.5.2 When trying to sign huge UTXO input TX, trezor session not found occurres. I can provide some debugging cooperation. I do not know why it is this closed if is NOT fixed yet... It is really problem if you can not send transaction and you have to send by smaller parts which you have to again merge (so you are able to send higher amount). More testing: I logged communication between trezord by wireshark, but nothing much I can see there.. Only POST 200, and then two POST will return "400 Bad request" with payload "Session not found". So probably better logging of trezord is needed to investigate this. |
|
Well I probably found something what can be connected with it... There is some long request to bridge (/listen) which hangs response for like 30 secods (or maybe until some /calls or /release are called? Did not checked code well yet.
In closer filter you can see this response came after 30 sec to the client... Maybe those asynchronous calls can be reason? I will check something like parallel requests from electron. And something like re-use connections (now I can see it reopen new TCP connection for every call) |
|
Problem is, I am not Golang programmer, so I do not understand well to those async things.. Also when is ctx.Done() True? From documentation of http.Request.context() I am not too much wise... But also I read documentation of "select" which waits until atleast some job is done (true), in case of method "Call" it is eighter finished (probably call?) or that context.done() (which will close USB session and causes this issue)... from documentation if both are true, Golang will use "random" to select one of it. That means, if context is done and call already finished too, then in random cases ctx.done() could be called prior to finished (return) one.. But I tested it on |
|
I solved this problem over a year ago by switching to another brand of hardware wallet. Let me just add, you probably wont have this problem unless you have some big transactions. Either way Trezor couldn’t handle it on both web and suite. It now resides as a hood ornament because no one could solve it. |
actually web with webusb works, because problem seems to be somewhere in bridge and it's asynchronous calls... As programmer I know async things are hell to debug... Especially if you do not have enough testing data and it happens only on some environments... That is why I trying to help somehow instead of just say "you are bad" and buy other wallet, because I think nothing can compare with trezor in other cases... |
No, as stated the problem persisted on both web and suite, which locked me out for an extended period and became quite costly. I didn’t say “you are bad”, I stated Trezor couldn’t handle it which I find unacceptable. If you pay good money for a device, it’s fair to expect that it works. Good luck and I hope you solve it. |
|
so one more time,, on web based suite with WebUSB (chromium/chrome) without trezord (bridge) it works fine... Also it would work with electrum. So there are atleast two options how to proceed those payments. I agree it's pity for newbie who buy boxed hardware and use official app (trezor suite) which have such problem. But still it's opensource, so anyone can help to diagnostic. You choose way to buy other device, that is also solution for some peoples. For me it is not solution and also use electrum or webusb will cause I will lost only one device, where this issue occurs and I will close way how to debug/help to solve it. |
|
I'm not Go developer either, perhaps a faux trezord load test can be devised to narrow down how big is too big and thus include it testing strategy. |
|
i just tried to send two big transactions "size": 14882, and "size": 7535, and resend/resign it via bump fee but it never failed in app with embedded bridge. T1 including white-noise background - https://tbtc2.trezor.io/tx/924195e88846242a5be5bffe587ae830d64936ac421da234f7df2d202cdf97ec Info:
|
|
@petrkr Perhaps you could try re-creating your BTC transaction with test coins. Then we can better analyse the problem transaction. Alternatively try and provide us some numbers, e.g. number of inputs, UTXOs, outputs, segwit ? etc. |
Detail transaction in suite says: there are 18 inputs as script_type": "SPENDP2SHWITNESS" I had same problem on more currencies (LTC, DOGE...) So that would not be problem of coin but somewhere in communication.... As I mention for example that async behavior of "select" and "random" selection of multiple true values. I can try access to some tBTC |
|
@petrkr the |
I see. Then I will really go for that select's random behavior where is ctx.Done() and finished. Seems at windows it does not occurs (bridge 27), Mac i do not have. When ctx is done? When http request is finished? It could be some localhost IP stack behaviorc so ctx.done is earlier than func finish.. or actually because it is 'go' rutine, it is like background task and ctx.done can be invoked earlier than defet (or how was that modifier) about finish true. Because IP stack is faster and it's multiprocesoring etc. I would like to add more debug logs in this code part to investigate,, but unfortunately I do not have too much time to help with it (even i actually wanted, because I like to do low-level things). For now I can only help by some evenings investigations, because I have environment where I can reproduce it. |
|
per the http.request docs:
your tcp dump seems to indicate that the client didn't close anything from my reading of the code and docs, it seems that your guess is correct: the deferred try placing this in the ctx.done branch: select {
case <-finished:
return
default:
}(iow, if you receive a Done, non-blocking-check if you don't also have a finished waiting) the question is of course why in the world you can reproduce this so reliably while we're hammering the bridge hard as we can without results 🤷♀️ |
|
this is clearly a bridge issue at this point, @prusnak can you please move to the bridge repo? |
Done |
|
Issue #197 (closed as duplicate of this issue) describes the same error but with Electrum |
Sending from Account 1 P2SH address to newly created Account 2 with new P2SH address returns error:
Sign transaction error: session not found
Trezor model T freezes.
The text was updated successfully, but these errors were encountered: