In your photo I see the raspberry pi led's. But I meant the led's on the hashing boards.
You say that you need it for a 12 chip board. Are you currently trying to use the v5.0 software on that, or on a regular board?
I will try the software in the comming days none the less.
Topic: Ultra Under-overclock image for A2 Innosilicon by Emdje - V5.0 - page 4. (Read 79746 times)
im connected by cabel
im download v 4 and write to sd -work well
and download v 5 and write-not work
im need v 5.0 for 12 chip board
emdje
pls download v5.0 and write to sd ,and try to start V5.0.....
version you upload https://mega.nz/#!rIdCwaYI!eh55V6G3eAWILmRJbXZA__gzSQcsBePByxpIqEr4cyU not working.
Please check it and upload it again
im download v 4 and write to sd -work well
and download v 5 and write-not work
im need v 5.0 for 12 chip board
emdje
pls download v5.0 and write to sd ,and try to start V5.0.....
version you upload https://mega.nz/#!rIdCwaYI!eh55V6G3eAWILmRJbXZA__gzSQcsBePByxpIqEr4cyU not working.
Please check it and upload it again
How is your A2 connected to the network? Cable or wifi? Wifi obviously requires setting up with cable access to the pi. If cable, how is it routed? directly to the router, through a switch? Is the cable still good? What are the lights on the board doing, blinking first and then just burning?
I am in the middle of moving, but I will download the ISO (instead of using the one on my computer), burn it freshly and check if it works out of the box in the comming days. If there are issues I will try and adress them.
If you have another SD card you can always just plug in the v4, if that seems to work for you.
I am in the middle of moving, but I will download the ISO (instead of using the one on my computer), burn it freshly and check if it works out of the box in the comming days. If there are issues I will try and adress them.
If you have another SD card you can always just plug in the v4, if that seems to work for you.
not avileble a2 .....
v2, 3, 4, working well!
v5 not working
im download ISO v5 and write win32disc imiger to sd
Not working v5....
pls help
someone tried v5?
It does not work for me.
I can not find A2 on the network ..
im us advanced ip scanner.
and twice downloaded iso
need ISo for new a 2 -12 CHIPS 1380 MGZ
It does not work for me.
I can not find A2 on the network ..
im us advanced ip scanner.
and twice downloaded iso
need ISo for new a 2 -12 CHIPS 1380 MGZ
Try logging into your router and look at the connected devices. When I need to find my A2 I just login to my router and see the raspberry pi connected to it.
I never have any issues finding my A2 with any of the software versions.
not present a2 device
software v5.0 -working,,,,,,,,,?
?what ip in v 5.0
dhcp,?
Yes DHCP for the IP.
But what do you mean with your other question, could you post a screenshot of your router page?
someone tried v5?
It does not work for me.
I can not find A2 on the network ..
im us advanced ip scanner.
and twice downloaded iso
need ISo for new a 2 -12 CHIPS 1380 MGZ
It does not work for me.
I can not find A2 on the network ..
im us advanced ip scanner.
and twice downloaded iso
need ISo for new a 2 -12 CHIPS 1380 MGZ
Try logging into your router and look at the connected devices. When I need to find my A2 I just login to my router and see the raspberry pi connected to it.
I never have any issues finding my A2 with any of the software versions.
not present a2 device
software v5.0 -working,,,,,,,,,?
?what ip in v 5.0
dhcp,?
I just ordered an A2 Mega from ZoomHash and it should be here tomorrow. I am completely new to this miner and I saw the title to this thread about under and overclocking the A2. I would be interested in cranking mine down so that is runs cooler and uses less power. Is this image compatible with the A2 Mega? What is the slowest speed we can run these and be stable? Any recommendations you might have would be greatly appreciated!
Providing that you can provide a stable power source, and keep the chip cool, it will run stable from 400MHz (5Mhash per 8 chip board) to 1500MHz (18.6 Mhash per 8 chip board).
If you want to overclock the chips beyond 1200MHz, increase the voltage to .92, or as one user suggest even to 1 volt. Somewhere in this thread I describe how you can overvolt (or undervolt in the same way) your board. If you significantly want to go under the 1200MHz you can undervolt your board. I have no experience with that though as to how low with which clock frequencies you can go.
someone tried v5?
It does not work for me.
I can not find A2 on the network ..
im us advanced ip scanner.
and twice downloaded iso
need ISo for new a 2 -12 CHIPS 1380 MGZ
It does not work for me.
I can not find A2 on the network ..
im us advanced ip scanner.
and twice downloaded iso
need ISo for new a 2 -12 CHIPS 1380 MGZ
Try logging into your router and look at the connected devices. When I need to find my A2 I just login to my router and see the raspberry pi connected to it.
I never have any issues finding my A2 with any of the software versions.
someone tried v5?
It does not work for me.
I can not find A2 on the network ..
im us advanced ip scanner.
and twice downloaded iso
need ISo for new a 2 -12 CHIPS 1380 MGZ
It does not work for me.
I can not find A2 on the network ..
im us advanced ip scanner.
and twice downloaded iso
need ISo for new a 2 -12 CHIPS 1380 MGZ
In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
True I can see that, for some reason I had not though about send a download and run type thing.
I was looking, I see the vulnerability for glibc but not really for eglibc, guess going to have to make a test bench somehow
eglibc is equally affected from the problem as far as I can judge:
i.e.: http://www.ubuntu.com/usn/usn-2485-1/
I am not that into coding and software as I would like. Do I read it correctly that because I have build the cgminer builds on the raspberry pi and not under Ubuntu that the builds are not vulnerable??
Most advisories only talk about glibc, but I am pretty confident all previous versions of eglibc were vulnerable (no matter if ubuntu or debian):
https://www.debian.org/security/2016/dsa-3480
If you still have your build system available, just apt-get upgrade it and then make the binary again, that should be sufficient (eventually a make clean would be advisable before).
Good point, I am not expert enough to answer this.
To my knowlegde if eglibc has not been linked statically then this could be enough (= if -static was not used for building).
In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
True I can see that, for some reason I had not though about send a download and run type thing.
I was looking, I see the vulnerability for glibc but not really for eglibc, guess going to have to make a test bench somehow
eglibc is equally affected from the problem as far as I can judge:
i.e.: http://www.ubuntu.com/usn/usn-2485-1/
I am not that into coding and software as I would like. Do I read it correctly that because I have build the cgminer builds on the raspberry pi and not under Ubuntu that the builds are not vulnerable??
Most advisories only talk about glibc, but I am pretty confident all previous versions of eglibc were vulnerable (no matter if ubuntu or debian):
https://www.debian.org/security/2016/dsa-3480
If you still have your build system available, just apt-get upgrade it and then make the binary again, that should be sufficient (eventually a make clean would be advisable before).
February 28, 2016, 09:05:57 PM
I have been working on a miner that I suspected the controller board died for some reason, I had built a replacement out of a CPLD but it is not the handiest thing to put in place so today I decided to figure this thing out. The device would not find any boards but I tested all of them one at a time and they worked. I traced out everything and found that one of the MISO lines back had no voltage on it, they use a couple of 3 input and gates for only select the signal going back cause I guess the theory is that it will be logic low when the board is selected. Anyway got to looking and there are pullups on all the lines but for some reason not pulling up, figured out which resistor it was and when I tried to test it is was actually broke in two, replaced resistor and away it went. R296
Great that your got it working
February 28, 2016, 02:15:11 PM
In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
True I can see that, for some reason I had not though about send a download and run type thing.
I was looking, I see the vulnerability for glibc but not really for eglibc, guess going to have to make a test bench somehow
eglibc is equally affected from the problem as far as I can judge:
i.e.: http://www.ubuntu.com/usn/usn-2485-1/
I am not that into coding and software as I would like. Do I read it correctly that because I have build the cgminer builds on the raspberry pi and not under Ubuntu that the builds are not vulnerable??
Most advisories only talk about glibc, but I am pretty confident all previous versions of eglibc were vulnerable (no matter if ubuntu or debian):
https://www.debian.org/security/2016/dsa-3480
If you still have your build system available, just apt-get upgrade it and then make the binary again, that should be sufficient (eventually a make clean would be advisable before).
February 28, 2016, 01:00:51 PM
I have been working on a miner that I suscpected the contrller board died for some reason, I had built a replacement out of a CPLD but it is not the handiest thing to put in place so today I decided to figure this thing out. The device would not find any boards but I tested all of them one at a time and they worked. I traced out everything and found that one of the MISO lines back had no voltage on it, they use a couple of 3 input and gates for only select the signal going back cause I guess the theoy is that it will be logic low when the board is selected. Anyway got to looking and there are pullups on all the lines but for some reason not pulling up, figured out which resistor it was and when I tried to test it is was actually broke in two, replaced resistor and away it went. R296
Great that your got it working
February 28, 2016, 01:00:23 PM
In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
True I can see that, for some reason I had not though about send a download and run type thing.
I was looking, I see the vulnerability for glibc but not really for eglibc, guess going to have to make a test bench somehow
eglibc is equally affected from the problem as far as I can judge:
i.e.: http://www.ubuntu.com/usn/usn-2485-1/
I am not that into coding and software as I would like. Do I read it correctly that because I have build the cgminer builds on the raspberry pi and not under Ubuntu that the builds are not vulnerable??
February 25, 2016, 04:12:29 PM
I have been working on a miner that I suscpected the contrller board died for some reason, I had built a replacement out of a CPLD but it is not the handiest thing to put in place so today I decided to figure this thing out. The device would not find any boards but I tested all of them one at a time and they worked. I traced out everything and found that one of the MISO lines back had no voltage on it, they use a couple of 3 input and gates for only select the signal going back cause I guess the theoy is that it will be logic low when the board is selected. Anyway got to looking and there are pullups on all the lines but for some reason not pulling up, figured out which resistor it was and when I tried to test it is was actually broke in two, replaced resistor and away it went. R296
February 25, 2016, 01:45:53 PM
In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
True I can see that, for some reason I had not though about send a download and run type thing.
I was looking, I see the vulnerability for glibc but not really for eglibc, guess going to have to make a test bench somehow
eglibc is equally affected from the problem as far as I can judge:
i.e.: http://www.ubuntu.com/usn/usn-2485-1/
February 25, 2016, 12:19:51 PM
In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
True I can see that, for some reason I had not though about send a download and run type thing.
I was looking, I see the vulnerability for glibc but not really for eglibc, guess going to have to make a test bench somehow
February 25, 2016, 11:38:43 AM
Is it possible to update a miner with your image simply via apt-get update/upgrade, once it is installed and running?
What version of glibc is in use? See here: http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/
What version of glibc is in use? See here: http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/
No that is not possible, and I don't know which version of glibc is used I would have to check that when I have some more time.
I'd recommend to check that as soon as possible. Since it is a really severe thing.
ldd (Debian EGLIBC 2.13-38+rpi2) 2.13
while it is a big deal I am not sure how bad in this case it is, I mean it has been around since 2008 , been out for 7 months already, if these were right on the internet w/o a firewall maybe I would be worried, I am up for some scenarios to talk about
In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
February 25, 2016, 08:59:53 AM
Is it possible to update a miner with your image simply via apt-get update/upgrade, once it is installed and running?
What version of glibc is in use? See here: http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/
What version of glibc is in use? See here: http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/
No that is not possible, and I don't know which version of glibc is used I would have to check that when I have some more time.
I'd recommend to check that as soon as possible. Since it is a really severe thing.
ldd (Debian EGLIBC 2.13-38+rpi2) 2.13
while it is a big deal I am not sure how bad in this case it is, I mean it has been around since 2008 , been out for 7 months already, if these were right on the internet w/o a firewall maybe I would be worried, I am up for some scenarios to talk about
Jump to: