rigelminer
commented
11 months ago Thanks for reporting.
FYI "protocol-dump" option is --log-network.
Open PSLLSP opened 11 months ago
rigelminer
commented
11 months ago Thanks for reporting.
FYI "protocol-dump" option is --log-network.
PSLLSP
commented
11 months ago Update, the issue with --log-network parameter, message {"method": "client.reconnect", "id": 0, "error": null, "params": ["eu-de02.miningrigrentals.com","52868"]} is visible in the output:
$ sh test-mrr-nexapow-1.sh --log-network
...
│[2023-10-03 05:55:44] Rigel v1.8.1 - [Linux] │
│[2023-10-03 05:55:44] │
│[2023-10-03 05:55:44] Driver: v460.91.03 │
│[2023-10-03 05:55:44] │
│[2023-10-03 05:55:44] + GPU #0: GTX 1070 8G │
│[2023-10-03 05:55:44] │
│[2023-10-03 05:55:44] Pools for nexapow (dev fee 2.0%): │
│[2023-10-03 05:55:44] URL: eu-de02.miningrigrentals.com:3333 │
│[2023-10-03 05:55:44] User: droidMiner.292758 │
│[2023-10-03 05:55:44] Pass: TESTMRR1 │
│[2023-10-03 05:55:44] │
│[2023-10-03 05:55:44] GPU#0: using kernel 1 │
│[2023-10-03 05:55:44] [eu-de02.miningrigrentals.com:3333] connecting... │
│[2023-10-03 05:55:44] [eu-de02.miningrigrentals.com:3333] connected │
│[2023-10-03 05:55:44] [eu-de02.miningrigrentals.com:3333] => {"id":0,"method":"mining.subscribe","params":["Rigel/1.8.1"]} │
│[2023-10-03 05:55:44] [eu-de02.miningrigrentals.com:3333] => {"id":1,"method":"mining.authorize","params":["droidMiner.292758","TESTMRR1"]} │
│[2023-10-03 05:55:44] [eu-de02.miningrigrentals.com:3333] <= {"error": null, "id": 1, "result": true} │
│[2023-10-03 05:55:44] [eu-de02.miningrigrentals.com:3333] <= {"method": "client.reconnect", "id": 0, "error": null, "params": ["eu-de02.miningrigrentals.com","52868"]} │
│[2023-10-03 05:55:44] [eu-de02.miningrigrentals.com:3333] connection error: unexpected EOF Thanks. Do you know if it should only be redirecting you to the same host? This feature may pose some security risks if I allow redirecting to a different domain name.
PSLLSP
commented
11 months ago MRR uses the same host but in theory, that could be any other host or just an IP address. Some miners have parameter to disable this redirection, like --no-redirect in pooler CPU miner... When pooler cpuminer ignores redirection then it reports it to the output, this is good for troubleshooting... applog(LOG_INFO, "Ignoring request to reconnect to %s", url);
For security reason, it is good idea to report to the output/log what happens, where the miner is redirected. I like the way gminer reports redirection, nice work...
MRR can use client.reconnect in other way. When miner connects to a dynamically allocated port that was already assigned to different miner, it is instructed to reconnect to TCP port 3333 and after that it will be sent to new TCP port, so two redirection will happen... This is rare situation but could be useful for old configuration where miner configuration was "hardcoded" to custom TCP port because it was not supporting redirection... Nice magic... ;-)
A bonus, test for ERGO at MRR:
$ cat test-mrr-ergo.sh
#!/bin/sh
POOL="eu-de01.miningrigrentals.com:3333"
#POOL="eu-de01.miningrigrentals.com:53637"
USER="droidMiner.217529"
PASS="TESTMRR3"
./rigel -a autolykos2 -o "stratum+tcp://$POOL" -u "$USER" -p "$PASS" $@
rigel 1.8.1, Linux
rigelignores method client.reconnect(). This stratum method is used by mining pool MiningRigRentals to dynamically allocate TCP ports for miners. Miner connects to TCP port 3333 and pool uses method client.reconnect() to redirect miner to newly allocated TCP port.DEMO, mine NEXA at MRR, connect to TCP port 3333; it doesn't work, the issue:
Workarround, hardcode dynamically allocated TCP port to the mining script, to prove that
rigelcan mine NEXA at MRR. The issue here is that TCP port was allocated dynamically and it will change in the future and new value of TCP port has to be found and fixed in the mining script...BTW, I cannot find parameter for
rigelto activate "protocol-dump"; this is useful for protocol debugging, it will help in this issue where client.reconnect() message is received and what is in the reconnect message...See similar issue in
gminer; they already fixed it some time ago...