Author

Topic: [POOL][Scrypt][Scrypt-N][X11] Profit switching pool - wafflepool.com - page 136. (Read 465668 times)

member
Activity: 70
Merit: 10
I was wondering why am I not getting paid my btc? http://wafflepool.com/miner/16oV1eHgFWN5yGu6hexB4ziUhKRiE8FYYv
It's been over 24 hours that my balance is over 0.01 btc.

Operator has been actively fighting/tracking a malware that was stealing hashrate.

However, payments just processed.
newbie
Activity: 7
Merit: 0
I was wondering why am I not getting paid my btc? http://wafflepool.com/miner/16oV1eHgFWN5yGu6hexB4ziUhKRiE8FYYv
It's been over 24 hours that my balance is over 0.01 btc.
member
Activity: 98
Merit: 10
I;ve been making twice as much mining GPUCoin than I have on WP 8-(
newbie
Activity: 55
Merit: 0
Hi,

Was wondering why you don't add REDD COIN.  It is more profitable than most of the coins mined on waffle ...

cheers,



There was a post a few pages (well more like 10 I suspect) where we were asked to provide things like the depth of the market (not less than 3BTC as I remember) for PW to consider adding coins - how does REDD look against these criteria?

Miles
newbie
Activity: 38
Merit: 0
Hi,

Was wondering why you don't add REDD COIN.  It is more profitable than most of the coins mined on waffle ...

cheers,

newbie
Activity: 4
Merit: 0
Poolwaffle, I've PM'd you another network capture Smiley
newbie
Activity: 14
Merit: 0
I use my ISP's DNS servers and had the problem. I think DNS hijack was ruled out, as there is a port change and miner reports being connected to the new server, not showing wafflepool's name anymore. And my separate pings to eu.wafflepool.com showed correct DNS resolving.
hero member
Activity: 798
Merit: 1000
This could still be a MITM attack via DNS Hijacking at Google's nameservers.

Keep in mind that Google has had very recent issues with DNS hijacking over the last week:
http://arstechnica.com/information-technology/2014/03/google-dns-briefly-hijacked-to-venezuela/

Also note that majority of the people posting here for the last few pages with the issue are using Google's DNS servers: 8.8.8.8 and 8.8.4.4

Is there ANYONE who has encountered this hijacking that aren't using Google's DNS servers either on the client or router level?

For instance, I did NOT encounter this hijack issue and I'm using Verizon's local FiOS dedicated DNS servers.
full member
Activity: 168
Merit: 100
I reviewed all my firewall logs (network edge has stateful packet inspection enabled) and did not find any dropped incoming tcp packets from port 3333 on either the hardware or software firewalls, and as my miners never switched to a different pool, it does not appear as if I ever received a client.reconnect message.  Connecting to the useast server.
newbie
Activity: 14
Merit: 0
No, mine was CleverMining.

And you had the issue happen to you?

Yes:
https://bitcointalksearch.org/topic/m.5844746
https://bitcointalksearch.org/topic/m.5853878


I tried to do a traceroute on the ip and it times out after a couple hops from my isp to max of 30 hops ...

anybody do a whois on it?  I don't know command on winblowz.  Suppose I could fire up LMDE in a Virtualbox and try ...

I got this: http://whois.domaintools.com/206.223.224.225
member
Activity: 84
Merit: 10
No, mine was CleverMining.

And you had the issue happen to you?

Is it possible that one of the multipools is using cryptovein for mining?
full member
Activity: 168
Merit: 100
The only reason I can think of for a redirect rather than just a hijacking is to allow him to repoint to various compromised servers.  Enable a MITM for a few seconds, redirect some traffic to a compromised box, turn off MITM.  Very difficult to see/catch the MITM happening if its only there for a few seconds, and the results (the redirected miners) will continue happily along for a while.


Check this out: https://bitcointalksearch.org/topic/m.5848594

It seems that Betarigs miners are having similar problem with stratum reconnect/hi-jacking?

This is actually very interesting.  One of the users we had seen an issue with originally has a backup pool as betarigs.

Can anyone else who has had the issue post if they have a backup pool set for betarigs?

Had the running stratum server code been updated to the patched version correcting the idling problem before all this client.reconnect stuff started happening?  -- as cgminer/kcgminer/sgminer users are much more likely to be leaking work to their backup pools if the older code still remains running on the server.  I would not recommend changing up any the variables right now in the middle of troubleshooting, but it would a good thing to know.
sr. member
Activity: 322
Merit: 254
No, mine was CleverMining.

And you had the issue happen to you?
newbie
Activity: 14
Merit: 0
No, mine was CleverMining.
sr. member
Activity: 322
Merit: 254
The only reason I can think of for a redirect rather than just a hijacking is to allow him to repoint to various compromised servers.  Enable a MITM for a few seconds, redirect some traffic to a compromised box, turn off MITM.  Very difficult to see/catch the MITM happening if its only there for a few seconds, and the results (the redirected miners) will continue happily along for a while.


Check this out: https://bitcointalksearch.org/topic/m.5848594

It seems that Betarigs miners are having similar problem with stratum reconnect/hi-jacking?

This is actually very interesting.  One of the users we had seen an issue with originally has a backup pool as betarigs.

Can anyone else who has had the issue post if they have a backup pool set for betarigs?
full member
Activity: 168
Merit: 100
The only reason I can think of for a redirect rather than just a hijacking is to allow him to repoint to various compromised servers.  Enable a MITM for a few seconds, redirect some traffic to a compromised box, turn off MITM.  Very difficult to see/catch the MITM happening if its only there for a few seconds, and the results (the redirected miners) will continue happily along for a while.

If he is only sending outgoing client.reconnect message packets to miners, and not rewriting incoming mining.authorize packets from miners, then the rogue stratum server to which he is redirecting hashpower is receiving the original user/pass, or in the case of wafflepool, the original btc address, and ignoring it -- which would mean it is completely under his control.

[changed my mind about this middle part of the post that I removed, and if you saw it then please note that a true mitm could circumvent all of my suggestions originally contained within]

For now, anyone downloading the miner code directly from github can change the client.reconnect command message text string to something else prior to compilation in order to insulate yourself from this current problem.
full member
Activity: 168
Merit: 100

To anyone and everyone using cgwatcher, whether your hashpower has been hijacked yet or not, you can configure cgwatcher to send an e-mail or perform another action when it detects a pool change in cgminer/kcgminer/sgminer.  To do this, click on the schedule tab, then add a scheduled action, and use the settings shown in the following image.  Then notify poolwaffle as soon as possible after your miner gets hijacked, and if you really want to be helpful, don't fix it until you hear back from him!


member
Activity: 84
Merit: 10
The only reason I can think of for a redirect rather than just a hijacking is to allow him to repoint to various compromised servers.  Enable a MITM for a few seconds, redirect some traffic to a compromised box, turn off MITM.  Very difficult to see/catch the MITM happening if its only there for a few seconds, and the results (the redirected miners) will continue happily along for a while.


Check this out: https://bitcointalksearch.org/topic/m.5848594

It seems that Betarigs miners are having similar problem with stratum reconnect/hi-jacking?
full member
Activity: 168
Merit: 100
The only reason I can think of for a redirect rather than just a hijacking is to allow him to repoint to various compromised servers.  Enable a MITM for a few seconds, redirect some traffic to a compromised box, turn off MITM.  Very difficult to see/catch the MITM happening if its only there for a few seconds, and the results (the redirected miners) will continue happily along for a while.

The idling miners turned out to be a different issue entirely unfortunately.  We re-send the exact same work request if we haven't sent a work update after 30 seconds (we had seen some miners timing out after 30 seconds of no new work), and some miners are seeing a duplicate work request (30 seconds later) and idling for some reason.

Don't think they're related.

One of the miners really needs to capture a client.redirect packet for analysis.  I will enable port mirroring on my switch and set up to capture relevant packets outside of the firewall on my end, but I might just never see one.  Can you clue me into the most likely server(s) whose network traffic is being inspected or redirected?
sr. member
Activity: 322
Merit: 254
The only reason I can think of for a redirect rather than just a hijacking is to allow him to repoint to various compromised servers.  Enable a MITM for a few seconds, redirect some traffic to a compromised box, turn off MITM.  Very difficult to see/catch the MITM happening if its only there for a few seconds, and the results (the redirected miners) will continue happily along for a while.

The idling miners turned out to be a different issue entirely unfortunately.  We re-send the exact same work request if we haven't sent a work update after 30 seconds (we had seen some miners timing out after 30 seconds of no new work), and some miners are seeing a duplicate work request (30 seconds later) and idling for some reason.

Don't think they're related.
Jump to: