[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 1066.

molecular

donator

Activity: 2772

Merit: 1019

Quote from: cdhowie on April 27, 2011, 10:04:40 AM

Quote from: molecular on April 27, 2011, 06:33:00 AM

I'm having trouble connecting to mining.bitcoin.cz:80, chrome tells me ""

This has been the case for about 10 hours now, my ip is/was: 85.176.112.67

Weirdly enough, I can connect through tor (using exit 46.19.138.242)

Any explanation?

Can you try a TCP traceroute? I don't know if such a tool is available for Windows, but there is one for Linux. It will essentially do a traceroute with TCP packets by setting the SYN packet's TTL to 1 initially and incrementing it for every packet sent thereafter, in an attempt to discover where the traffic is really going (using the ICMP TTL exceeded errors to determine the path, similar to how regular traceroute works).

This is an effective technique for discovering transparent proxies or other bizarre/evil things done by your ISP or any router between you and the destination.

Thanks for the hint. Unfortunately I can access the web-page again now :|

Veldy

member

Activity: 98

Merit: 10

Quote from: slush on April 28, 2011, 11:32:40 AM

Quote from: Veldy on April 28, 2011, 11:13:31 AM

SYN flooding should be easy for the provider to handle.

...which is also already solved on the server, so this is not an issue.

Your server is still getting hit with the SYN packets ... why not have your ISP stop them and give your server a break [this is the sort of thing that is best blocked by a router, not a production server]. I assume you used IPTABLES on Linux to block syn attacks, but that still leaves your network bandwidth utilized and your CPU (Kernel) dealing with each of these. Your choice, but handling attacks on the server when a router would do a better job [in this case] may prove to be resource expensive as you grow.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: Veldy on April 28, 2011, 11:13:31 AM

SYN flooding should be easy for the provider to handle.

...which is also already solved on the server, so this is not an issue.

Veldy

member

Activity: 98

Merit: 10

Quote from: slush on April 28, 2011, 10:47:32 AM

Quote from: Veldy on April 28, 2011, 09:20:33 AM

My point is that they don't like a DOS attack passing through their network either and will often stop it at their routers. The advantage is that their network is not strained, they have removed the traffic going into your network and taking up your resources and they also [usually] have a better idea how to best stop the attack and not just filter it.

How do they know which traffic is needed and which is not? Currently SYN flooding and similar is solved by pool server itself and the rest of possible attacks are usually application related, so I don't know how Linode can help with this...

SYN flooding should be easy for the provider(s) to handle. Application specific attacks you are correct about; you must make sure they are not vulnerable and then if necessary filter [at the ISP if possible]. If it is just some script kiddie, then a complaint against the source IP pool owner will often put a halt to it. You did mention it was coming from a single block if I remember correctly. This isn't my area of expertise, so I don't have much to offer beyond that.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: Veldy on April 28, 2011, 09:20:33 AM

My point is that they don't like a DOS attack passing through their network either and will often stop it at their routers. The advantage is that their network is not strained, they have removed the traffic going into your network and taking up your resources and they also [usually] have a better idea how to best stop the attack and not just filter it.

How do they know which traffic is needed and which is not? Currently SYN flooding and similar is solved by pool server itself and the rest of possible attacks are usually application related, so I don't know how Linode can help with this...

Veldy

member

Activity: 98

Merit: 10

Quote from: slush on April 28, 2011, 02:21:28 AM

Quote from: Veldy on April 27, 2011, 08:54:36 PM

You have business class hosting through your ISP, right? Can't they get a handle on this for you?

Handle what? IP blacklist? I'm completely OK with managing this blacklist for myself.

To connection problems - I don't think it is problem on the pool side, because it works without problems for two thousands of workers, only two or three people reported some troubles. It definitely looks like problem of their firewalls, routers etc. I once had similar problems with my router box - I had high packet loss, slow roundtrips. Restarting helped. It's common problem of cheap router boxes...

My point is that they don't like a DOS attack passing through their network either and will often stop it at their routers. The advantage is that their network is not strained, they have removed the traffic going into your network and taking up your resources and they also [usually] have a better idea how to best stop the attack and not just filter it.

Just my thoughts.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: Veldy on April 27, 2011, 08:54:36 PM

You have business class hosting through your ISP, right? Can't they get a handle on this for you?

Handle what? IP blacklist? I'm completely OK with managing this blacklist for myself.

To connection problems - I don't think it is problem on the pool side, because it works without problems for two thousands of workers, only two or three people reported some troubles. It definitely looks like problem of their firewalls, routers etc. I once had similar problems with my router box - I had high packet loss, slow roundtrips. Restarting helped. It's common problem of cheap router boxes...

Veldy

member

Activity: 98

Merit: 10

Quote from: slush on April 27, 2011, 03:47:49 AM

Plese send me your IPs to PM. It's possible that they fall into IP blacklist because of server flooding - I'll check it.

You have business class hosting through your ISP, right? Can't they get a handle on this for you?

slush

legendary

Activity: 1386

Merit: 1097

Quote from: ChaosFox on April 27, 2011, 06:13:01 PM

Getting a 502 Bad Gateway error on the main page right now, even though my miners can connect fine. Hmmm.

Was fixed in few minutes. I really have to recompile bitcoind for webserver tomorrow...

ChaosFox

full member

Activity: 178

Merit: 100

Certified fox posing as a cat posing as a human

Getting a 502 Bad Gateway error on the main page right now, even though my miners can connect fine. Hmmm.

marcus_of_augustus

legendary

Activity: 3920

Merit: 2349

Eadem mutata resurgo

Quote from: JackSparrow on April 27, 2011, 05:13:09 PM

Traceroute can do a "TCP traceroute", just add -P TCP -p 80.

For more info use "man traceroute".

actually he needs to do it for port 8332, i.e. miner port
linux command

$sudo traceroute mining.bitcoin.cz -P TCP -p 8332

JackSparrow

member

Activity: 116

Merit: 10

Traceroute can do a "TCP traceroute", just add -P TCP -p 80.

For more info use "man traceroute".

Miner-TE

hero member

Activity: 499

Merit: 500

Traceroute and tracert are ICMP trace route utilities not TCP trace route.

I suggest searching on "TCP traceroute" and find what is available for your OS.

JackSparrow

member

Activity: 116

Merit: 10

Under Linux it is called traceroute and under Windows tracert.

Istead of telling people about SYN-Flags, TTL and TCP you could just link to wikipedia or somewhere.

cdhowie

full member

Activity: 182

Merit: 107

Quote from: molecular on April 27, 2011, 06:33:00 AM

I'm having trouble connecting to mining.bitcoin.cz:80, chrome tells me ""

This has been the case for about 10 hours now, my ip is/was: 85.176.112.67

Weirdly enough, I can connect through tor (using exit 46.19.138.242)

Any explanation?

Can you try a TCP traceroute? I don't know if such a tool is available for Windows, but there is one for Linux. It will essentially do a traceroute with TCP packets by setting the SYN packet's TTL to 1 initially and incrementing it for every packet sent thereafter, in an attempt to discover where the traffic is really going (using the ICMP TTL exceeded errors to determine the path, similar to how regular traceroute works).

This is an effective technique for discovering transparent proxies or other bizarre/evil things done by your ISP or any router between you and the destination.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: molecular on April 27, 2011, 06:33:00 AM

Any explanation?

No, this IP isn't in blacklist and I don't know about any connection troubles on server side...

molecular

donator

Activity: 2772

Merit: 1019

I'm having trouble connecting to mining.bitcoin.cz:80, chrome tells me ""

This has been the case for about 10 hours now, my ip is/was: 85.176.112.67

Weirdly enough, I can connect through tor (using exit 46.19.138.242)

Any explanation?

slush

legendary

Activity: 1386

Merit: 1097

Quote from: molecular on April 27, 2011, 05:47:13 AM

Maybe slush recently made a change to not allow connections to worker account if one is already "connected"?

No, more miners using same worker account should not lead to connection troubles...

molecular

donator

Activity: 2772

Merit: 1019

Quote from: ghost on April 26, 2011, 07:30:05 PM

I'm having trouble connecting with more then 1 worker. I have four instances using the same worker on one computer - they are all working fine. A worker on a different computer won't connect. If I turn off the other worker it will.

This just started last night.

Last I checked you had to create a worker account for each worker.

Maybe slush recently made a change to not allow connections to worker account if one is already "connected"?

slush

legendary

Activity: 1386

Merit: 1097

Plese send me your IPs to PM. It's possible that they fall into IP blacklist because of server flooding - I'll check it.

Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 1066. (Read 4382653 times)