Re: [ANN][POOL] Profit switching pool

My cgminer started falling back to a backup pool and no longer connecting to the Waffle EU server. I see in my firewall logs that it tries to connect to 206.223.224.225:3009. Is that address related to Wafflepool and how so? It shows on whois lookup as a residential cable in Montreal, Canada. If I restart the cgminer it connects to Waffle EU normally but the same thing happens after a while.

Take notice that Meeho captured both the unexpected ip address and TCP PORT to which cgminer was attempting to connect, thereby further ruling out the possibility of a dns hijack, as dns maps host names to ip addresses only, and applications themselves handle port assignments.

The change of tcp port can only occur as a result of having received a client.reconnect command message from the stratum server, or a spoof thereof -- or the existence of other malware present on the mining computers themselves. Dns hijacking can not possibly explain the cause of a miner process attempting to connect to a pool stratum server on a different tcp port.

Furthermore, as wafflepool servers had previously been experiencing a mysterious underreporting of miner hashrates, which was identified mostly by cudaminers hearing their gpu fans spin down as cudaminer was waiting for more work to be sent from the wafflepool stratum server, that means cgminer with configured backup servers which by default will leak work to backup servers in the case of an underperforming active server, might even have received a client.reconnect command message from a stratum server other than wafflepool stratum server, as it could possibly have originated from a backup stratum server. So those possible sources are too in play.

From ckolivas cgminer 3.7.2 readme:

Options for both config file and command line:

--failover-only Don't leak work to backup pools when primary pool is lagging

Q: Work keeps going to my backup pool even though my primary pool hasn't
failed?

A: Cgminer checks for conditions where the primary pool is lagging and will
pass some work to the backup servers under those conditions. The reason for
doing this is to try its absolute best to keep the GPUs working on something
useful and not risk idle periods. You can disable this behaviour with the
option --failover-only.

I was going to say that I also use Google DNS and saw this happen to me, but that's a good point regarding the port change. Do you know if only active pools can trigger this? I had my miner configured for four pools, two of which are disabled, and two were set with a quota. Unfortunately I don't have any logs from the event.

Does anyone else who had this happen connect to multiple pools?

Randomly, a day or two before this started up, I read some old forum posts between slush and another op arguing over how to move forward with stratum and why you would ever need a command to redirect miners to other servers while looking for ways to improve my solo mining tests...

From what I understand, the client.reconnect command was included to seamlessly move miners over to another pool stratum server in preparation for maintenance on the originally active server. As to whether a backup stratum server could trigger cgminer to suspend all active stratum server connections, I really cannot provide a firm answer. It would make sense that a client.reconnect command message should only suspend one active stratum connection (the one on which it arrived), but there always exists the possibility of other unforeseen behavior within the implementation of the code. Either way, the dns hijacking theory is discounted by the tcp port having been changed too, and perhaps the local miner malware possibility is much more likely. But in order to find out which, we must all stop placing blame on dns hijacking ghosts.

Update: I misread your question. Yes a stratum connection must be active in order for a miner to receive a client.reconnect command message, and only the miner side can initiate a stratum connection. In your case using quotas (as per your description), you would have active connections to a minimum of two stratum servers. But even without using quotas, cgminer will connect to backup servers IF the active server cannot provide work at a rate fast enough to keep the GPUs fully utilized. (unless the failover-only option is specified on the command line or in the configuration file.)

Another update: I've realized that technically speaking, a dns hijack could still indeed be in play, followed by a client.reconnect message from a rogue stratum server in order to change the tcp port, but that just seems awfully convoluted. For if one were to hijack a dns server to redirect a miner to a different server on port 3333, why would they they redirect again to port 3009? -- unless they are using the technique to load balance stolen hashpower to multiple rogue servers, but then only one rogue ip address and tcp port combination has been reported here. Has anyone observed any other rogue server ip addresses or tcp ports?