-
Notifications
You must be signed in to change notification settings - Fork 132
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
not retrying on DNS failures #184
Comments
I have the same problem with 2.1.6. Wifi reconnect works and webinterface is reachable again. But mining does not start. Only a manually triggered reboot solves the problem. |
I've tested it some minutes ago and it's working on my two Bitaxe 204 (Ultra). When the wifi network was down, both devices were showing both connecting to my ssid and the AP ssid available messages. When the network was available again, both connected and started showing the mining information. |
For me it's not working: |
0.0.0.0 sounds like a DNS problem somewhere. |
I've seen this too. It's possible that once the connection is lost, it can't resolve the URL to an IP address. solo.ckpool.org is 2604:2dc0:100:240f::1 Maybe we could try mining directly with the pool's IP address to see if there are any errors. *Edited |
Same Problem with 2.1.6 and 2.17 and possible older versions.
Looking at the source, it seems like stratum_task() does not check if the dns lookup was successful (resolved ip = 0.0.0.0) and does not try to resolve the dns again. Then stratum_task() does try to connect to the unresolved ip endlessly -> can't connect to pool. |
when a pool URL resolves to 0.0.0.0 that likely means there was a DNS failure. We should be recognizing this error and retrying until it works. |
Ah, I see what's going on here. The DNS lookup is not in the retry loop. So if for whatever reason DNS fails it sets the IP to 0.0.0.0. The Bitaxe will just keep retrying this bad IP.
|
I made a 2.1.8b1 build with this fix; can y'all give it a try? |
With 2.1.8 i had at least one instance where dns lookup only partialy resolved the pool ip and firmware stopped after that: Serial Log
Bitaxe did not continue, had to Reboot via Webinterface Note the resolved IP: 0.0.0.149 Looks like the ip was only partialy "resolved" or converted? The correct ip is 46.101.2.149
SNIP
SNIP
|
How long did you wait before rebooting? |
@skot the first time it sit stuck like 4h+. Got the issue again tonight, Uptime was 7h (i belive it was stuck like 6h) and again for about an hour. |
this is still happening in 2.1.8. need to merge in @BitMaker-hub fix from #185 |
Describe the bug
Router rebooted today. Miners lost connection but seem to have all (5 of them) connected back to wifi after it came back online. However, all 5 did not start mining.
I can connect to them on the local LAN. This is what I am seeing in the logs:
₿ (899188) stratum_task: Socket unable to connect to public-pool.io:21496 (errno 113)
₿ (904188) stratum_task: Socket created, connecting to 0.0.0.0:21496
One seems to have rebooted on its own after about 18 minutes and it is now mining. The others have not rebooted and are still showing that same information in the logs. Rebooting them gets them mining again.
The text was updated successfully, but these errors were encountered: