Bitcoin Forum
November 17, 2024, 09:27:48 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 [726] 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 ... 843 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5805642 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic. (3 posts by 1+ user deleted.)
-ck (OP)
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


View Profile WWW
February 28, 2014, 03:00:24 AM
 #14501

New version: 4.0.1, 28th February 2014

A few fixes for most users on top of 4.0, and some major improvements for hashfast users that hopefully will run in tandem with their 0.4 firmware release.


Human readable changelog:

- Fixed cgminer getting stuck at startup when no pool is valid and getting itself into an endless loop
- Fixed AMUs being detected as failing and resetting them too early
- Made the check for failing devices proportional to hashrate to not get false positives
- Queue size is now adjusted up dynamically when it bottoms out regularly which it may on very high hashrates/many devices
- Fixed ANU and other icarus devices falsely showing higher hashrates by calculating hardware errors - NOTE this means if you were seriously overclocking it before, your hashrate will appear to be lower now, but it was simply reporting wrong before.
- Changed the priority of various threads to bias towards work generation instead of giving the mining threads priority.
- Fixed a crash when a device drops out during an attempt to initialise
- Ava2 voltage detection
- Show the device number on the left without padding
- Fixes for devices that ended in OFF state instead of dropping out to allow them to hotplug
- Hashfast changes:
Multiple devices are now added one by one by hotplugging according to name and then initialising instead of trying to initialise them together which made them fail previously.
Dropping the clock speed on a device failure is limited to default clock speed of 550 and the amount of drop per failure can be configured or disabled with:
Code:
--hfa-fail-drop <arg> Set how many MHz to drop clockspeed each failure on an overlocked hashfast device (default: 10)

If you overclock your hashfast device with --hfa-hash-clock and cgminer detects
it failing to return hashes, it will restart it at a lower clock speed if
possible. Changing this value will allow you to choose how much it will lower
the clock speed or to disable this function entirely.
Devices with newer firmware can be named using the op name feature, or cgminer will generically choose a suitable name for them and display it at startup
Code:
--hfa-name <arg>    Set a unique name for a single hashfast device specified with --usb or the first device found

This command allows you to specify the unique name stored in nvram on a single
hashfast device. This name can be queried from the API stats command and comes
up as "op name". Discrete names are used by cgminer to try to maintain settings
across restarts, unplugs/hotplugs and so on. If this command is used by itself,
the name will be given to the first hashfast device it encounters and then
cgminer will proceed to go back to regular mining. If you have multiple devices,
it is best to discretely choose the device you wish to use with the --usb
command. For example
'lsusb' on linux shows the following devices (297c:0001 is a hfa device):
 Bus 001 Device 079: ID 297c:0001
 Bus 004 Device 042: ID 297c:0001
If you wished to name the second device Slug you would add the commands:
 --hfa-name Slug --usb 4:42
Devices that are re-hotplugged are recognised by their name or serial number if possible and appear back as the same device number on screen
More information in API stats
Updated udev rules file to allow regular users to update firmware
Fixes for corrupt message reading and runs of crc errors
Ability to disable the core shedding feature in new firmware:
Code:
--hfa-noshed        Disable hashfast dynamic core disabling feature

Newer firmwares on hashfast devices dynamically disable cores that generate
invalid data. This command will disable this feature where possible.
Numerous low level fixes


Full changelog:

- Refresh the log window on pool failure message at startup.
- Rework the pool fail to connect at startup to not get stuck indefinitely
repeatedly probing pools with new threads and to exit immediately when any key
is pressed.
- Fix for crashes with a failed startup.
- Use an early_quit function for shutting down when we have not successfully
initialised that does not try to clean up.
- Add more information to a hfa bad sequence tail event.
- Increase the work queue at the top end if we've hit the bottom as well.
- Set the work generation thread high priority, not the miner threads.
- Bringing each hfa device online takes a lot of work generation so only ever do
one at a time.
- Increase the opt_queue if we can hit the maximum amount asked for but are
still bottoming out.
- Keep the old hfa device data intact with a clean thread shutdown to allow it
to be re-hotplugged with the old information.
- Cope with the API calling hfa on partially initialised devices having no info.
- Show only as many digits as are required to display the number of devices.
- Cold plug only one hashfast device to get started, and then hotplug many to
minimise startup delays and possible communication delays causing failed first
starts.
- Send a shutdown and do a usb_nodev if hfa_reset fails.
- Null a device driver should thread prepare fail.
- Add a function for making all driver functions noops.
- Don't try to reinit a device that's disabled.
- Disable a device that fails to prepare.
- Check for lack of thread in watchdog thread for a failed startup.
- Make all device_data dereferences in the hfa driver safe by not accessing it
in statline before when it's non-existent.
- Add an option to disable dynamic core shedding on hashfast devices.
- Do not remove the info struct on a failure to hfa prepare.
- Detect an hfa device purely on the basis of getting a valid header response to
an OP_NAME query, leaving init to hfa_prepare which will allow multiple devices
to start without holding each other up at startup.
- Store the presence and validity of opname in the hfa info.
- api - buffer size off by 1 for joined commands
- minion - clean up statline
- Only break out of usb_detect_one when a new device is found.
- Use usb_detect_one in the hfa driver.
- Provide a usb_detect_one wrapper which only plugs one device at a time,
breaking out otherwise.
- Issue a usb_nodev on a bad work sequence tail in hfa
- Read in hfa stream until we get a HF_PREAMBLE
- Add shed count to hfa API stats output.
- Display the base clockrate for hfa devices with a different name to per die
clockrates to be able to easily distinguish them.
- Use op_name if possible first with hfa devices to detect old instances and be
able to choose the starting clockspeed before sending an init sequence,
reverting to setting op name and serial number as fallbacks.
- Make hfa resets properly inherit across a shutdown.
- Don't break out of hfa_old_device early if there's no serial number.
- Fix harmless warning.
- Allow the drop in MHz per hfa failure to be specified on the command line.
- Icarus - ignore HW errors in hash rate ... and fix detection of them
- Enable the hfa shed supported feature by default.
- Add to udev rules hfa devices for firmware writing.
- Remove ENV from hashfast udev rules.
- Add a --hfa-name command that allows one to specify the unique opname for a
hashfast device.
- Ava2 decode the voltage, get the temp_max
- Set the clock rate with a work restart instead of an init when changing to old
clocks for hfa
- Set opname on hfa devices without a serial number to a hex value based on time
to not overflow the field.
- Add op name to hfa API stats output if it exists.
- Set the actual op_name in hfa devices if cgminer is choosing it itself due to
it being invalid.
- Re-init an hfa device to its old data before setting up info structures as
their sizes may change.
- Remove the usb device whenever we do a running shutdown on hfa and do a
shutdown as the imitated reinit  to allow it to hotplug again.
- Reset opt hfa dfu boot after it's used.
- Comment out windows only transfer on hfa startup.
- Clean up structures unused in case of all failures in hfa detect common
- Clear all structures should we fail to hfa reset on adjusting clock on a
hotplug.
- Set master and copy cgpu hash clock rate for hfa when dropping it on a
restart.
- Set the master hfa clock speed to lower when shutting down a copy.
- Do a clear readbuf on any hfa reset in case the device  has not yet cleanly
shut down.
- Increase hfa fanspeed slightly more when it's rising in the optimal range than
falling.
- Always decrease hfa clock speed on a running shutdown and don't try sending an
init frame since it will be dropped regardless.
- Match hfa devices to old ones based on OP_NAME values before serial numbers if
possible.
- Read off the OP_NAME if it exists and is supported on hfa devices, setting it
to the device serial number or a timestamp if it is invalid.
- Updated hf protocol
- Check for an amount along with no error in hfa clear readbuf
- Hfa clear readbuf can return a nonsense amount when there's a return error so
ignore the amount.
- Running resets always cause a shutdown on hfa meaning the device will
disappear with modern firmware so always kill off the threads to allow
re-hotplugging.
- Reset the hfa hash clock rate to the old one if we find an old instance, only
setting the device id in hfa_prepare
- Keep the device_id on the original zombie thread for HFA in case of further
resets.
- Break out of hfa inherit if there is no device data.
- Inherit the hfa zombie instance after the device id has been allocated.
- The list_for_each_cgpu macro will dereference when there are no mining threads
yet.
- Make hfa hotplug inherit some parameters from a previous instance if the
serial number exists and is matching, avoiding dropping the clock on all
devices.
- Per device last getwork won't work if the device stops asking for work.
- Use the share_work_tdiff function in the driver watchdogs.
- Provide a helper function for determining time between valid share and getwork
per device.
- Store last_getwork time on a per-device basis.
- Limit the decrease of hfa clock rate on reset to the default clockrate.
- Base the hfa failure time on the current expected hashrate instead of a static
15 seconds.
- We shouldn't be trying to read from the hfa_send_shutdown function itself.
- Reset the icarus failing flag only when a valid nonce is found.
- Transferred value is corrupt on a NODEV error in usbutils.
- Set each miner thread last valid work just before starting its hash loop in
case there are delays at startup.
- Only memcopy *transferred data in usbutils if we have received only success or
a non-fatal error.
- Increase to 25 nonce ranges on icarus fail detect.
- Set icarus device fail time to be dependent on device speed to avoid falsely
detecting failure on slower AMU devices.
- Updated hf protocol header.
- Updated BE hf protocol header.
- Take into account shed cores on hfa devices when determining how many jobs to
send.
- Fix compilation error with two avalon types.
- Fix missing A1 files from distribution.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Karin
Member
**
Offline Offline

Activity: 109
Merit: 10



View Profile WWW
February 28, 2014, 11:01:08 AM
 #14502

Unofficial Mac binaries have been updated for v4.0.1 and tested, and are available here.

These are precompiled universal binaries that support Mac OS X 10.5.8 through 10.9+.

Also, the forum thread title is still 4.0.0 Smiley

Easiest to use bitcoin/litecoin miner for Mac: AsteroidApp.com | @AsteroidApp | Bitcointalk forum thread
Unofficial cgminer for Mac OS X | sgminer for Mac OS X
KyrosKrane
Sr. Member
****
Offline Offline

Activity: 295
Merit: 250


View Profile WWW
March 01, 2014, 03:16:56 PM
 #14503

- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
os2sam
Legendary
*
Offline Offline

Activity: 3586
Merit: 1098


Think for yourself


View Profile
March 01, 2014, 03:28:23 PM
 #14504

- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?

Give it a try and let us know.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-ck (OP)
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


View Profile WWW
March 01, 2014, 09:13:37 PM
 #14505

- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?
That's what the change is for...

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
canford
Member
**
Offline Offline

Activity: 89
Merit: 10


View Profile WWW
March 01, 2014, 10:36:04 PM
 #14506

- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?
That's what the change is for...

Running 12 BE's with 4.0.1, working well.  Also updated Avalon Mini to 4.0.1, no issues.  Though oddly, the Mini has slowed down from 62 GH/s to 59 GH/s over a period of months, unrelated to cgminer - I suspect some of the chips have failed.

Пoльзyйтecь бecплaтнo и пишитe чтo вaм нyжнo yлyчшить:trd.ai
Bидeo, кaк пoльзoвaтьcя пpoeктoм:https://www.youtube.com/watch?v=pNhx715vOOk&feature=youtu.be
AngusCanine
Legendary
*
Offline Offline

Activity: 1414
Merit: 1001

To weird to live To rare to die


View Profile WWW
March 02, 2014, 01:28:50 AM
Last edit: March 02, 2014, 02:26:44 AM by AngusCanine
 #14507

when using 4.0.1 what should my bat file look like for overclocking antminer u1

edit : thank you ckolivas for the speedy reply on the other thread
-ck (OP)
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


View Profile WWW
March 02, 2014, 01:52:55 AM
 #14508

when using 4.0.1 what should my bat file look like for overclocking antminer u1

Whatever it normally looks like plus: --anu-freq 250

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
AngusCanine
Legendary
*
Offline Offline

Activity: 1414
Merit: 1001

To weird to live To rare to die


View Profile WWW
March 02, 2014, 02:10:51 AM
 #14509

when using 4.0.1 what should my bat file look like for overclocking antminer u1

[/quote)
Whatever it normally looks like plus: --anu-freq 250


works perfectly
Internet151
Full Member
***
Offline Offline

Activity: 174
Merit: 100



View Profile
March 02, 2014, 11:18:39 AM
Last edit: March 03, 2014, 11:52:11 AM by Internet151
 #14510

Tried out 4.0.1 with my hashfast babyjets with upgraded 0.4 preview firmware. I noticed now when a babyjet reconnects for any reason it will keep it's name (ex. HFB 0) in the cgminer window, but in the API it will get a new name (ex. HFB 14) instead of just reactivating the old name. It's not really high priority, but id help clean up the stats I'm pulling from the API if this was corrected.

Also, had a few cases were 4.0.1 crashed when a babyjet hit 90C, went back to 3.12.0 and this did not reoccur.

EDIT: Also, cpu usage by cgminer seems to have greatly increased. I noticed these things with two machines running Windows 7.
HellDiverUK
Hero Member
*****
Offline Offline

Activity: 1246
Merit: 501



View Profile
March 03, 2014, 08:57:28 AM
 #14511

Is there a way to ban Luke from this thread? I suggest asking Theymos.

I suggest you keep your nose out of it.  Tongue
canford
Member
**
Offline Offline

Activity: 89
Merit: 10


View Profile WWW
March 03, 2014, 09:39:57 AM
Last edit: March 03, 2014, 09:54:55 AM by canford
 #14512

Will do, I have reverted the erupters to 3.12.3, which works great.  The bitcoin mining world is an odd combination of old and new hardware, I'm just running everything I have.  I suppose the financially logical thing to do would be to flip the erupters on Ebay, but I'd rather mine with them as long as they make more than the cost of the electricity that they consume.  Right now, the Avalon Mini + BE's make about $6 a day but cost around $4.  When that line is crossed, the tough thing will be throwing away working hardware, which the engineer in me hates the idea of.
Indeed, it's tough, but I'm pretty sure the erupters fell below their electricity costs a while ago, though I don't have the numbers here. You could always bet on BTC going $10k in the future and thus mining at an electricity cost loss now will pay off longer term... or you could just sell them now for more than they'll ever earn anyway (highly recommend the latter). Anyway in a future version I'll be more lax for these slowest devices left that cgminer still mines on, as this was clearly an oversight on my part. The next slowest device is a normally clocked antminer U1 at 1.6GH, and everyone overclocks them to 2GH anyway, so the difference is stark.

I ran all the numbers today in an excel spreadsheet.  First, let me say that I am mining bitcoin because I believe in bitcoin, so making money would be great but it is not a requirement.  Having run the numbers through, it appears that the Block Erupters and Avalon Mini do indeed make a small profit: Per day electricity cost $1.98, income $4.93, profit $2.95.  This is at the current 3.82G difficulty.  So it looks like 110nm has a little run life left.  I'm going to keep mining and perhaps expand the operation, depending on what happens as the all of the pre-orders are delivered and people mine regardless of cost to recoup what they can.  Interesting days ahead.  Thanks again CK for keeping cgminer up to date.

Пoльзyйтecь бecплaтнo и пишитe чтo вaм нyжнo yлyчшить:trd.ai
Bидeo, кaк пoльзoвaтьcя пpoeктoм:https://www.youtube.com/watch?v=pNhx715vOOk&feature=youtu.be
KyrosKrane
Sr. Member
****
Offline Offline

Activity: 295
Merit: 250


View Profile WWW
March 04, 2014, 05:56:54 AM
 #14513

I've noticed two odd behaviors with cgminer since switching to 4.0.1.  This is on Ubuntu 13.10 using the precompiled 64-bit binary of cgminer.  I have a small farm of 31 USB Block Erupters set up on this rig.  I configured the box using the instructions in the README file for USB devices running as a non-root user on Linux. Starting cgminer, they all run fine.

First thing, if I restart cgminer (using Settings -> Restart ->Yes), cgminer throws a "SEM" error for each device saying the devices are already in use.  Even if I wait a bit, cgminer doesn't re-detect them using hotplug.  I'll try to get you the exact error message if you need it.  Exiting cgminer then immediately restarting from the command line works fine; it instantly detects the devices and starts mining.

Second thing, cgminer doesn't seem to save queue settings.  I run p2pool, which recommends a queue of zero.  I set the queue (using Settings -> Queue -> 0), and it confirms the queue is set to zero.  Then I write the config file (Write -> type in path and name) and the summary screen that comes up shows a non-zero value for the queue.  After leaving the node running for a few days, I checked this morning and the queue size was at a stunning 4808! It manifested as a 6% drop in the hash rate for the devices.  Normally they run at a steady 335MH/s, give or take a 1%.  Today I found them at 315MH/s.

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
deagel
Member
**
Offline Offline

Activity: 67
Merit: 10


View Profile
March 04, 2014, 06:10:06 AM
 #14514

hi,
is there an option to use a http proxy on multi pools?

i found this but it is only for single pools:
Code:
EXECUTIVE SUMMARY ON USAGE:

Single pool:

cgminer -o http://pool:port -u username -p password

Multiple pools:

cgminer -o http://pool1:port -u pool1username -p pool1password -o http://pool2:port -u pool2usernmae -p pool2password

Single pool with a standard http proxy:

cgminer -o "http:proxy:port|http://pool:port" -u username -p password

Single pool with a socks5 proxy:

cgminer -o "socks5:proxy:port|http://pool:port" -u username -p password

Single pool with stratum protocol support:

cgminer -o stratum+tcp://pool:port -u username -p password

The list of proxy types are:
 http:    standard http 1.1 proxy
 http0:   http 1.0 proxy
 socks4:  socks4 proxy
 socks5:  socks5 proxy
 socks4a: socks4a proxy
 socks5h: socks5 proxy using a hostname
kano
Legendary
*
Offline Offline

Activity: 4620
Merit: 1851


Linux since 1997 RedHat 4


View Profile
March 05, 2014, 07:57:52 AM
 #14515

hi,
is there an option to use a http proxy on multi pools?
...
You use a proxy setting on each pool you want a proxy for ...

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
-ck (OP)
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


View Profile WWW
March 05, 2014, 09:39:26 AM
 #14516

I've noticed two odd behaviors with cgminer since switching to 4.0.1.  This is on Ubuntu 13.10 using the precompiled 64-bit binary of cgminer.  I have a small farm of 31 USB Block Erupters set up on this rig.  I configured the box using the instructions in the README file for USB devices running as a non-root user on Linux. Starting cgminer, they all run fine.

First thing, if I restart cgminer (using Settings -> Restart ->Yes), cgminer throws a "SEM" error for each device saying the devices are already in use.  Even if I wait a bit, cgminer doesn't re-detect them using hotplug.  I'll try to get you the exact error message if you need it.  Exiting cgminer then immediately restarting from the command line works fine; it instantly detects the devices and starts mining.

Second thing, cgminer doesn't seem to save queue settings.  I run p2pool, which recommends a queue of zero.  I set the queue (using Settings -> Queue -> 0), and it confirms the queue is set to zero.  Then I write the config file (Write -> type in path and name) and the summary screen that comes up shows a non-zero value for the queue.  After leaving the node running for a few days, I checked this morning and the queue size was at a stunning 4808! It manifested as a 6% drop in the hash rate for the devices.  Normally they run at a steady 335MH/s, give or take a 1%.  Today I found them at 315MH/s.
Yep restart's pretty broken. It's another one of those features from the GPU days unfortunately and shutting down all these threads reliably is really hard. I mentioned it a few pages back that only quit and start works. If I had infinite hours to work on it I'd eventually fix it, but new device drivers/features keep taking priority sorry.

I changed the queue size to auto adjust every time it hits zero now since it shouldn't - and there are devices with massive hashrates that need a huge queue to keep busy. Unfortunately that seems to be fighting with you trying to set it to zero, but that shouldn't actually drop the hashrate unless you're running out of cpu. So yeah it's not ideal. Kinda hard writing code for 333MH and 50TH setups at the same time. Lemme think about it. This might need a new command line option.


Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
KyrosKrane
Sr. Member
****
Offline Offline

Activity: 295
Merit: 250


View Profile WWW
March 05, 2014, 10:16:37 AM
 #14517

I changed the queue size to auto adjust every time it hits zero now since it shouldn't - and there are devices with massive hashrates that need a huge queue to keep busy. Unfortunately that seems to be fighting with you trying to set it to zero, but that shouldn't actually drop the hashrate unless you're running out of cpu. So yeah it's not ideal. Kinda hard writing code for 333MH and 50TH setups at the same time. Lemme think about it. This might need a new command line option.
Awesome, thanks for the update.  I'm not worried about the restart, so long as you're aware of it and it isn't a symptom of something else being broken.  Exit/restart works fine for me.

For the other, could I set the work queue to 1 as a workaround? Or would the system still try to raise it?

As for CPU, that's possible, I guess.  I'm running on a decade-or-so old Pentium dual-core box.  I'll see if I can set up some kind of CPU monitoring.

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
M3kk
Full Member
***
Offline Offline

Activity: 128
Merit: 100


View Profile
March 05, 2014, 01:43:47 PM
 #14518

Hello, what i need to set to --api-allow to be accesed from ANY ip? Not only 127.0.0.1 and 192.168.0.x, but from 192.168.x.x too for example.. W:192.168.0.0/24,127.0.0.1 is only for localhost and 192.168.0.x ...

Ty.

LE: Nevermind, i think this is "W:0/0" Smiley.
crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
March 05, 2014, 01:55:40 PM
 #14519

Hello, what i need to set to --api-allow to be accesed from ANY ip? Not only 127.0.0.1 and 192.168.0.x, but from 192.168.x.x too for example.. W:192.168.0.0/24,127.0.0.1 is only for localhost and 192.168.0.x ...

Ty.

LE: Nevermind, i think this is "W:0/0" Smiley.
W:192.168.0.0/16 would allow anyone on the 192.168.x.x range.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
kano
Legendary
*
Offline Offline

Activity: 4620
Merit: 1851


Linux since 1997 RedHat 4


View Profile
March 05, 2014, 09:32:52 PM
 #14520

Hello, what i need to set to --api-allow to be accesed from ANY ip? Not only 127.0.0.1 and 192.168.0.x, but from 192.168.x.x too for example.. W:192.168.0.0/24,127.0.0.1 is only for localhost and 192.168.0.x ...

Ty.

LE: Nevermind, i think this is "W:0/0" Smiley.
Seriously, that's a bad idea in general.
It means anyone with any access (local or remote) to your miner can change anything they like ... including who it mines for.
That's what KFC put in their miners originally, no idea if they ever fixed it.

Also, 192.168/16 will also work

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
Pages: « 1 ... 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 [726] 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 ... 843 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!