Add a Test SV2 connection button to the pool settings#1752
Conversation
Users who pick SV2 on a pool that doesn't support it silently end up on the fallback and wonder why. This adds a button under the SV2 authority key field that probes the entered pool for SV2 support before saving. The probe opens a throwaway TCP connection, sends a Noise handshake init and checks whether the pool answers with a Noise response. It doesn't complete the handshake and doesn't touch the running miner. Backend does the work and returns the verdict; the frontend just shows it.
|
Ideally, this should be a test pool connection button, not just for SV2. But not entirely sure how much you can do to test? At least url:port, and maybe the SV1 auth as well, that could sometimes be rejected (depending on the pool, I guess) |
|
maybe this should be ported over to a logic that always happens. when new pool credentials are put into the user input field and we click on save maybe we should do a quick test then and only save the new fields when stratum.auth works. Having an extra button might be way too confusing and having an underlying logic that quickly checks for the user if he has done everything correct with a response would be nicer. I don't wanna introduce more and more buttons to the ui, it might clutter everything. |
|
With your suggestion this test would always happen whenever you change your connection, you would have to wait a second or two until the settings has been saved. Not ideal either. I suggest to take @mutatrum proposal. Also I don't see anything "way to confusing" on a Test Connection button, also I don't see buttons cluttering the UI, never ever felt personally that there is a button too much, and also, the new button is hidden under the Advanced Options. People actually like buttons, gives them more control instead of doing something everytime which might be not needed. |
3 participants
Might be a confusion future: someone picks SV2 on a pool that only speaks SV1, the device quietly falls back, and they wonder why they're on the fallback pool. This adds a "Test SV2 connection" button under the SV2 authority key field (shown when a pool is set to SV2) so you can check before saving.
The test opens a throwaway TCP connection to the entered pool, sends a Noise handshake init and checks whether the pool answers with a Noise response — an SV1 pool won't. It deliberately doesn't complete the handshake (no crypto needed on our side, since ElligatorSwift accepts any 64-byte ephemeral) and runs on its own short-lived socket, so the running miner isn't touched.
Backend does the probe and returns
{ supported, message }; the frontend just shows the result as a toast. Works for both the primary and fallback pool.Tested on hardware against an SV2 and an SV1 pool.
SV2 compatible:
Not SV2 compatible