Official FutureBit Apollo II/BTC Software/Image and Support thread

[OgNasty]

I'm not experiencing any issues with usernames being changed.  I've also never seen the dashboard (don't even know how to access it to be honest).

Wait, then how did you set your mining pool information?
And how did you choose between 'eco', 'balanced' or 'turbo'?

You can choose between the different settings using a .bat file to start the miner (I pasted it in my post) with the necessary settings.  You can set it to whatever you want, not just the 3 options (although I wouldn't play around with those settings too much) and also setup a restart (as shown in my post) so that if it crashes it will automatically start mining again.  I use the interface at slush pool to make sure everything is running as it should.

Looks like your running a standard unit, so there is no dashboard for that since you run the miner software directly on your system

Yup, just a couple of standard units running off of a PC.  That would explain why no dashboard for me.

[thak777]

TL;DR: Do I have to wait for the Full to sync before a completely separate hashboard in my Standard is able to mine? That seems pretty silly.

I just got a Full & Standard. After plugging them in, I had the problem with the unseated NVMe drive and I've already reflashed my install because I made the mistake of accepting the system upgrades when the machine first booted. (I've since turned off all of the repositories so it thinks I'm fully upgraded.)

ANYWAY...

I'm still waiting for the node to sync. After reading the thread, I'm assuming the miner isn't staying running on the Full because syncing is overheating the CPU. Meanwhile, my Standard is sitting there with a solid red LED on the front, connected via the USB cable, doing nothing. So I restart the miner, it detects both of them, starts them up--going from solid red LED to flashing LED--and then immediately proceeds to show them inactive.

[SpeedForceGN]

1) Is it possible to use the in screen keyboard option at the Apollo os login screen? I don't have a keyboard I can leave permanently hooked up to the Apollo unit, it would be much more convenient if I could use the mouse to pick the password letters using an on-screen keyboard.

2) Also, has anybody set up a VPN on the Apollo unit? I'm thinking about using my free windscribe account (50gb/mo) but weary of breaking anything custom setup for the miner/node to work.

Thanks!

I use my dVPN  from Deeper Network just fine

Is that only a hardware solution or do they have a downloadable as well?

Are these results in line with what others are getting?https://i.ibb.co/71Rtrkh/Screenshot-20220225-135252-Chrome-Beta.jpg

And if anyone is looking to upgrade their SSD to 2TB...  https://slickdeals.net/f/15619948-2tb-samsung-970-evo-plus-ssd-200-free-s-h-at-amazon

That is average in returns for one unit

[SpeedForceGN]

I'm not experiencing any issues with usernames being changed.  I've also never seen the dashboard (don't even know how to access it to be honest).

Wait, then how did you set your mining pool information?
And how did you choose between 'eco', 'balanced' or 'turbo'?

You can choose between the different settings using a .bat file to start the miner (I pasted it in my post) with the necessary settings.  You can set it to whatever you want, not just the 3 options (although I wouldn't play around with those settings too much) and also setup a restart (as shown in my post) so that if it crashes it will automatically start mining again.  I use the interface at slush pool to make sure everything is running as it should.

Looks like your running a standard unit, so there is no dashboard for that since you run the miner software directly on your system

Yup, just a couple of standard units running off of a PC.  That would explain why no dashboard for me.

How do you and where do you make those changes?

[jstefanop]

If anyone is interested in buying a full node+psu at an extremely discounted price, message me.

I have absolutely no desire to be apart of FutureBit with the obvious coding flaws that's allowed some sort of exploit through that's caused a great deal of us to all experience the same exact thing.

I'm currently mining 7 different coins with a dozen or so different miner manufacturers, Helium, a couple weather stations, GEOD navigators, etc... this is the only product I own I truly feel has a potential to completely compromise my entire network by the obvious back doors on these units.

First 400 takes it, it's less than 2 weeks old, I'll even throw in free expedited shipping.

Let's stop with the fear mongering please. Only you and one other person has reported this, and support has been in touch with one of you. Its been determined the issue is because you guys chose to expose your Apollo to the whole internet for anyone to attack. This akin to leaving your Bitcoin wallet on a table outside, publicly yelling out your address and telling everyone come and take it.

The issue is with forwarding our webUI to the open internet. The webui is not a server grade hardened frontend, its designed for easy access and control of your Apollo from your LAN. While you can forward your WAN port 80 so you can bring your UI up from any and device/place what you are doing is essentially hosting it as a public web page that anyone can try to attack, and this is precisely what happened.

Simply remove those port forwards and you will be fine(or go through the process of turning your Apollo into a hardened server grade web server). If you really want to be able to access your Apollo from outside your LAN in an easy and more secure way, then setup a remote access app directly in the desktop environment.

[n0nce]

TL;DR: Do I have to wait for the Full to sync before a completely separate hashboard in my Standard is able to mine? That seems pretty silly.

FWIW, my single standard unit was able to sync and mine at the same time.
It took it 48h roughly to sync, which is pretty good. CPU temp was in the 70s / 80s, but that should be no problem for modern chips. In fact, high end desktop CPUs can operate even close to 100C before throttling.
I would just position the thing on top of something else so it can more easily suck in air from the bottom for the little Orange Pi fan.

Its been determined the issue is because you guys chose to expose your Apollo to the whole internet for anyone to attack. This akin to leaving your Bitcoin wallet on a table outside, publicly yelling out your address and telling everyone come and take it.

Oh noo that's terrible! Did they set it as an 'exposed host' or just forward port 80 though?
Good to finally know what caused these guys issues...

Personal opinion: it's easily good enough to check the pool's dashboard when on the go; if you really need to see the dashboard, you could create an SSH tunnel, VPN into your network, or potentially setup a Tor v3 hidden service with authentication. The latter might be the safest solution honestly.

Especially in current international state of affairs, there's lots of viruses, hacks and malware going on as well guys, so beware, update your stuff and stay safe. Don't decrease your security in any way if avoidable..

~

Are you selling a full or standard unit for 400 bucks? And that's $400, 400€, or what currency? With or without PSU?

[Darkmatus]

Hello,

I got al the time the following error on my raspberry pi3 (Ubuntu aarch64) using the aarch64 binaries. The test on my windows machine works fine but now

MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00
MsPacket: crc mismatch: exp 0x00000000 != act 0xc048df6d
magic=0xabcd, ver=0xd166, msgId=0x28, msgSize=4819
WARNING: slave[0]: packet ignored
[6144]: 40 00 00 20 41 41 70 6f ... 00 00 00 00 00 00 00 00

Can any body help with this?

[thak777]

TL;DR: Do I have to wait for the Full to sync before a completely separate hashboard in my Standard is able to mine? That seems pretty silly.

FWIW, my single standard unit was able to sync and mine at the same time.
It took it 48h roughly to sync, which is pretty good. CPU temp was in the 70s / 80s, but that should be no problem for modern chips. In fact, high end desktop CPUs can operate even close to 100C before throttling.
I would just position the thing on top of something else so it can more easily suck in air from the bottom for the little Orange Pi fan.

So it's even weirder. I just ended up leaving it all running overnight...and what do you know--Nicehash is reporting that it's been successfully mining since I posted this message...The web dashboard still shows that the miners are inactive: everything is showing zeroes, even after I refresh the screen. I'm happy that it's successfully mining, but the whole reason I bought these things was to resell them and set them up for normies that want to get into mining in a plug-and-play manner. If the web dashboard doesn't work, that defeats a lot of the purpose for my use case.

Are there logs I need to look at? An update I need to run?

[n0nce]

The web dashboard still shows that the miners are inactive: everything is showing zeroes, even after I refresh the screen.

Tried full reboot? Dashboard can be dodgy at times. Reboot is often easier than manually digging for services to restart, because obviously it restarts everything.

[Bude Stacks]

The web dashboard still shows that the miners are inactive: everything is showing zeroes, even after I refresh the screen.

Tried full reboot? Dashboard can be dodgy at times. Reboot is often easier than manually digging for services to restart, because obviously it restarts everything.

I bet you changed the time zone on the OS. @thak777

Same thing happened to me yesterday. Miner kept running fine according to slushpool, but all stats were empty.  

Preformed a system reboot and everything has been problem free since then.

[Wattsdass]

My apollo(batch 3) is mining, however dashboard is frozen and nothing is responding. New to this…..
Please help!

[ROcrypto]

If anyone is interested in buying a full node+psu at an extremely discounted price, message me.

I have absolutely no desire to be apart of FutureBit with the obvious coding flaws that's allowed some sort of exploit through that's caused a great deal of us to all experience the same exact thing.

I'm currently mining 7 different coins with a dozen or so different miner manufacturers, Helium, a couple weather stations, GEOD navigators, etc... this is the only product I own I truly feel has a potential to completely compromise my entire network by the obvious back doors on these units.

First 400 takes it, it's less than 2 weeks old, I'll even throw in free expedited shipping.

Let's stop with the fear mongering please. Only you and one other person has reported this, and support has been in touch with one of you. Its been determined the issue is because you guys chose to expose your Apollo to the whole internet for anyone to attack. This akin to leaving your Bitcoin wallet on a table outside, publicly yelling out your address and telling everyone come and take it.

The issue is with forwarding our webUI to the open internet. The webui is not a server grade hardened frontend, its designed for easy access and control of your Apollo from your LAN. While you can forward your WAN port 80 so you can bring your UI up from any and device/place what you are doing is essentially hosting it as a public web page that anyone can try to attack, and this is precisely what happened.

Simply remove those port forwards and you will be fine(or go through the process of turning your Apollo into a hardened server grade web server). If you really want to be able to access your Apollo from outside your LAN in an easy and more secure way, then setup a remote access app directly in the desktop environment.

I had issues with the pool switching and I have replaced the root and dashboard password, I ONLY have port 83333 forwarded but after I made the miner_config file READ ONLY I have no more issues, still I think the issue is not outside the network but inside the futurebit os or Ubuntu.  I will be happy to send you logs to see if you can find anything suspicious but I will need instructions on how to do it. So to be clear, I REPEAT, the only forwarded port is 83333 and I have replaced the root password after I have noticed the issues with the pool which started after i turned the miner on after it fully synced the bitcoin node. The password change did not stop the pool switching, the only thing it stopped it was making that config file read only so there is something in the software that tries to change the pool. Now the fact that it happened on 2 Apollo units, mine is a week old, i think it cannot be a coincidence....I would like the manufacturer to look more into this please....

[itskeule]

I had issues with the pool switching and I have replaced the root and dashboard password, I ONLY have port 83333 forwarded but after I made the miner_config file READ ONLY I have no more issues, still I think the issue is not outside the network but inside the futurebit os or Ubuntu.  I will be happy to send you logs to see if you can find anything suspicious but I will need instructions on how to do it. So to be clear, I REPEAT, the only forwarded port is 83333 and I have replaced the root password after I have noticed the issues with the pool which started after i turned the miner on after it fully synced the bitcoin node. The password change did not stop the pool switching, the only thing it stopped it was making that config file read only so there is something in the software that tries to change the pool. Now the fact that it happened on 2 Apollo units, mine is a week old, i think it cannot be a coincidence....I would like the manufacturer to look more into this please....

To pinpoint the problem, do the following:

- make sure no other network component is compromised (if in doubt, turn off all other equipment)
- reflash the Apollo OS with a brand new SD card (don't use the current one)
- remove the SSD (which holds the blockchain) from the machine (to make sure no bogus app has been installed on the NVME drive)
- disable port forwarding 8333 on your router (and any other forward if such one exist)

1) Turn on the Apollo and make sure the mining process is disabled - enter your pool credentials.
2) Next, connect to the Apollo via SSH (from a trusted source), or if you have a monitor/keyboard attached, open a terminal session.

3) To see if something is happening to the miner config file, enter the following command:

Code:

watch cat /opt/apolloapi/backend/apollo-miner/miner_config

(you should see your correct pool URL with your credentials)
The 'watch' command updates the file contents every 2 seconds. If the config file is altered, you'll see it.

4) Now turn on the miner process from within the dashboard. (Have a look at the 'watch' output - is there a credential change?)
If NO, let the machine run for a few hours to make sure the miner behaves as normal.

Next, turn off the miner process and the Apollo and reinstall the NVME disk. Repeat step 1) and following.
If there is no change in the miner_config, that's good.

Now enable port forwarding 8333 to your Apollo. Repeat step 1 ...

If, at some point, your credentials are being changed, report back when this was gonna happen.

Good luck.

[n0nce]

So to be clear, I REPEAT, the only forwarded port is 83333

First of all, why are you doing that? It's not required to forward that port to run a full node.

The password change did not stop the pool switching, the only thing it stopped it was making that config file read only so there is something in the software that tries to change the pool.

Of course, if someone planted a script on your machine that periodically goes to the config file and changes the pool settings, changing password doesn't help, because they're already inside.

I am myself considering installing my own Linux distro on mine & connecting the Apollo 'to itself' using a short USB-A => Micro-USB cable, in light of these vulnerability reports. Had no issues with it so far, though.

[ROcrypto]

So to be clear, I REPEAT, the only forwarded port is 83333

First of all, why are you doing that? It's not required to forward that port to run a full node.

The password change did not stop the pool switching, the only thing it stopped it was making that config file read only so there is something in the software that tries to change the pool.

Of course, if someone planted a script on your machine that periodically goes to the config file and changes the pool settings, changing password doesn't help, because they're already inside.

I am myself considering installing my own Linux distro on mine & connecting the Apollo 'to itself' using a short USB-A => Micro-USB cable, in light of these vulnerability reports. Had no issues with it so far, though.

In the setup guide it is mentioned to forward port 83333 to have maximum node connections....I did what it says there...I am no Linux expert so I followed the guide...

[SpeedForceGN]

The web dashboard still shows that the miners are inactive: everything is showing zeroes, even after I refresh the screen.

Tried full reboot? Dashboard can be dodgy at times. Reboot is often easier than manually digging for services to restart, because obviously it restarts everything.

I bet you changed the time zone on the OS. @thak777

Same thing happened to me yesterday. Miner kept running fine according to slushpool, but all stats were empty. 

Preformed a system reboot and everything has been problem free since then.

What does changing the time zone do? What time zone is it suppose to be set too?

[unicornmangle]

After running my full node for a week and not being able to change the default username and password for the account without crippling the cobbled together software which seems to be some combination of minera mixed with other packages and many other libraries. you say dont forward port 8333 to run a full node thats kind of opposite of how these were advertised also the nag message on the mining screen needing to open port 8333 on router. Also upnp is a terrible idea to have open on a router the default config should be upnp=0.

All the javascript and webui on the main node was a mistake and will probably continue to be a mistake. they were fun to play with but my miners are disconnected and won't ever see a power source or internet again. One hashboard died on day 4 works for about 20 minutes then disables itself these are not plug in play and should not be advertised as such. i see no mention of any warranty on your website(doesnt matter to me as mine are going in the trash).

Sorry if i seem biter the project looked great and i had high expectations, but ive been nothing but burnt from every miner brand i could get my hands on. i think mining is just not for me i dont have enough money to play.

[heslo]

After running my full node for a week and not being able to change the default username and password for the account without crippling the cobbled together software which seems to be some combination of minera mixed with other packages and many other libraries. you say dont forward port 8333 to run a full node thats kind of opposite of how these were advertised also the nag message on the mining screen needing to open port 8333 on router. Also upnp is a terrible idea to have open on a router the default config should be upnp=0.

All the javascript and webui on the main node was a mistake and will probably continue to be a mistake. they were fun to play with but my miners are disconnected and won't ever see a power source or internet again. One hashboard died on day 4 works for about 20 minutes then disables itself these are not plug in play and should not be advertised as such. i see no mention of any warranty on your website(doesnt matter to me as mine are going in the trash).

Sorry if i seem biter the project looked great and i had high expectations, but ive been nothing but burnt from every miner brand i could get my hands on. i think mining is just not for me i dont have enough money to play.

If you're just throwing em away, send em to me; I'll happily pay shipping

[thak777]

The node finally finished syncing last night.

When I came to check on the machine this morning, it was no longer showing the USB device as connected. Couple of questions:

1) Is there a command I can use to force the device to reconnect?

2) Are there logs somewhere that can help me identify what's going on?

[SpeedForceGN]

The node finally finished syncing last night.

When I came to check on the machine this morning, it was no longer showing the USB device as connected. Couple of questions:

1) Is there a command I can use to force the device to reconnect?

2) Are there logs somewhere that can help me identify what's going on?

What USB device? Flash card or mouse/key board?