[ mining os ] nvoc - page 124. | Bitcointalksearch.org

DJ ACK

newbie

Activity: 13

Merit: 0

Quote from: leenoox on November 30, 2017, 05:01:58 PM

Quote from: DJ ACK on November 30, 2017, 04:39:07 PM

Is anyone having issues with internal network DoS? I have re-imaged my entire farm twice and somehow an attacker is getting in. I am not sure if my IP addy was stolen from one of the BTG mining pools or if there are unpatched security vulnerabilities within the 1.3/1.4 beta builds. A couple other miners running the same build are not having this problem. My farm is isolated to a dedicated router and the DoS only happens on the farm. I can run about 10 hours or less and then the attack hits. I have swapped modems, verified firewall configs on the router and the OS. I have wiresharked at the gateway and was not able to capture anything that stood out. Looking at the PacketStorm website I see a continuous flow of Linux vulnerabilities published every day. How often are security patches pushed for the latest Ubuntu build? I know that DDoS was the main reason for the exchanges to go down yesterday, but that attack vector was different.

My test bench rig running the exact same nvOC build on a separate network is not having this issue at all.

Have you manually applied ubuntu updates?
Have you changed the default password in nvOC?
Is someone running DDoS against your IP or the DDoS is initiated from your rigs against someone else?

I have verified the integrity of the latest nvOC image, changed the default password, enabled UFW and only allowed port 22. ISP has no indications of an external attack or an attack originating from me. I have not applied any Ubuntu updates since the release of 19-1.4 beta. I have a feeling that is the ultimate cause for my issue is that someone is taking advantage of an exploit that I haven't patched yet. I have re-imaged twice now and it keeps occurring. My router firewall logs show "WANATTACK" and IPV4 and IPV6 drops.

DangerD

newbie

Activity: 24

Merit: 0

Quote from: Stubo on November 30, 2017, 11:25:13 AM

Quote from: DangerD on November 30, 2017, 09:51:33 AM

Can somebody please compile ccminer2.2.2 ?
( https://github.com/tpruvot/ccminer )
I need compiled binary... Can't do it because i don't have free space on flash stick...

I compiled it a few weeks back and put it here:

http://www.cstone.net/~stu/nvOC/miners/

Thanks.

Tried to run timetravel (BTX) and got "Illegal instruction" error

Code:

ccminer -a timetravel -o stratum+tcp://btx.suprnova.cc:3629 -u DangerD.Miner1 -p zzz

It was compiled from git of from downloaded release? (From git is needed because latest changes are not in latest release)

leenoox

full member

Activity: 200

Merit: 101

Quote from: DJ ACK on November 30, 2017, 04:39:07 PM

Is anyone having issues with internal network DoS? I have re-imaged my entire farm twice and somehow an attacker is getting in. I am not sure if my IP addy was stolen from one of the BTG mining pools or if there are unpatched security vulnerabilities within the 1.3/1.4 beta builds. A couple other miners running the same build are not having this problem. My farm is isolated to a dedicated router and the DoS only happens on the farm. I can run about 10 hours or less and then the attack hits. I have swapped modems, verified firewall configs on the router and the OS. I have wiresharked at the gateway and was not able to capture anything that stood out. Looking at the PacketStorm website I see a continuous flow of Linux vulnerabilities published every day. How often are security patches pushed for the latest Ubuntu build? I know that DDoS was the main reason for the exchanges to go down yesterday, but that attack vector was different.

My test bench rig running the exact same nvOC build on a separate network is not having this issue at all.

Have you manually applied ubuntu updates?
Have you changed the default password in nvOC?
Is someone running DDoS against your IP or the DDoS is initiated from your rigs against someone else?

DJ ACK

newbie

Activity: 13

Merit: 0

Is anyone having issues with internal network DoS? I have re-imaged my entire farm twice and somehow an attacker is getting in. I am not sure if my IP addy was stolen from one of the BTG mining pools or if there are unpatched security vulnerabilities within the 1.3/1.4 beta builds. A couple other miners running the same build are not having this problem. My farm is isolated to a dedicated router and the DoS only happens on the farm. I can run about 10 hours or less and then the attack hits. I have swapped modems, verified firewall configs on the router and the OS. I have wiresharked at the gateway and was not able to capture anything that stood out. Looking at the PacketStorm website I see a continuous flow of Linux vulnerabilities published every day. How often are security patches pushed for the latest Ubuntu build? I know that DDoS was the main reason for the exchanges to go down yesterday, but that attack vector was different.

My test bench rig running the exact same nvOC build on a separate network is not having this issue at all.

damNmad

full member

Activity: 378

Merit: 104

nvOC forever

Quote from: Stubo on November 30, 2017, 11:25:13 AM

Quote from: DangerD on November 30, 2017, 09:51:33 AM

Can somebody please compile ccminer2.2.2 ?
( https://github.com/tpruvot/ccminer )
I need compiled binary... Can't do it because i don't have free space on flash stick...

I compiled it a few weeks back and put it here:

http://www.cstone.net/~stu/nvOC/miners/

Thanks.

Great collection Stubo Grin

Stubo

member

Activity: 224

Merit: 13

Quote from: DangerD on November 30, 2017, 09:51:33 AM

Can somebody please compile ccminer2.2.2 ?
( https://github.com/tpruvot/ccminer )
I need compiled binary... Can't do it because i don't have free space on flash stick...

I compiled it a few weeks back and put it here:

http://www.cstone.net/~stu/nvOC/miners/

Thanks.

damNmad

full member

Activity: 378

Merit: 104

nvOC forever

Quote from: Alienbert on November 30, 2017, 10:35:50 AM

Quote from: damNmad on November 30, 2017, 10:17:30 AM

Quote from: Alienbert on November 30, 2017, 10:10:02 AM

Hi.

Simple question for you

I want to mine ZEC to a closed pool with PW.
Is this the correct way?: Miner name set CUSTOM than Username.worker:PW

ZEC_WORKER="$WORKERNAME"
# replace_with_your_ZEC_address
ZEC_ADDRESS=""
ZEC_POOL="coinotron.com"
ZEC_PORT="3346"

Do i need zec adress, because the adress is saved on pool.

Is this right?

Thanks

I think coinotron is like suprnova or miningpoolhub.

you need to have an account with them, have a worker on their dashboard and make sure you set password 'z' for that worker! (never used that pool, please correct me if i am wrong).

Quote

ZEC_WORKER="yourCointronWorkerName"
ZEC_ADDRESS="cointronLoginName"

I have checked their help page, if you follow the above, it should work.

Thanks!
I want to try it now! Yes you right. You must have an account.
Why should the PW "z"?

I write again if work or not Grin

UPDATE: WORKS GREAT. THANKS FOR THE HELP Kiss

Well, that password is not that important, you can put anything, its just a worker password, people can't move fund with that password.

I asked you to set it to 'z' because it has been configured as 'z' in 3main or nvOC. You can try with other passwords and test it.

Alienbert

newbie

Activity: 26

Merit: 0

Quote from: damNmad on November 30, 2017, 10:17:30 AM

Quote from: Alienbert on November 30, 2017, 10:10:02 AM

Hi.

Simple question for you

I want to mine ZEC to a closed pool with PW.
Is this the correct way?: Miner name set CUSTOM than Username.worker:PW

ZEC_WORKER="$WORKERNAME"
# replace_with_your_ZEC_address
ZEC_ADDRESS=""
ZEC_POOL="coinotron.com"
ZEC_PORT="3346"

Do i need zec adress, because the adress is saved on pool.

Is this right?

Thanks

I think coinotron is like suprnova or miningpoolhub.

you need to have an account with them, have a worker on their dashboard and make sure you set password 'z' for that worker! (never used that pool, please correct me if i am wrong).

Quote

ZEC_WORKER="yourCointronWorkerName"
ZEC_ADDRESS="cointronLoginName"

I have checked their help page, if you follow the above, it should work.

Thanks!
I want to try it now! Yes you right. You must have an account.
Why should the PW "z"?

I write again if work or not Grin

UPDATE: WORKS GREAT. THANKS FOR THE HELP Kiss

damNmad

full member

Activity: 378

Merit: 104

nvOC forever

Quote from: Alienbert on November 30, 2017, 10:10:02 AM

Hi.

Simple question for you

I want to mine ZEC to a closed pool with PW.
Is this the correct way?: Miner name set CUSTOM than Username.worker:PW

ZEC_WORKER="$WORKERNAME"
# replace_with_your_ZEC_address
ZEC_ADDRESS=""
ZEC_POOL="coinotron.com"
ZEC_PORT="3346"

Do i need zec adress, because the adress is saved on pool.

Is this right?

Thanks

I think coinotron is like suprnova or miningpoolhub.

you need to have an account with them, have a worker on their dashboard and make sure you set password 'z' for that worker! (never used that pool, please correct me if i am wrong).

Quote

ZEC_WORKER="yourCointronWorkerName"
ZEC_ADDRESS="cointronLoginName"

I have checked their help page, if you follow the above, it should work.

damNmad

full member

Activity: 378

Merit: 104

nvOC forever

Quote from: DangerD on November 30, 2017, 09:51:33 AM

Can somebody please compile ccminer2.2.2 ?
( https://github.com/tpruvot/ccminer )
I need compiled binary... Can't do it because i don't have free space on flash stick...

I think i have compiled it very recently, will try to update it to my drive and share.

Alienbert

newbie

Activity: 26

Merit: 0

Hi.

Simple question for you

I want to mine ZEC to a closed pool with PW.
Is this the correct way?: Miner name set CUSTOM than Username.worker:PW

ZEC_WORKER="$WORKERNAME"
# replace_with_your_ZEC_address
ZEC_ADDRESS=""
ZEC_POOL="coinotron.com"
ZEC_PORT="3346"

Do i need zec adress, because the adress is saved on pool.

Is this right?

Thanks

DangerD

newbie

Activity: 24

Merit: 0

Can somebody please compile ccminer2.2.2 ?
( https://github.com/tpruvot/ccminer )
I need compiled binary... Can't do it because i don't have free space on flash stick...

damNmad

full member

Activity: 378

Merit: 104

nvOC forever

Quote from: papampi on November 30, 2017, 02:46:52 AM

Quote from: leenoox on November 30, 2017, 01:46:54 AM

Claymore released version 10.2 for eth/dual miner.
TODO: update miner in next nvOC release

if you want to update to it do a quick search in this thread, it's been posted few times how to update it

Thanks mate,
Will add to unofficial 19-2 update

I think adding new claymore is even more simpler from 1_4 version, we just download the latest version, rename the main folder to 10_2 and add that selection in 1bash

Quote

CLAYMORE_VERSION="10_2" # choose 10_2 or 10_0 or 9_8 or 9_7 or 9_5 or 9_4 or 8_0

this should do i think!

papampi

full member

Activity: 686

Merit: 140

Linux FOREVER! Resistance is futile!!!

Quote from: leenoox on November 30, 2017, 01:46:54 AM

Claymore released version 10.2 for eth/dual miner.
TODO: update miner in next nvOC release

if you want to update to it do a quick search in this thread, it's been posted few times how to update it

Thanks mate,
Added to unofficial 19-2 update

leenoox

full member

Activity: 200

Merit: 101

Claymore released version 10.2 for eth/dual miner.
TODO: update miner in next nvOC release

if you want to update to it do a quick search in this thread, it's been posted few times how to update it

poisonxa

member

Activity: 85

Merit: 10

Guys if you need faster Help getting your Rig up and running Visit us at our Discord Channel : https://discord.gg/8YDFEvY You will get faster response so less downtime on your miner Wink

papampi

full member

Activity: 686

Merit: 140

Linux FOREVER! Resistance is futile!!!

Quote from: Temporel on November 29, 2017, 07:03:54 AM

Quote from: moofone on November 28, 2017, 11:56:57 AM

Completely disagree. This is dangerous way to overclock and could lead to catastrophic failure of your rig if a card dies on its own.. and they do.

Its discussed on the nvidia dev form with some python code that could be adopted to nvOC if anyone is interested:

https://devtalk.nvidia.com/default/topic/769851/multi-nvidia-gpus-and-xorg-conf-how-to-account-for-pci-bus-busid-change-/

Quote from: Bibi187 on November 28, 2017, 11:51:02 AM

Quote from: moofone on November 28, 2017, 11:42:01 AM

Hi Guys,

I discovered a serious and potentially dangerous flaw in the way nvOC handles overclocking and would like to make a suggestion for an improvement.

We really need overclocking tied to the specific pcie slot (bus id) not an index that changes every time your hardware changes.

For example, if you have a gtx1080ti in slot 2, and a gtx1060 in slot 3, and your 1080ti goes offline for some reason or you remove it, the 1080ti overclock is now applied to what it thinks is the next card in the dumb index, and applies it to your gtx1060 potentially going POOF.

Nothing to fix at all oO ...

You modified your RIG, you have to modify setting ...

top posting is disrespectful, wake up kiddo.

👍👍👍👍

Temporel

full member

Activity: 224

Merit: 100

Quote from: moofone on November 28, 2017, 11:56:57 AM

Completely disagree. This is dangerous way to overclock and could lead to catastrophic failure of your rig if a card dies on its own.. and they do.

Its discussed on the nvidia dev form with some python code that could be adopted to nvOC if anyone is interested:

https://devtalk.nvidia.com/default/topic/769851/multi-nvidia-gpus-and-xorg-conf-how-to-account-for-pci-bus-busid-change-/

Quote from: Bibi187 on November 28, 2017, 11:51:02 AM

Quote from: moofone on November 28, 2017, 11:42:01 AM

Hi Guys,

I discovered a serious and potentially dangerous flaw in the way nvOC handles overclocking and would like to make a suggestion for an improvement.

We really need overclocking tied to the specific pcie slot (bus id) not an index that changes every time your hardware changes.

For example, if you have a gtx1080ti in slot 2, and a gtx1060 in slot 3, and your 1080ti goes offline for some reason or you remove it, the 1080ti overclock is now applied to what it thinks is the next card in the dumb index, and applies it to your gtx1060 potentially going POOF.

Nothing to fix at all oO ...

You modified your RIG, you have to modify setting ...

top posting is disrespectful, wake up kiddo.

leenoox

full member

Activity: 200

Merit: 101

Quote from: Stubo on November 28, 2017, 05:20:40 PM

Quote from: leenoox on November 28, 2017, 04:06:31 PM

Quote from: Stubo on November 28, 2017, 11:18:01 AM

Quote from: papampi on November 28, 2017, 11:08:49 AM

There are moments that only 1 GPU wont get fully utilize and keep on going like that, problem with the current wdog on multiple GPUs is that it takes so long for wdog to restart 3 main if only one gpu fails, so on a 12 card rig it takes 72 times and while it checks every 10 seconds it will take more than 10 minutes for it to restart 3main

Any idea how to correct this?

Oh believe me, I have thought about this one, too, and have yet to arrive and what I feel is a good solution. Having the reboot time grow proportionally to #GPU is not ideal, IMO. I am all ears if somebody wants to chime in. The best that I can come up with is an upper limit on count instead of just 6xGPU. There has to be a better way.

The watchdog needs complete overhaul, some of its logic has no logic at all Wink

I had cases when one GPU would hang and pretty much brings the whole rig to a crawl. Its 6x logic (x 13 GPU's for me) caused 3-4 hours of slow ~10% performance before it realized its time to reboot. Quick solution for me was to scratch its logic and change the code to reboot on any detected problem... I'd rather lose 1 minute rebooting than 4 hours of mining at 10%

I will revisit the watchdog soon, see if i can come up with some new logic for it

I was thinking of detecting similar situations by looking for the top process and looking at CPU utilization. However, there is the option of "plusCPU" where the CPU is mining XMR and it is pegged so that must be accounted for. In the scenario you describe above, is there any chance you saw error from the miner - "[Unknown Error]"? I have found that to be the one that turns 10 seconds into 1 minute on one of my rigs while mining with the DSTM ZM miner.

yup, it was "Unknown Error" when some GPU hangs, for me it was turning the 10 second cycle into about 5 minutes Sad

Confirmed by adding debug logging option... lowering the OC reduced those hangs, it still happens once in a while but adding reboot into the loop took care of it (dirty fix)

Stubo

member

Activity: 224

Merit: 13

Quote from: leenoox on November 28, 2017, 04:06:31 PM

Quote from: Stubo on November 28, 2017, 11:18:01 AM

Quote from: papampi on November 28, 2017, 11:08:49 AM

There are moments that only 1 GPU wont get fully utilize and keep on going like that, problem with the current wdog on multiple GPUs is that it takes so long for wdog to restart 3 main if only one gpu fails, so on a 12 card rig it takes 72 times and while it checks every 10 seconds it will take more than 10 minutes for it to restart 3main

Any idea how to correct this?

Oh believe me, I have thought about this one, too, and have yet to arrive and what I feel is a good solution. Having the reboot time grow proportionally to #GPU is not ideal, IMO. I am all ears if somebody wants to chime in. The best that I can come up with is an upper limit on count instead of just 6xGPU. There has to be a better way.

The watchdog needs complete overhaul, some of its logic has no logic at all Wink

I had cases when one GPU would hang and pretty much brings the whole rig to a crawl. Its 6x logic (x 13 GPU's for me) caused 3-4 hours of slow ~10% performance before it realized its time to reboot. Quick solution for me was to scratch its logic and change the code to reboot on any detected problem... I'd rather lose 1 minute rebooting than 4 hours of mining at 10%

I will revisit the watchdog soon, see if i can come up with some new logic for it

I was thinking of detecting similar situations by looking for the top process and looking at CPU utilization. However, there is the option of "plusCPU" where the CPU is mining XMR and it is pegged so that must be accounted for. In the scenario you describe above, is there any chance you saw error from the miner - "[Unknown Error]"? I have found that to be the one that turns 10 seconds into 1 minute on one of my rigs while mining with the DSTM ZM miner.

Topic: [ mining os ] nvoc - page 124. (Read 418542 times)