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

Fail to unlock Jade DIY tdisplay #1616

Open
jpph opened this issue Feb 4, 2025 · 13 comments
Open

Fail to unlock Jade DIY tdisplay #1616

jpph opened this issue Feb 4, 2025 · 13 comments

Comments

@jpph
Copy link

jpph commented Feb 4, 2025

Image

On latest 2.1.1, it can unlock Lilygo T-Display S3 Pro with Cam but not the legacy T-Display (the one at 10usd).
It can interact with it only if I first unlock it with electrum (enter the pin ) then close electrum and then open sparrow.
attached logs. It is like it timeout before entering the pin in the tdisplay

sparrow.log

Edit1: If I empty the sparrow.log file, and test again, the log file stay empty. I think the log file I attached contain previous errors, not this one
Edit2 : I sent you 15usd (btcpay trx ( id TxMobRRwFB7TDi5876xtAq). If you want to buy a Lilygo T-display , you can take the 4MB version with shell (K163)

@qdwang
Copy link

qdwang commented Feb 5, 2025

Same error here with LILYGO T-Display-S3

When the device is initialized(with seed inside), after entering the PIN, it will display Connecting... for a few seconds and then shows Network or server error

When the device is uninitialized, after entering the new PIN twice, it will display Persisting PIN data... for a few seconds and then shows Network or server error

Like @jpph described, only by passing this step with Electrum, then I can use the device with Sparrow.

@qdwang
Copy link

qdwang commented Feb 5, 2025

And even if one use Electrum to unlock the device first, there is still issue in the signing step

Image

If i click Rescan, it shows:

Image

@craigraw
Copy link
Collaborator

craigraw commented Feb 5, 2025

Ok, I've ordered both the legacy T-Display and the Lilygo T-Display S3. I should be able to test directly in a week or so.

@jpph
Copy link
Author

jpph commented Feb 5, 2025

I have made further investigation, I confirm I get error trying to sign on the legacy Tdisplay. So pin entry unlock (with oracle server) and signing is not working. Verify receive adress is working.
With the Lilygo S3 pro with camera I was able to unlock, verify adress and send transaction ! I think the main difference between the Tdisplay, tdisplay s3 and tdisplay s3 pro with cam is that the tdisplay s3pro with cam is receiving the diy firmware from the jade plus (ability to unlock and sign with qrcode with camera).

@craigraw
Copy link
Collaborator

craigraw commented Feb 7, 2025

Ok, I have received and tested with LILYGO T-Display-S3. I did the setup over USB with Blockstream Green. I have no problems with unlocking the device, signing or displaying addresses. I am still waiting for the legacy T-Display.

@qdwang It appears your issue is that the device is returning a URL for the PIN oracle that can't be accessed by Sparrow for some reason. Have you checked sparrow.log to see if there are any relevant errors? See the FAQ to find Sparrow home.

@sandman21vs
Copy link

sandman21vs commented Feb 7, 2025

I come to report that the same error happens to me
however, I was using an older version of sparow and it wasn't happening, a colleague of mine who also has a ttgo t display got in touch saying there were errors, so we updated the firmware to the latest version 1.0.33-96-ga
and we updated sparow to version 2.1.1, after updating sparow on my computer I stopped being able to access jade (which was possible in the older version, I'm still trying to find out which version of sparow I was using previously, I'll comment here soon)

edit

I just tested version 2.0.0 msi here and it is working correctly with jade diy ttgo t display
I believe that in the implementation of 2.1.1 there was some conflict because of the pro version of Jade that came out, I hope that this comment helps anyone who sees the post later and that the devs have a basis for research

@qdwang
Copy link

qdwang commented Feb 11, 2025

@craigraw Here is the log

2025-02-11 10:14:12,761 DEBUG [Thread-17] c.s.j.Native [null:-1] Looking in classpath from jdk.internal.loader.ClassLoaders$AppClassLoader@3d82c5f3 for /com/sun/jna/darwin-aarch64/libjnidispatch.jnilib
2025-02-11 10:14:12,762 DEBUG [Thread-17] c.s.j.Native [null:-1] Found library resource at jrt:/com.sparrowwallet.merged.module/com/sun/jna/darwin-aarch64/libjnidispatch.jnilib
2025-02-11 10:14:12,763 DEBUG [Thread-17] c.s.j.Native [null:-1] Extracting library to /Users/qdwang/Library/Caches/JNA/temp/jna18100386240907245598.tmp
2025-02-11 10:14:12,763 DEBUG [Thread-17] c.s.j.Native [null:-1] Trying /Users/qdwang/Library/Caches/JNA/temp/jna18100386240907245598.tmp
2025-02-11 10:14:12,812 DEBUG [Thread-17] c.s.j.Native [null:-1] Found jnidispatch at /Users/qdwang/Library/Caches/JNA/temp/jna18100386240907245598.tmp
2025-02-11 10:14:12,817 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Looking for library 'hidapi'
2025-02-11 10:14:12,817 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Adding paths from jna.library.path: null
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Trying libhidapi.dylib
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Loading failed with message: dlopen(libhidapi.dylib, 0x0009): tried: 'libhidapi.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibhidapi.dylib' (no such file), '/Applications/Sparrow.app/Contents/Frameworks/libhidapi.dylib' (no such file), '/Applications/Sparrow.app/Contents/PlugIns/libhidapi.dylib' (no such file), '/usr/lib/libhidapi.dylib' (no such file, not in dyld cache), 'libhidapi.dylib' (no such file), '/usr/lib/libhidapi.dylib' (no such file, not in dyld cache)
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Adding system paths: [/usr/lib]
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Trying libhidapi.dylib
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Loading failed with message: dlopen(libhidapi.dylib, 0x0009): tried: 'libhidapi.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibhidapi.dylib' (no such file), '/Applications/Sparrow.app/Contents/Frameworks/libhidapi.dylib' (no such file), '/Applications/Sparrow.app/Contents/PlugIns/libhidapi.dylib' (no such file), '/usr/lib/libhidapi.dylib' (no such file, not in dyld cache), 'libhidapi.dylib' (no such file), '/usr/lib/libhidapi.dylib' (no such file, not in dyld cache)
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Trying /Users/qdwang/Library/Frameworks/hidapi.framework/hidapi
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Loading failed with message: dlopen(/Users/qdwang/Library/Frameworks/hidapi.framework/hidapi, 0x0009): tried: '/Users/qdwang/Library/Frameworks/hidapi.framework/hidapi' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/qdwang/Library/Frameworks/hidapi.framework/hidapi' (no such file), '/Users/qdwang/Library/Frameworks/hidapi.framework/hidapi' (no such file), '/System/Library/Frameworks/hidapi.framework/hidapi' (no such file, not in dyld cache)
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Trying /Library/Frameworks/hidapi.framework/hidapi
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Loading failed with message: dlopen(/Library/Frameworks/hidapi.framework/hidapi, 0x0009): tried: '/Library/Frameworks/hidapi.framework/hidapi' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Library/Frameworks/hidapi.framework/hidapi' (no such file), '/Library/Frameworks/hidapi.framework/hidapi' (no such file), '/System/Library/Frameworks/hidapi.framework/hidapi' (no such file, not in dyld cache)
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Trying /System/Library/Frameworks/hidapi.framework/hidapi
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Loading failed with message: dlopen(/System/Library/Frameworks/hidapi.framework/hidapi, 0x0009): tried: '/System/Library/Frameworks/hidapi.framework/hidapi' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/System/Library/Frameworks/hidapi.framework/hidapi' (no such file), '/System/Library/Frameworks/hidapi.framework/hidapi' (no such file, not in dyld cache)
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.Native [null:-1] Looking in classpath from jdk.internal.loader.ClassLoaders$AppClassLoader@3d82c5f3 for hidapi
2025-02-11 10:14:12,818 DEBUG [Thread-17] c.s.j.Native [null:-1] Found library resource at jrt:/org.hid4java/darwin-aarch64/libhidapi.dylib
2025-02-11 10:14:12,819 DEBUG [Thread-17] c.s.j.Native [null:-1] Extracting library to /Users/qdwang/Library/Caches/JNA/temp/jna6104677367100336179.tmp
2025-02-11 10:14:13,091 DEBUG [Thread-17] c.s.j.NativeLibrary [null:-1] Found library 'hidapi' at /Users/qdwang/Library/Caches/JNA/temp/jna6104677367100336179.tmp
2025-02-11 10:14:13,328 DEBUG [HttpClient-Default-scheduler-1] o.e.j.c.HttpClientTransport [null:-1] Could not connect to HttpDestination[https://api.coingecko.com]@3d8ae5f8,state=STARTED,queue=1,pool=DuplexConnectionPool@1c618b75[s=STARTED,c=1/1/64,a=0,i=0,q=1,p=Pool@3420bd57[inUse=0,size=1,capacity=64,closed=false]],stale=false,idle=-1
2025-02-11 10:14:13,328 DEBUG [HttpClient-Default-scheduler-1] o.e.j.c.HttpClientTransport [null:-1] Could not connect to HttpDestination[https://api.coingecko.com]@3d8ae5f8,state=STARTED,queue=1,pool=DuplexConnectionPool@1c618b75[s=STARTED,c=1/1/64,a=0,i=0,q=1,p=Pool@3420bd57[inUse=0,size=1,capacity=64,closed=false]],stale=false,idle=-1
2025-02-11 10:14:13,329 ERROR [RxCachedThreadScheduler-1] c.s.t.h.c.JacksonHttpClient [null:-1] getJson failed: https://api.coingecko.com/api/v3/exchange_rates: com.sparrowwallet.tern.http.client.HttpNetworkException: java.util.concurrent.ExecutionException: java.net.NoRouteToHostException: No route to host
2025-02-11 10:14:13,329 WARN [Thread-7] c.s.s.n.ExchangeSource [null:-1] Error retrieving currency rates
com.sparrowwallet.tern.http.client.HttpNetworkException: java.util.concurrent.ExecutionException: java.net.NoRouteToHostException: No route to host
	at com.sparrowwallet.tern/com.sparrowwallet.tern.http.client.JettyHttpClient.makeRequest(Unknown Source)
	at com.sparrowwallet.tern/com.sparrowwallet.tern.http.client.JettyHttpClient.requestJsonGet(Unknown Source)
	at com.sparrowwallet.tern/com.sparrowwallet.tern.http.client.JacksonHttpClient.lambda$getJson$0(Unknown Source)
	at com.sparrowwallet.tern/com.sparrowwallet.tern.http.client.JacksonHttpClient.handleNetworkError(Unknown Source)
	at com.sparrowwallet.tern/com.sparrowwallet.tern.http.client.JacksonHttpClient.lambda$getJson$1(Unknown Source)
	at com.sparrowwallet.tern/com.sparrowwallet.tern.http.client.JacksonHttpClient.lambda$httpObservable$8(Unknown Source)
	at [email protected]/io.reactivex.internal.operators.single.SingleFromCallable.subscribeActual(Unknown Source)
	at [email protected]/io.reactivex.Single.subscribe(Unknown Source)
	at [email protected]/io.reactivex.internal.operators.single.SingleSubscribeOn$SubscribeOnObserver.run(Unknown Source)
	at [email protected]/io.reactivex.Scheduler$DisposeTask.run(Unknown Source)
	at [email protected]/io.reactivex.internal.schedulers.ScheduledRunnable.run(Unknown Source)
	at [email protected]/io.reactivex.internal.schedulers.ScheduledRunnable.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.util.concurrent.ExecutionException: java.net.NoRouteToHostException: No route to host
	at [email protected]/org.eclipse.jetty.client.util.FutureResponseListener.getResult(Unknown Source)
	at [email protected]/org.eclipse.jetty.client.util.FutureResponseListener.get(Unknown Source)
	at [email protected]/org.eclipse.jetty.client.HttpRequest.send(Unknown Source)
	... 17 common frames omitted
Caused by: java.net.NoRouteToHostException: No route to host
	at java.base/sun.nio.ch.Net.connect0(Native Method)
	at java.base/sun.nio.ch.Net.connect(Unknown Source)
	at java.base/sun.nio.ch.Net.connect(Unknown Source)
	at java.base/sun.nio.ch.SocketChannelImpl.connect(Unknown Source)
	at [email protected]/org.eclipse.jetty.client.AbstractConnectorHttpClientTransport.connect(Unknown Source)
	at [email protected]/org.eclipse.jetty.client.HttpClient$1.connect(Unknown Source)
	at [email protected]/org.eclipse.jetty.client.HttpClient$1.access$100(Unknown Source)
	at [email protected]/org.eclipse.jetty.client.HttpClient$1$1.failed(Unknown Source)
	at [email protected]/org.eclipse.jetty.client.AbstractConnectorHttpClientTransport.connectFailed(Unknown Source)
	at [email protected]/org.eclipse.jetty.client.AbstractConnectorHttpClientTransport$ClientSelectorManager.connectionFailed(Unknown Source)
	at [email protected]/org.eclipse.jetty.io.ManagedSelector$Connect.failed(Unknown Source)
	at [email protected]/org.eclipse.jetty.io.ManagedSelector$Connect.run(Unknown Source)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	... 5 common frames omitted

I got this log by using open -a Sparrow --args -l DEBUG -n testnet. After creating a new wallet, I selected "Connected Hardware Wallet" and clicked "Scan". The LILYGO device displayed the PIN entry interface, but Sparrow then displayed the error in @jpph 's first post.

@craigraw
Copy link
Collaborator

I have now tested the legacy T-Display. The issue is that the device is both sending RPC responses in a piecemeal fashion, and, at the same time, is sending quite a bit of INFO level logging over the wire. As far as I can tell, the combination of these two factors means that it appears the device has no more data to send, when in fact it is just working through creating more logs that should be part of one complete response. This causes incomplete responses to be read, as reading terminates too early due to the incorrect signalling of "no more bytes to read" on the input stream halfway through receiving an RPC response.

It is possible to detect this board and try add delays in reading from the device that improve the situation somewhat, but a much better solution is simply to suppress INFO logging, which is not necessary anyway:

idf.py menuconfig

Go to "Component config", "Log output", set "Default log verbosity" to Error (or No output).

idf.py flash

Once I did this, I had no issues with logging in, signing etc using the legacy T-Display.

@jpph
Copy link
Author

jpph commented Feb 11, 2025

This is not doable with the diy web flasher. You could manage detecting the debug stream ? It is working nice with electrum

@craigraw
Copy link
Collaborator

I would rather not. Introducing things like wait-loops are poor engineering, to solve a problem that should be solved upstream - ultimately, by specifying a protocol that has basic necessities like data framing, or at least writing all the data all at once. Unfortunately, for whatever reason the Jade's developers chose to not to do this, and application developers are left with a mess and imperfect answers. In addition, the "solution" I mentioned wasn't great - it only worked partially, there were still occasional errors.

Why not open an issue on https://github.com/Blockstream/jadediyflasher to request that the Jade firmware be built without INFO logging, which is for debugging purposes in any case and shouldn't be used in production builds.

@jpph
Copy link
Author

jpph commented Feb 11, 2025

Ok I have raised an issue to upstream (diyflasher doesnt have issue tracker)
Blockstream/Jade#214

@craigraw
Copy link
Collaborator

Fwiw I have attached the binaries I built which disable the INFO (really debug) logging.

jade tdisplay no info.zip

@qdwang
Copy link

qdwang commented Feb 12, 2025

I have already flash the firmware(with debug log) with secure boot. The problem is OTA a new firmware without debug log can cause the device unusable.

Is there another way to solve this?

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

4 participants