Assumptions make poor foundations upon which to build any theory. Though hard coding ip addresses will circumvent the problem for now, it may cause unexpected outages in the future if pw reconfigures the server network.
Sorry, I take back the word assumption if you're going to be semantic.
Here's what I've seen, which I'm using to create my "theory": I have 2 mining setups, both pointing to useast.wafflepool.com. The two systems use different miners, one is using cgminer running under BAMT, the other is using cudaminer under win7. Both systems are NAT'd behind a router running dd-wrt.
With the difference in miners / systems, I don't think someone trojaning both my systems with different miners / OS's / authentications at the same time is likely. With other people reporting the same issue, it makes a lot of sense that some sort of DNS hijack took place.
I agree with you and don't recommend people hardcode an IP in their miner configs for long term use, but for the immediate future it would negate any sort of DNS issues should they continue.
I never suggested anyone infiltrated your systems with a trojan, and to rush to judgment that nothing else can be responsible other than a dns hijack, is a leap using poor reasoning.
Google "stratum client.reconnect", and notice that even if ip addresses are hard coded, you could still be vulnerable to this potential attack vector.
But as this would suggest a pool server vulnerability, I kept it private for a while to give pw a chance to collect whatever information he could to confirm or eliminate this possibility.
In simple English, within the legitimate code of most stratum mining software is a command called client.reconnect that can be issued by the server to tell any miner to switch to another server and port. If a pool server vulnerability had been found and exploited, it would be possible to send your miner a client.reconnect command to go mine elsewhere, anywhere.
Here is a snippet from ckolivas/cgminer 3.7.2 code:
if (!strncasecmp(buf,
"client.reconnect", 16) && parse_reconnect(pool, params)) {
ret = true;
return ret;
}
static bool parse_reconnect(struct pool *pool, json_t *val)
{
char *url, *port, address[256];
memset(address, 0, 255);
url = (char *)json_string_value(json_array_get(val, 0));
if (!url)
url = pool->sockaddr_url;
port = (char *)json_string_value(json_array_get(val, 1));
if (!port)
port = pool->stratum_port;
sprintf(address, "%s:%s", url, port);
if (!extract_sockaddr(address, &pool->sockaddr_url, &pool->stratum_port))
return false;
pool->stratum_url = pool->sockaddr_url;
applog(LOG_NOTICE, "Reconnect requested from pool %d to %s", pool->pool_no, address);
if (!restart_stratum(pool))
return false;
return true;
}
For those of you affected by the problem
with detailed cgminer logs, (from cgminer/sgminer, not cgwatcher as it does not log such messages), may I suggest that you search for "reconnect requested" messages for any possible evidence of this method being used.
