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

[slush]

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...

[1714205259]

1714205259

[1714205259]

1714205259

[molecular]

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]

Any explanation?

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

[cdhowie]

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.

[JackSparrow]

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.

[Miner-TE]

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]

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

For more info use "man traceroute".

[marcus_of_augustus]

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

[ChaosFox]

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

[slush]

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...

[Veldy]

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]

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]

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]

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]

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]

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]

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.

[molecular]

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 :|

[molecular]

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

actually no, I need port 80. the webpage didn't work (problem resolved itself somehow), I could, however, mine fine.

[Veldy]

502 error yet again today.