 Show Posts
|
|
Pages: [1] 2 »
|
ethminer API timing out, but only on remote agent connectionsI have hundreds of messages like this on the remote agent log per day on my miners(which eventually lead to false positive offline detection): 2020/11/01 6:51:23.796 [016] [E]Failed to process API request (localhost, time: 13006 ms): {"id":0,"jsonrpc":"2.0","method":"miner_getstatdetail"}
Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.48 hours ago I started running a script I made that reads the API on localhost every 5 seconds on every miner, I also ran the script 3 times on my machine with each instance pointing to the IP of each miner, the script instances never failed to connect and always took just a few milliseconds everywhere(only once in the 48 hours from my machine one instance took around one second to respond but responded correctly). I made this test with firewall disabled and freshly restarted miners. I tried setting the priority of the remote agent process to high, I don't think it made a difference. This is happening with ethminer 0.17.1 (chosen via awesome miner) and ethminer-0.19.0-7+commit.66186f1b (manually uploaded via awesome miner custom software). Although it seems to happen more on the updated version. I'm not using 0.18.0 (chosen via awesome miner) as it that version of ethminer has a bug that prevents the api from responding. I'm using the later version mainly because 0.17.1 won't show any data while mining, I believe the only data missing when using the later version is the individual progress details for each gpu. Any suggestion on what else I could try? thanks Thanks for the detailed description and for your analysis. So at the same time Remote Agent get a timeout after 13 seconds, your tool connecting to the same EthMiner API is receiving a response without any problems? Do you see a timeout error like this and then it works fine for a while and then another timeout and so on? I will have to look into this a bit more because I cannot see any obvious reason why Remote Agent would timeout if the API is in fact working. For the API data processing, I can make a few adjustments to make sure it parses the API response correctly once received. Correct, my tool never failed to get the API data quickly, I'm using the same command I saw on the logs(miner_getstatdetail) Update: I installed the latest updates for windows 1909 on windows update(security, servicing stack, cumulative and a .net 3.5 update but not edge), after about 10 hours the timeouts seem to be less common, one machine had 0, other 12 and other 16(6 consecutive timeouts once which triggered the offline detection that is set to 60 seconds now). The API was fully responsive all the time on all miners when requesting information from my computer with my tool (every 5 seconds never taking more than a few milliseconds). I'll reformat one miner with latest windows to test when I can. Thanks for the update. If you look at the Windows Defender advanced settings, where all applications are listed - are there any difference between Awesome Miner and your tool? For example the Profile (Private, Public)? I did the tests with firewall disabled but I normally have it set to not notify and not block all, so there are no extra rules. I only have the inbound rule for AwesomeMinerService (9630) which is private(as my network type). My tool (made in PHP and run locally via cli) doesn't listen on any port. The updated 8.1.6 made awesome miner show more info for 0.17.1 but shows nothing for 0.19 (ethminer-0.19.0-7+commit.66186f1b). It seems those 2 versions APIs have different fields in the response. I haven't had any timeouts with 8.1.6 and 0.17.1 in a while so I'll just use that for now, thanks. |
|
|
|
ethminer API timing out, but only on remote agent connectionsI have hundreds of messages like this on the remote agent log per day on my miners(which eventually lead to false positive offline detection): 2020/11/01 6:51:23.796 [016] [E]Failed to process API request (localhost, time: 13006 ms): {"id":0,"jsonrpc":"2.0","method":"miner_getstatdetail"}
Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.48 hours ago I started running a script I made that reads the API on localhost every 5 seconds on every miner, I also ran the script 3 times on my machine with each instance pointing to the IP of each miner, the script instances never failed to connect and always took just a few milliseconds everywhere(only once in the 48 hours from my machine one instance took around one second to respond but responded correctly). I made this test with firewall disabled and freshly restarted miners. I tried setting the priority of the remote agent process to high, I don't think it made a difference. This is happening with ethminer 0.17.1 (chosen via awesome miner) and ethminer-0.19.0-7+commit.66186f1b (manually uploaded via awesome miner custom software). Although it seems to happen more on the updated version. I'm not using 0.18.0 (chosen via awesome miner) as it that version of ethminer has a bug that prevents the api from responding. I'm using the later version mainly because 0.17.1 won't show any data while mining, I believe the only data missing when using the later version is the individual progress details for each gpu. Any suggestion on what else I could try? thanks Thanks for the detailed description and for your analysis. So at the same time Remote Agent get a timeout after 13 seconds, your tool connecting to the same EthMiner API is receiving a response without any problems? Do you see a timeout error like this and then it works fine for a while and then another timeout and so on? I will have to look into this a bit more because I cannot see any obvious reason why Remote Agent would timeout if the API is in fact working. For the API data processing, I can make a few adjustments to make sure it parses the API response correctly once received. Correct, my tool never failed to get the API data quickly, I'm using the same command I saw on the logs(miner_getstatdetail) Update: I installed the latest updates for windows 1909 on windows update(security, servicing stack, cumulative and a .net 3.5 update but not edge), after about 10 hours the timeouts seem to be less common, one machine had 0, other 12 and other 16(6 consecutive timeouts once which triggered the offline detection that is set to 60 seconds now). The API was fully responsive all the time on all miners when requesting information from my computer with my tool (every 5 seconds never taking more than a few milliseconds). I'll reformat one miner with latest windows to test when I can. |
|
|
|
ethminer API timing out, but only on remote agent connectionsI have hundreds of messages like this on the remote agent log per day on my miners(which eventually lead to false positive offline detection): 2020/11/01 6:51:23.796 [016] [E]Failed to process API request (localhost, time: 13006 ms): {"id":0,"jsonrpc":"2.0","method":"miner_getstatdetail"}
Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.48 hours ago I started running a script I made that reads the API on localhost every 5 seconds on every miner, I also ran the script 3 times on my machine with each instance pointing to the IP of each miner, the script instances never failed to connect and always took just a few milliseconds everywhere(only once in the 48 hours from my machine one instance took around one second to respond but responded correctly). I made this test with firewall disabled and freshly restarted miners. I tried setting the priority of the remote agent process to high, I don't think it made a difference. This is happening with ethminer 0.17.1 (chosen via awesome miner) and ethminer-0.19.0-7+commit.66186f1b (manually uploaded via awesome miner custom software). Although it seems to happen more on the updated version. I'm not using 0.18.0 (chosen via awesome miner) as it that version of ethminer has a bug that prevents the api from responding. I'm using the later version mainly because 0.17.1 won't show any data while mining, I believe the only data missing when using the later version is the individual progress details for each gpu. Any suggestion on what else I could try? thanks
|
|
|
|
So I was finally able to catch and collect data on the miners stopping issue I had before. Both miners are managed profit miners. The "offline detection" emails were sent at around 11:16:20 (as expected/configured). The status on the awesome miner manager was "Stopped" (at around 14:40). There wasn't any miner software running when I VNCed to the miner (at around 14:40). The miners can mine Equihash 150,5 correctly most of the time(with gminer). If I'm reading the logs correctly I think awesome miner used bminer but it is configured to use gminer for Equihash 150,5. I tested setting it to bminer for Equihash 150,5, screenshot below. I replaced my bitcoin addresses for "xxx" on the logs. I replaced repeated "nVidia driver version" entries for "..." on the logs. On the screenshots Z270XP1 uses profit profile 1070-1, Z270XP3 uses profit profile 1070-3 screenshots: https://imgur.com/a/zr85dwblogs: https://pastebin.com/Lzxh4T2Yhttps://pastebin.com/AXpRk6mmI understand the miner software tried to restart 3 times (as configured), I'm not sure what failed but I think awesome miner should just keep going, jump to the next algorithm(retry again x times if needed) or something like that. Is there any reason bminer was used for Equihash 150,5 when gminer is configured? or maybe I'm misreading the logs? Thanks |
|
|
|
My managed profit miners are going "offline" now and then, this seem to happen when pools fail (seen it on nicehash and zpool so far, with bminer, gminer and z-enemy). Even that the miner is flagged as offline, it is still connected to awesome miner manager and I can just start it again. Is there a way to force the miner to not stop/go to the next pool/algo, or any ideas on how should I troubleshoot this?
On options->Profit switching I have this:
Ignore pools with no accepted shares in minutes: checked 6
Ignore minutes: 50
Ignore pools after too many failed miner restart attemps: checked
Thanks
Is the scenario that once you run into this problem, even after > 6 minutes, Awesome Miner has still not marked the pool as failed and moved on to the next pool? It just keeps running the same mining software that is unable to do its work - while it display "Interface offline"? I usually can't remote to the computers very fast so when I remote to them they are just not doing anything, I can confirm the "Interface offline" only for Equihash 150.5+NiceHash+Gminer CUDA Equihash Miner (it happens more often, I'm not 100% sure about the others). Edit: If I go to right click->view details (even after a few hours) I have several timestamps (as if the mining didn't stop) and when I click the timestamp after the error (i.e. 12 minutes after the error), it shows the message that some pool is being ignored and the button to reset. If I click a more recent timestamp there isn't any ignored pool message. Thanks for the update. The fact that you do see the "Failed" for some pool in the View Details dialog indicates that Awesome Miner did detect this pool failure. The profit switcher will then not use this pool for a while, but the profit switching decision might be made a number of minutes later, depending on how often the profit switcher is configured to run. Right now you have an ignore time of only 50 minutes, so Awesome Miner will start using the pool a while later and this is why you no longer see the "Failed" indicator. If the pool fails again a little later, Awesome Miner will again mark it as failed and ignore it. The idea is that Awesome Miner shouldn't be stuck on a failed pool for many hours or days, but a number of minutes of mining will always be lost before Awesome Miner will consider it to be a failure. For this reason it can be good to ignore the pool for a longer period of time after a failure. If the specific combination for Eq150,5 + Nicehash + Gminer causes these issues frequently, it could be time to consider if this combination should be removed from the profit switcher. Sorry I wasn't clear, the miners stop working until I manually start them, the other day I went to sleep and it failed after 1-2 hours, I received the offline email but it didn't wake me up(that's ok). Another day the same thing happened, I didn't see/check my email until noon, miners were idle for around 11 hours until I started them. I just wanted to know if there was a way to troubleshoot this because it started happening with more than 1 algo/pool/software. It doesn't happen that often but I'd rather it kept mining by itself. When you find the miners in this start, they are showing as "Interface offline" as you pointed out earlier? Not "Service Offline"? And when you look at the miner console window, the mining software is running but do nothing because of pool connection failure? The Offline e-mail you received, was it from the Offline Detection rule? Sorry for asking all these questions, I'm just trying to get as detailed understanding as possible of the scenario. I remember the message being "Interface offline" but now I'm not so sure because I found a screenshot with the miners just saying "Stopped" in red. I rarely use the console window, I just vnc to the miner and see there isn't any console/mining software running, so I start the miner again. Yes, the email is from the offline detection rules. I understand the info I'm giving is probably not good enough, I'll be sure to document it better the next time this happens. Thanks |
|
|
|
My managed profit miners are going "offline" now and then, this seem to happen when pools fail (seen it on nicehash and zpool so far, with bminer, gminer and z-enemy). Even that the miner is flagged as offline, it is still connected to awesome miner manager and I can just start it again. Is there a way to force the miner to not stop/go to the next pool/algo, or any ideas on how should I troubleshoot this?
On options->Profit switching I have this:
Ignore pools with no accepted shares in minutes: checked 6
Ignore minutes: 50
Ignore pools after too many failed miner restart attemps: checked
Thanks
Is the scenario that once you run into this problem, even after > 6 minutes, Awesome Miner has still not marked the pool as failed and moved on to the next pool? It just keeps running the same mining software that is unable to do its work - while it display "Interface offline"? I usually can't remote to the computers very fast so when I remote to them they are just not doing anything, I can confirm the "Interface offline" only for Equihash 150.5+NiceHash+Gminer CUDA Equihash Miner (it happens more often, I'm not 100% sure about the others). Edit: If I go to right click->view details (even after a few hours) I have several timestamps (as if the mining didn't stop) and when I click the timestamp after the error (i.e. 12 minutes after the error), it shows the message that some pool is being ignored and the button to reset. If I click a more recent timestamp there isn't any ignored pool message. Thanks for the update. The fact that you do see the "Failed" for some pool in the View Details dialog indicates that Awesome Miner did detect this pool failure. The profit switcher will then not use this pool for a while, but the profit switching decision might be made a number of minutes later, depending on how often the profit switcher is configured to run. Right now you have an ignore time of only 50 minutes, so Awesome Miner will start using the pool a while later and this is why you no longer see the "Failed" indicator. If the pool fails again a little later, Awesome Miner will again mark it as failed and ignore it. The idea is that Awesome Miner shouldn't be stuck on a failed pool for many hours or days, but a number of minutes of mining will always be lost before Awesome Miner will consider it to be a failure. For this reason it can be good to ignore the pool for a longer period of time after a failure. If the specific combination for Eq150,5 + Nicehash + Gminer causes these issues frequently, it could be time to consider if this combination should be removed from the profit switcher. Sorry I wasn't clear, the miners stop working until I manually start them, the other day I went to sleep and it failed after 1-2 hours, I received the offline email but it didn't wake me up(that's ok). Another day the same thing happened, I didn't see/check my email until noon, miners were idle for around 11 hours until I started them. I just wanted to know if there was a way to troubleshoot this because it started happening with more than 1 algo/pool/software. It doesn't happen that often but I'd rather it kept mining by itself. |
|
|
|
My managed profit miners are going "offline" now and then, this seem to happen when pools fail (seen it on nicehash and zpool so far, with bminer, gminer and z-enemy). Even that the miner is flagged as offline, it is still connected to awesome miner manager and I can just start it again. Is there a way to force the miner to not stop/go to the next pool/algo, or any ideas on how should I troubleshoot this?
On options->Profit switching I have this:
Ignore pools with no accepted shares in minutes: checked 6
Ignore minutes: 50
Ignore pools after too many failed miner restart attemps: checked
Thanks
Is the scenario that once you run into this problem, even after > 6 minutes, Awesome Miner has still not marked the pool as failed and moved on to the next pool? It just keeps running the same mining software that is unable to do its work - while it display "Interface offline"? I usually can't remote to the computers very fast so when I remote to them they are just not doing anything, I can confirm the "Interface offline" only for Equihash 150.5+NiceHash+Gminer CUDA Equihash Miner (it happens more often, I'm not 100% sure about the others). Edit: If I go to right click->view details (even after a few hours) I have several timestamps (as if the mining didn't stop) and when I click the timestamp after the error (i.e. 12 minutes after the error), it shows the message that some pool is being ignored and the button to reset. If I click a more recent timestamp there isn't any ignored pool message. |
|
|
|
|
My managed profit miners are going "offline" now and then, this seem to happen when pools fail (seen it on nicehash and zpool so far, with bminer, gminer and z-enemy). Even that the miner is flagged as offline, it is still connected to awesome miner manager and I can just start it again. Is there a way to force the miner to not stop/go to the next pool/algo, or any ideas on how should I troubleshoot this?
On options->Profit switching I have this:
Ignore pools with no accepted shares in minutes: checked 6
Ignore minutes: 50
Ignore pools after too many failed miner restart attemps: checked
Thanks
|
|
|
|
Block all incoming connections takes precedence over any other rule. I manually changed the allow rules created by awesome miner for the mining software to block rules. Have been mining since I originally asked about this without any issue or popup (picture of my rules linked). The problem is that when new software is added/updated new rules will be created by awesome miner as allowed rules. https://imgur.com/a/w7YBXdZIf you make this an option you could just leave the default as it is now(allowed rules), just in case "blocked" rules might break anything for someone. Thanks for the update. I've made a quick implementation to support this case. I've introduced a new setting that you can set directly in the Awesome Miner configuration file as I don't want to expose this in the user interface. 1) Once the next version of Awesome Miner is available, install it, run it once and then exit the application. 2) Open the configuration file (%appdata%\AwesomeMiner\ConfigData.xml) and search for "ConfigureWindowsDefenderAllowedApps". 3) Change the property from true to false and save the file. Thanks, I tried but it showed a popup the first time a mining software ran. While testing further I found out 2 possible reasons why: 1 When creating a block rule the rule is created with Profile Private(current profile), while when creating an allow rule the rule is created with Profile All. 2 When creating a block rule the rule is added to the registry a couple of seconds after the miner software is launched, while when creating an allow rule the rule is added to the registry a few milliseconds before the miner software is launched. I didn't test extensively but I'm guessing #1 has something to do with defaults, for #2 my guess is some firewall api limitation or maybe it is not the cause of the issue. Hopefully you can take another look at it, otherwise I'll just create a script that runs now and then and modifies the rules as needed. Even that my lan is relatively secure and have trustworthy people connecting to it, I don't want to leave my mining software open. Thanks again. The default behavior of Awesome Miner is to add this Allowed Apps rule. In that case things should just work and you shouldn't see any dialogs from Windows Defender. Is that correct according to your observations as well? I don't have any plans to change how these rules are set at the moment, as what Awesome Miner do works very well in a very large number of mining environments out there. If you use the new property set to false, Awesome Miner will not do anything with the firewall configuration. I assume it's in only in this case you are getting the warnings from Defender? With the automatic configuration disabled in Awesome Miner, you are basically on your own here and you can manually configure (or not configure) the rules as you want. I'm feeling that I'm failing to communicate what I want to say a lot, sorry about that and thank you for your patience. Maybe you make me nervous  I meant that when configuring ConfigureWindowsDefenderAllowedApps as true the rules (allow rules) are being created with Profile=All, but when configuring ConfigureWindowsDefenderAllowedApps as false the rules(block rules) are being created with Profile=Private, I believe the difference in profile causes the popups to come up when ConfigureWindowsDefenderAllowedApps is set to false. Thanks for the update. Your observations when running with ConfigureWindowsDefenderAllowedApps set to false are probably what to expect, as it's totally up to Windows to decide when to block, when to show the dialog and what rule to add in that case. Awesome Miner will do nothing, which is the purpose of setting the property to false. Although I understand your observations here, I don't fully understand what you want Awesome Miner to do here. It can already do: 1) Add allowed apps automatically. This is the default, has been around for years and works fine for the purpose of mining. 2) The new mode when ConfigureWindowsDefenderAllowedApps set to false will result in Awesome Miner doing nothing. You are on your own to do what you want here. Any dialogs, blocking and so on you see is related to configuration of Windows and not Awesome Miner. There are no feature in Awesome Miner to configure the allowed apps in any new way - either it's configured in a way that work (#1) or it's not touching anything (#2). Sorry if I missed your point here. ConfigureWindowsDefenderExclusions defines whether firewall rules are created by awesome miner or not. ConfigureWindowsDefenderAllowedApps(the one you added recently) defines whether the rules are created by awesome miner as allow rules(true) or block rules(false). When ConfigureWindowsDefenderAllowedApps is set to true(default) the created rules are being created by awesome miner with Profile=All, when it is set to false the rules are being created by awesome miner with Profile=Private. I'd like the rules to be created with Profile=All regardless of ConfigureWindowsDefenderAllowedApps being true or false. I believe having Profile=All on the block rules(when ConfigureWindowsDefenderAllowedApps is set to false) might prevent popups to come up. ConfigureWindowsDefenderExclusions is only for addings paths as exclusions to the anti-virus scan and that feature is always on by default. Otherwise Windows Defender will start removing all mining software it considers a thread. "When ConfigureWindowsDefenderAllowedApps is set to true(default) the created rules are being created by awesome miner with Profile=All"Correct assumption. In this case Awesome Miner makes a configuration that is proven to work well with mining " when it is set to false the rules are being created by awesome miner with Profile=Private." Not correct assumption. Awesome Miner do nothing to the Allowed Apps here. It will not touch the rules at all when this property is set to False. The behavior you experience is what Windows is doing when Awesome Miner no longer takes responsibility for configuring Defender for you. Any rules added at this point is what Windows is doing. This was the point I was trying to make above that when you tell Awesome Miner to not setup the Allowed Apps for you, you will be on your own and you will most likely run into issues with Defender unless you manually find a way to setup everything. I'm have to admit that I'm not really an expert on all these Defender settings and the exact behaviors of when Windows is adding these rules automatically. If I knew more of the details, I would of course want to help out more with suggestions how to make these configurations. This is the reason why my answers above is based on everything from an Awesome Miner and mining point of view. You are right, having ConfigureWindowsDefenderExclusions=true and ConfigureWindowsDefenderAllowedApps=false made windows auto create the block rules with Profile=Private. I misunderstood what ConfigureWindowsDefenderAllowedApps=false would do. Manually changing the allow rules created by awesome miner to block rules worked fine for me (as shown on the picture), so I will just let awesome miner create the default rules and run an extra script every minute or so to change them from allow to block rules. Thanks. |
|
|
|
Block all incoming connections takes precedence over any other rule. I manually changed the allow rules created by awesome miner for the mining software to block rules. Have been mining since I originally asked about this without any issue or popup (picture of my rules linked). The problem is that when new software is added/updated new rules will be created by awesome miner as allowed rules. https://imgur.com/a/w7YBXdZIf you make this an option you could just leave the default as it is now(allowed rules), just in case "blocked" rules might break anything for someone. Thanks for the update. I've made a quick implementation to support this case. I've introduced a new setting that you can set directly in the Awesome Miner configuration file as I don't want to expose this in the user interface. 1) Once the next version of Awesome Miner is available, install it, run it once and then exit the application. 2) Open the configuration file (%appdata%\AwesomeMiner\ConfigData.xml) and search for "ConfigureWindowsDefenderAllowedApps". 3) Change the property from true to false and save the file. Thanks, I tried but it showed a popup the first time a mining software ran. While testing further I found out 2 possible reasons why: 1 When creating a block rule the rule is created with Profile Private(current profile), while when creating an allow rule the rule is created with Profile All. 2 When creating a block rule the rule is added to the registry a couple of seconds after the miner software is launched, while when creating an allow rule the rule is added to the registry a few milliseconds before the miner software is launched. I didn't test extensively but I'm guessing #1 has something to do with defaults, for #2 my guess is some firewall api limitation or maybe it is not the cause of the issue. Hopefully you can take another look at it, otherwise I'll just create a script that runs now and then and modifies the rules as needed. Even that my lan is relatively secure and have trustworthy people connecting to it, I don't want to leave my mining software open. Thanks again. The default behavior of Awesome Miner is to add this Allowed Apps rule. In that case things should just work and you shouldn't see any dialogs from Windows Defender. Is that correct according to your observations as well? I don't have any plans to change how these rules are set at the moment, as what Awesome Miner do works very well in a very large number of mining environments out there. If you use the new property set to false, Awesome Miner will not do anything with the firewall configuration. I assume it's in only in this case you are getting the warnings from Defender? With the automatic configuration disabled in Awesome Miner, you are basically on your own here and you can manually configure (or not configure) the rules as you want. I'm feeling that I'm failing to communicate what I want to say a lot, sorry about that and thank you for your patience. Maybe you make me nervous I meant that when configuring ConfigureWindowsDefenderAllowedApps as true the rules (allow rules) are being created with Profile=All, but when configuring ConfigureWindowsDefenderAllowedApps as false the rules(block rules) are being created with Profile=Private, I believe the difference in profile causes the popups to come up when ConfigureWindowsDefenderAllowedApps is set to false. Thanks for the update. Your observations when running with ConfigureWindowsDefenderAllowedApps set to false are probably what to expect, as it's totally up to Windows to decide when to block, when to show the dialog and what rule to add in that case. Awesome Miner will do nothing, which is the purpose of setting the property to false. Although I understand your observations here, I don't fully understand what you want Awesome Miner to do here. It can already do: 1) Add allowed apps automatically. This is the default, has been around for years and works fine for the purpose of mining. 2) The new mode when ConfigureWindowsDefenderAllowedApps set to false will result in Awesome Miner doing nothing. You are on your own to do what you want here. Any dialogs, blocking and so on you see is related to configuration of Windows and not Awesome Miner. There are no feature in Awesome Miner to configure the allowed apps in any new way - either it's configured in a way that work (#1) or it's not touching anything (#2). Sorry if I missed your point here. ConfigureWindowsDefenderExclusions defines whether firewall rules are created by awesome miner or not. ConfigureWindowsDefenderAllowedApps(the one you added recently) defines whether the rules are created by awesome miner as allow rules(true) or block rules(false). When ConfigureWindowsDefenderAllowedApps is set to true(default) the created rules are being created by awesome miner with Profile=All, when it is set to false the rules are being created by awesome miner with Profile=Private. I'd like the rules to be created with Profile=All regardless of ConfigureWindowsDefenderAllowedApps being true or false. I believe having Profile=All on the block rules(when ConfigureWindowsDefenderAllowedApps is set to false) might prevent popups to come up. |
|
|
|
Any way to stop awesome miner from creating firewall rules for every mining software?
I don't want everyone on my LAN to have access to the mining software on my miners.
Local connections usually work even if you don't allow the program, is there any particular reason for awesome miner to create firewall rules?
There are currently no setting to prevent this behavior in Awesome Miner. Awesome Miner is registering the mining software as an allowed application. Mining software must be able to make outgoing pool connections and also open an API port where Awesome Miner connects for monitoring information. If an application isn't registered to the Windows firewall it may be blocked and Windows almost always shows a dialog where the user must accept the application. If you try to start almost any mining software outside of Awesome Miner (a software that Awesome Miner didn't register already) you will see that Windows Defender Firewall will show a warning dialog - unless Defender is completely disabled. In Windows Defender Firewall you also have a setting called "Block all incoming connections, including those in the list of allowed apps". That might be the one you are looking for in your specific scenario. As for the inbound rules, I understand is good to have them to prevent the popups but there is no need to have them as "allow the connection" rules, because the monitoring connections are local we could have them as "block the connection" rules and the monitoring would still work correctly(as far as I have tested over the years) without allowing other LAN devices access to the mining software. The "Block all incoming connections, including those in the list of allowed apps" might seem enough for most use cases but I have mining computers that serve other content so I need access to some of their ports. Please consider adding an option so we can decide whether to create the rules as allow or block rules, thank you. Can this be solved by using the setting to block all incoming connections, but then explicitly configure Windows Defender to open up a few ports that you need? Even if you only monitor mining software locally, Windows will still complain and show the Blocked dialog when you launch the mining software unless it's an allowed application. This is the reason why Awesome Miner adds the mining software as allowed as it's very difficult to run mining operations without it. Block all incoming connections takes precedence over any other rule. I manually changed the allow rules created by awesome miner for the mining software to block rules. Have been mining since I originally asked about this without any issue or popup (picture of my rules linked). The problem is that when new software is added/updated new rules will be created by awesome miner as allowed rules. https://imgur.com/a/w7YBXdZIf you make this an option you could just leave the default as it is now(allowed rules), just in case "blocked" rules might break anything for someone. Thanks for the update. I've made a quick implementation to support this case. I've introduced a new setting that you can set directly in the Awesome Miner configuration file as I don't want to expose this in the user interface. 1) Once the next version of Awesome Miner is available, install it, run it once and then exit the application. 2) Open the configuration file (%appdata%\AwesomeMiner\ConfigData.xml) and search for "ConfigureWindowsDefenderAllowedApps". 3) Change the property from true to false and save the file. Thanks, I tried but it showed a popup the first time a mining software ran. While testing further I found out 2 possible reasons why: 1 When creating a block rule the rule is created with Profile Private(current profile), while when creating an allow rule the rule is created with Profile All. 2 When creating a block rule the rule is added to the registry a couple of seconds after the miner software is launched, while when creating an allow rule the rule is added to the registry a few milliseconds before the miner software is launched. I didn't test extensively but I'm guessing #1 has something to do with defaults, for #2 my guess is some firewall api limitation or maybe it is not the cause of the issue. Hopefully you can take another look at it, otherwise I'll just create a script that runs now and then and modifies the rules as needed. Even that my lan is relatively secure and have trustworthy people connecting to it, I don't want to leave my mining software open. Thanks again. The default behavior of Awesome Miner is to add this Allowed Apps rule. In that case things should just work and you shouldn't see any dialogs from Windows Defender. Is that correct according to your observations as well? I don't have any plans to change how these rules are set at the moment, as what Awesome Miner do works very well in a very large number of mining environments out there. If you use the new property set to false, Awesome Miner will not do anything with the firewall configuration. I assume it's in only in this case you are getting the warnings from Defender? With the automatic configuration disabled in Awesome Miner, you are basically on your own here and you can manually configure (or not configure) the rules as you want. I'm feeling that I'm failing to communicate what I want to say a lot, sorry about that and thank you for your patience. Maybe you make me nervous I meant that when configuring ConfigureWindowsDefenderAllowedApps as true the rules (allow rules) are being created with Profile=All, but when configuring ConfigureWindowsDefenderAllowedApps as false the rules(block rules) are being created with Profile=Private, I believe the difference in profile causes the popups to come up when ConfigureWindowsDefenderAllowedApps is set to false. |
|
|
|
Any way to stop awesome miner from creating firewall rules for every mining software?
I don't want everyone on my LAN to have access to the mining software on my miners.
Local connections usually work even if you don't allow the program, is there any particular reason for awesome miner to create firewall rules?
There are currently no setting to prevent this behavior in Awesome Miner. Awesome Miner is registering the mining software as an allowed application. Mining software must be able to make outgoing pool connections and also open an API port where Awesome Miner connects for monitoring information. If an application isn't registered to the Windows firewall it may be blocked and Windows almost always shows a dialog where the user must accept the application. If you try to start almost any mining software outside of Awesome Miner (a software that Awesome Miner didn't register already) you will see that Windows Defender Firewall will show a warning dialog - unless Defender is completely disabled. In Windows Defender Firewall you also have a setting called "Block all incoming connections, including those in the list of allowed apps". That might be the one you are looking for in your specific scenario. As for the inbound rules, I understand is good to have them to prevent the popups but there is no need to have them as "allow the connection" rules, because the monitoring connections are local we could have them as "block the connection" rules and the monitoring would still work correctly(as far as I have tested over the years) without allowing other LAN devices access to the mining software. The "Block all incoming connections, including those in the list of allowed apps" might seem enough for most use cases but I have mining computers that serve other content so I need access to some of their ports. Please consider adding an option so we can decide whether to create the rules as allow or block rules, thank you. Can this be solved by using the setting to block all incoming connections, but then explicitly configure Windows Defender to open up a few ports that you need? Even if you only monitor mining software locally, Windows will still complain and show the Blocked dialog when you launch the mining software unless it's an allowed application. This is the reason why Awesome Miner adds the mining software as allowed as it's very difficult to run mining operations without it. Block all incoming connections takes precedence over any other rule. I manually changed the allow rules created by awesome miner for the mining software to block rules. Have been mining since I originally asked about this without any issue or popup (picture of my rules linked). The problem is that when new software is added/updated new rules will be created by awesome miner as allowed rules. https://imgur.com/a/w7YBXdZIf you make this an option you could just leave the default as it is now(allowed rules), just in case "blocked" rules might break anything for someone. Thanks for the update. I've made a quick implementation to support this case. I've introduced a new setting that you can set directly in the Awesome Miner configuration file as I don't want to expose this in the user interface. 1) Once the next version of Awesome Miner is available, install it, run it once and then exit the application. 2) Open the configuration file (%appdata%\AwesomeMiner\ConfigData.xml) and search for "ConfigureWindowsDefenderAllowedApps". 3) Change the property from true to false and save the file. Thanks, I tried but it showed a popup the first time a mining software ran. While testing further I found out 2 possible reasons why: 1 When creating a block rule the rule is created with Profile Private(current profile), while when creating an allow rule the rule is created with Profile All. 2 When creating a block rule the rule is added to the registry a couple of seconds after the miner software is launched, while when creating an allow rule the rule is added to the registry a few milliseconds before the miner software is launched. I didn't test extensively but I'm guessing #1 has something to do with defaults, for #2 my guess is some firewall api limitation or maybe it is not the cause of the issue. Hopefully you can take another look at it, otherwise I'll just create a script that runs now and then and modifies the rules as needed. Even that my lan is relatively secure and have trustworthy people connecting to it, I don't want to leave my mining software open. Thanks again. |
|
|
|
Any way to stop awesome miner from creating firewall rules for every mining software?
I don't want everyone on my LAN to have access to the mining software on my miners.
Local connections usually work even if you don't allow the program, is there any particular reason for awesome miner to create firewall rules?
There are currently no setting to prevent this behavior in Awesome Miner. Awesome Miner is registering the mining software as an allowed application. Mining software must be able to make outgoing pool connections and also open an API port where Awesome Miner connects for monitoring information. If an application isn't registered to the Windows firewall it may be blocked and Windows almost always shows a dialog where the user must accept the application. If you try to start almost any mining software outside of Awesome Miner (a software that Awesome Miner didn't register already) you will see that Windows Defender Firewall will show a warning dialog - unless Defender is completely disabled. In Windows Defender Firewall you also have a setting called "Block all incoming connections, including those in the list of allowed apps". That might be the one you are looking for in your specific scenario. As for the inbound rules, I understand is good to have them to prevent the popups but there is no need to have them as "allow the connection" rules, because the monitoring connections are local we could have them as "block the connection" rules and the monitoring would still work correctly(as far as I have tested over the years) without allowing other LAN devices access to the mining software. The "Block all incoming connections, including those in the list of allowed apps" might seem enough for most use cases but I have mining computers that serve other content so I need access to some of their ports. Please consider adding an option so we can decide whether to create the rules as allow or block rules, thank you. Can this be solved by using the setting to block all incoming connections, but then explicitly configure Windows Defender to open up a few ports that you need? Even if you only monitor mining software locally, Windows will still complain and show the Blocked dialog when you launch the mining software unless it's an allowed application. This is the reason why Awesome Miner adds the mining software as allowed as it's very difficult to run mining operations without it. Block all incoming connections takes precedence over any other rule. I manually changed the allow rules created by awesome miner for the mining software to block rules. Have been mining since I originally asked about this without any issue or popup (picture of my rules linked). The problem is that when new software is added/updated new rules will be created by awesome miner as allowed rules. https://imgur.com/a/w7YBXdZIf you make this an option you could just leave the default as it is now(allowed rules), just in case "blocked" rules might break anything for someone. |
|
|
|
Any way to stop awesome miner from creating firewall rules for every mining software?
I don't want everyone on my LAN to have access to the mining software on my miners.
Local connections usually work even if you don't allow the program, is there any particular reason for awesome miner to create firewall rules?
There are currently no setting to prevent this behavior in Awesome Miner. Awesome Miner is registering the mining software as an allowed application. Mining software must be able to make outgoing pool connections and also open an API port where Awesome Miner connects for monitoring information. If an application isn't registered to the Windows firewall it may be blocked and Windows almost always shows a dialog where the user must accept the application. If you try to start almost any mining software outside of Awesome Miner (a software that Awesome Miner didn't register already) you will see that Windows Defender Firewall will show a warning dialog - unless Defender is completely disabled. In Windows Defender Firewall you also have a setting called "Block all incoming connections, including those in the list of allowed apps". That might be the one you are looking for in your specific scenario. As for the inbound rules, I understand is good to have them to prevent the popups but there is no need to have them as "allow the connection" rules, because the monitoring connections are local we could have them as "block the connection" rules and the monitoring would still work correctly(as far as I have tested over the years) without allowing other LAN devices access to the mining software. The "Block all incoming connections, including those in the list of allowed apps" might seem enough for most use cases but I have mining computers that serve other content so I need access to some of their ports. Please consider adding an option so we can decide whether to create the rules as allow or block rules, thank you. |
|
|
|
|
Any way to stop awesome miner from creating firewall rules for every mining software?
I don't want everyone on my LAN to have access to the mining software on my miners.
Local connections usually work even if you don't allow the program, is there any particular reason for awesome miner to create firewall rules?
|
|
|
|
|
Is it possible to use ethminer instead of claymore ethereum miner for managed profit miners? I've been trying with profit profiles but can't do it so far.
|
|
|
|
|
I just upgraded to 5.2.1, I can't benchmark the new Cryptonight variants (they are enabled on general options and profit profile), is that normal? do I need to do something else?
|
|
|
|
On a managed profit miner is there a way to disable ethereum dual mining, but keep ethereum by itself with accurate profit calculation?
What I did was disable each of the dual mining algorithms on the profit profile for the miner in question. They'll never be the most profitable by themselves anyway, and if that ever changes for one of them, you could always reenable them. You got me thinking and I think I found a simpler solution (or at least one that I like more): just go to the profit profile, Ethereum and set the dual mining hashrate to 0. Thanks |
|
|
|
On one of my rigs, for whatever reason, the console windows do not appear when miners are running. It still works though, AM launches the miner and gets stats back. Anyone have any idea what would cause this? I can't think of any Windows setting that would cause this.
Right click, properties, environment, process settings, console window mode. Default is "show formatted console window" |
|
|
|
|
On a managed profit miner is there a way to disable ethereum dual mining, but keep ethereum by itself with accurate profit calculation?
|
|
|
|
|
