|
CubedRoot
|
 |
June 03, 2011, 07:11:50 PM |
|
How about deny everything and have people enter their worker IPs when they setup workers. Then just open up the source IP for each worker.
+1 Simpel and effective HEh... see my post above yours.... not simple if your ISP gives you dynamic IPs that change every few days. |
|
|
|
|
|
|
|
|
|
"Bitcoin: mining our own business since 2009" -- Pieter Wuille
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
DeiBellum
Newbie
 Offline
Activity: 22
Merit: 0
|
|
June 03, 2011, 07:13:48 PM |
|
Cubed Root has it right on.
Most ISPs use a Dynamic IP system for all the routers on their network. They can change frequently and would leave people SOL once their's changed.
I think the best long term solution would be to have an automatic firewall tool. Some templates I would recommend would be fail2ban or denyhosts. These both use "After X attempts and Y failures" approach and is something that I could see being adapted for the mining server.
|
|
|
|
|
|
bitcoindaddy
|
|
June 03, 2011, 07:30:07 PM |
|
I think eleuthria has gotten things under control again. My hash rate (on the website) has gone back up and the total GHash rate of btcguild is skyrocketing.
|
|
|
|
|
|
Carnth
|
|
June 03, 2011, 07:35:04 PM |
|
What is the problem to do this banning automatically? either using iptables or directly in the pool server daemon?
Count number of requested shares, returned .. if exceeds some maxima, ban the IP for 10 minutes.
Doing this by "hand" from logs is tedious work which will not adapt to other DDoSers.
I don't think you realize that this is the first time this has happened to this pool. I very sure eleuthria will do exactly what you suggest to take care of any future problems. Again everyone.... You patience during these growing pains is appreciated. Eleuthria is working his ass off trying to make this the best pool there is. |
|
|
|
|
|
Carnth
|
|
June 03, 2011, 07:39:44 PM |
|
How about deny everything and have people enter their worker IPs when they setup workers. Then just open up the source IP for each worker.
Although this would solve problems for the pool servers, we "the masses" are not very good at doing this. I'm sure most people who are mining right now know their way around an IP address. But the "average" person doesn't. Plus then you have to deal with dynamic IPs and the whole thing gets way to complicated. |
|
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
June 03, 2011, 08:08:14 PM |
|
Part of the problem has been identified and corrected, related to the update pushed yesterday (index was in reversed order, causing MySQL to lock a much larger portion of the table than needed when doing an update).
This has been corrected, and the frequency of idles has plummeted already. There is still the problem of some miners, which I previously called an attack. It is POSSIBLE these are not actual hostile attacks, and rather a number of misconfigured miners, or miners operating at queue depth that is calling for an absurd amount of work.
I am working on an automated rule for adding these overly aggressive requests to IPtables to filter the traffic out.
As of right now, the idles seem to center around long polls, which are hitting the server with over 5,000 getwork requests in a single second due to the miners flushing their queues and grabbing work. At this time, it looks like that will cause idles for some users, and the bottleneck appears to be bitcoind. I am working on a modification to pushpool which will load balance between different bitcoind instances.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
June 03, 2011, 09:42:52 PM |
|
Just putting this out there as a public service announcement:
If you're going to install miners on a school network in Missouri, don't screw up the settings. Sending 101,000 work requests and only returning 91 is not the most efficient way to steal resources from systems funded taxpayers.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
June 03, 2011, 09:43:58 PM |
|
Just putting this out there as a public service announcement:
If you're going to install miners on a school network in Missouri, don't screw up the settings. Sending 101,000 work requests and only returning 91 is not the most efficient way to steal resources from systems funded taxpayers.
Lol, win. |
|
|
|
|
btcboston
Member
Offline
Activity: 101
Merit: 10
|
|
June 03, 2011, 09:45:28 PM |
|
Very nice run for the pool here over the last couple hours. Looks like the luck is finally starting to turn.
|
|
|
|
Veldy
Member
Offline
Activity: 98
Merit: 10
|
|
June 03, 2011, 09:51:15 PM |
|
Just putting this out there as a public service announcement:
If you're going to install miners on a school network in Missouri, don't screw up the settings. Sending 101,000 work requests and only returning 91 is not the most efficient way to steal resources from systems funded taxpayers.
Accidentally DOSd by some kid(s) at a school  Stupid since the school is unlikely to have a significant GPU in any of it's machines, and bound to get caught. |
If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
|
|
|
Veldy
Member
Offline
Activity: 98
Merit: 10
|
|
June 03, 2011, 10:17:55 PM |
|
I am still seeing several idle times, often as long as 20 seconds. Oddly, I saw most of them on only one miner [the only one not on wireless  ]. I have a rock solid wireless network with QoS and WISH setup for allowing port 8332 proper priority. But 20 seconds at a time idled isn't so hot. Most were only a second or two, but several were longer. I didn't mine very long ... just testing the waters before I took a dip again. I have been rock solid elsewhere with ~0.5% stale on all miners and no more than one or two idle timeouts that I logged in 12 hours and they were so short as to be meaningless. Thoughts? I know you have been working on this and good job thus far getting things up and running pretty solidly again. Unfortunately, I don't think your work is quite over yet. |
If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
|
|
|
Genrobo
Newbie
Offline
Activity: 28
Merit: 0
|
|
June 03, 2011, 10:29:25 PM |
|
Just putting this out there as a public service announcement:
If you're going to install miners on a school network in Missouri, don't screw up the settings. Sending 101,000 work requests and only returning 91 is not the most efficient way to steal resources from systems funded taxpayers.
Now, if it wasn't an intentional attack... You may consider leaving them unblocked... But if I was the pool operator, I'd go ahead and ban that IP range. That's just me though.  |
|
|
|
|
Veldy
Member
Offline
Activity: 98
Merit: 10
|
|
June 03, 2011, 10:41:21 PM |
|
Just putting this out there as a public service announcement:
If you're going to install miners on a school network in Missouri, don't screw up the settings. Sending 101,000 work requests and only returning 91 is not the most efficient way to steal resources from systems funded taxpayers.
Now, if it wasn't an intentional attack... You may consider leaving them unblocked... But if I was the pool operator, I'd go ahead and ban that IP range. That's just me though. Slippery slope. Probably better to script getworks to accepted shares [and duration between said getworks and accepted shares] and if the threshold is triggered, fire off an entry in the firewall to ban them ... thus, this scenario where rapid getworks were occurring, but almost no work actually was generated would be avoided after a little bit. Unfortunately, it probably represents large CPU mining pools and it could essentially exclude them]. |
If you have found my post helpful, please donate what you feel it is worth: 18vaZ4K62WiL6W2Qoj9AE1cerfCHRaUW4x
|
|
|
brunoshady
Sr. Member
Offline
Activity: 262
Merit: 250
Dubs Get
|
|
June 03, 2011, 10:59:51 PM |
|
down?
|
😆
|
|
|
russelljohnson
Member
Offline
Activity: 84
Merit: 10
|
|
June 03, 2011, 11:00:09 PM |
|
down?
feels down to me... what's going on... |
If you've found my post helpful, send me some bitcoins!
1FkGxXmesGbhoFewYGrtNEmifzwvNaNCXH
|
|
|
brunoshady
Sr. Member
Offline
Activity: 262
Merit: 250
Dubs Get
|
|
June 03, 2011, 11:10:58 PM |
|
2 miners/workers of the same pool in the same GPU can work better than just one?
|
😆
|
|
|
brunoshady
Sr. Member
Offline
Activity: 262
Merit: 250
Dubs Get
|
|
June 03, 2011, 11:17:28 PM |
|
any chance to delete workers?
=/
|
😆
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
June 03, 2011, 11:28:33 PM |
|
Server is back up, logs were tweaked to automate some of this process. Restarting pushpool involved a fairly long period of idles/connection errors due to the absolute flood of reconnects miners attempted for every milisecond that it was offline apparently (no reconnect delay). Took a while to settle down, but now that it has things are going good.
Some miners -may- have lost their long poll connection, so restarting a miner briefly could fix the issue if you're not seeing any LPs issued.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
russelljohnson
Member
Offline
Activity: 84
Merit: 10
|
|
June 03, 2011, 11:32:49 PM |
|
Server is back up, logs were tweaked to automate some of this process. Restarting pushpool involved a fairly long period of idles/connection errors due to the absolute flood of reconnects miners attempted for every milisecond that it was offline apparently (no reconnect delay). Took a while to settle down, but now that it has things are going good.
Some miners -may- have lost their long poll connection, so restarting a miner briefly could fix the issue if you're not seeing any LPs issued.
thanks eleuthria. everything looking good now. |
If you've found my post helpful, send me some bitcoins!
1FkGxXmesGbhoFewYGrtNEmifzwvNaNCXH
|
|
|
Soros Shorts
Donator
Legendary
Offline
Activity: 1616
Merit: 1003
|
|
June 03, 2011, 11:39:19 PM |
|
My BTC Guild miners did not pick up the following 2 new blocks that were picked up by miners connected to other pools:
03/06/2011 19:10:35, long poll: new block 000002a2a5aaadae
03/06/2011 19:14:59, long poll: new block 00001239399053ae
Time zone is ET. While this was happening the pool was happily accepting a bunch of (possibly stale) work.
Was this just me or did everyone else on BTC Guild miss these 2 blocks?
|
|
|
|
|
|
