cannot connect anymore to peers

[altagir]

since 4 days (4 february) I cannot sync anymore to network

I also try to port forward 8888 with no succes. any idea ?

in ~/.hush/debug.log

2018-02-08 19:31:31 socket recv error Connection reset by peer (104) 2018-02-08 19:31:31 connect() to [2001:0:9d38:953c:1ca7:e871:a472:fde9]:8888 failed: Network is unreachable (101) 2018-02-08 19:31:32 socket recv error Connection reset by peer (104) 2018-02-08 19:31:33 connect() to [2001:0:9d38:90d7:c8f:3875:b635:d6a8]:8888 failed: Network is unreachable (101) 2018-02-08 19:31:39 socket recv error Connection reset by peer (104) 2018-02-08 19:31:40 connect() to 46.147.23.0:8888 failed after select(): Connection refused (111) 2018-02-08 19:31:41 socket recv error Connection reset by peer (104) 2018-02-08 19:31:48 socket recv error Connection reset by peer (104) 2018-02-08 19:31:50 socket recv error Connection reset by peer (104) 2018-02-08 19:31:55 connect() to [2001:0:4137:9e76:c60:6ad2:2ac8:4f36]:8888 failed: Network is unreachable (101) 2018-02-08 19:31:56 socket recv error Connection reset by peer (104) 2018-02-08 19:31:57 socket recv error Connection reset by peer (104) 2018-02-08 19:31:58 socket recv error Connection reset by peer (104) 2018-02-08 19:31:59 socket recv error Connection reset by peer (104) 2018-02-08 19:32:05 connect() to [2a01:cb08:5c:300:35e9:622f:2ab0:29f4]:8888 failed: Network is unreachable (101) 2018-02-08 19:32:11 connect() to [2001:0:4137:9e76:4de:3453:b992:c6b9]:8888 failed: Network is unreachable (101) 2018-02-08 19:32:12 connect() to [2001:0:9d38:6abd:c5d:c204:a88b:4f82]:8888 failed: Network is unreachable (101) 2018-02-08 19:32:14 socket recv error Connection reset by peer (104) 2018-02-08 19:32:14 socket recv error Connection reset by peer (104) 2018-02-08 19:32:15 socket recv error Connection reset by peer (104)

[altagir]

alternatively how can I download current blocks ? I fixed ipv6 unreachable yet

2018-02-09 18:40:54 socket recv error Connection reset by peer (104) 2018-02-09 18:40:56 socket recv error Connection reset by peer (104) 2018-02-09 18:41:07 connect() to 163.172.70.26:8888 failed after select(): Connection refused (111) 2018-02-09 18:41:14 connect() to 173.212.196.148:8888 failed after select(): Connection refused (111) 2018-02-09 18:41:15 socket recv error Connection reset by peer (104) 2018-02-09 18:41:26 connect() to 163.172.70.26:8888 failed after select(): Connection refused (111) 2018-02-09 18:41:26 connect() to 192.99.3.29:8888 failed after select(): Connection refused (111) 2018-02-09 18:41:32 connect() to 163.172.64.208:8888 failed after select(): Connection refused (111) 2018-02-09 18:41:33 connect() to 37.187.167.145:8888 failed after select(): Connection refused (111)

[johnny-b2]

Hi, I have the same problem and can't find a solution. The hushd wallet/node can't connect. It is few days. I was experimenting with some parameters and after i used -salvagewallet, then it connected again. Because I tried -reindex before it was start syncing again. Then it synced, but I'm not sure if it was 100% synced. Now it is synced at block 251139 and again - can't connect to any node. Tried -reindex and -salvagewallet, but it is not working now. Also tried to backup wallet.dat. Deleted all the content of /home/user/.hush folder. Generate new config from config generator on myhush website. Also tried to add a list of nodes from README.md. But no luck. Still not syncing. It doesn't matter what ISP I'm using.

This is frustrating. I can't find no help on the Internet. Anybody with any help, please?

2018-02-09 20:26:35 Loaded 883 addresses from peers.dat  5ms
2018-02-09 20:26:35 dnsseed thread start
2018-02-09 20:26:35 net thread start
2018-02-09 20:26:35 addcon thread start
2018-02-09 20:26:35 opencon thread start
2018-02-09 20:26:35 msghand thread start
2018-02-09 20:26:40 socket recv error Connection reset by peer (104)
2018-02-09 20:26:46 Loading addresses from DNS seeds (could take a while)
2018-02-09 20:27:33 connect() to 104.236.118.65:8888 failed after select(): Connection refused (111)
2018-02-09 20:30:26 connect() to [2001:0:9d38:78cf:2cff:e69e:4de7:515]:8888 failed: Network is unreachable (101)
2018-02-09 20:30:26 3 addresses found from DNS seeds
2018-02-09 20:30:26 dnsseed thread exit

This is part of debug.log just after I started node. It can run several hours but no connection.

[altagir]

about ipv6 adresses, I couldn't even ping address (Network is unreachable) so i install package miredo you will have a new teredo entry in your network interfaces with an ipv6 adress so now you will also have "Connection refused" using ipv6 (and not Network is unreachable)

telneting on ipv4 adress with 8888 gives connection refused, while testing my external ip adress and husd running functions properly

I am trying reindex, and just see it just start downloadingeverything again :( will see if it stops at same point... in logs i see a lot of
LoadExternalBlockFile: Processing out of order child ....

[altagir]

reindexing solved my issue I use hush swing wallet UI to check 100% @johnny-burak try also -upgradewallet. just using index solved it, but thought it was related

[altagir]

well that just worked for a day... next day same issue, cannot connect to peers.. any DEV feedback here? or do we have to download from scratch every day ?

[mawenpeng]

I have similar issues although I set "addnode" in hush.conf. Maybe my network issues?

[altagir]

I ruled out network issues. connection is refused by other servers and database seems corrupted

I suspect a bad closure of daemon (using Ctrl-C instead of hush-cli stop?) or else the swing hush ui is corrupting database

[altagir]

can you guys check in your debug.log if you have such thing: 2018-02-11 18:30:55 ERROR: CheckEquihashSolution(): invalid solution 2018-02-11 18:30:55 ERROR: CheckBlockHeader(): Equihash solution invalid

[altagir]

I also realized that doing : hush-cli listreceivedbyaddress 0 true shows only one of my adress with 0 coins, while the one used is not shown

HUSH swing wallet is showing the 2 address

it is definitely a database corruption.. 2 clients have different info. or have diffrerent protocol

I guess i am due for my daily 1.8 gb download reindexing and banning swing wallet for now tocheck that

DEV team, your feedback will be appreciated so we know HUSH is not a dead coin. thanks

[johnny-b2]

@altagir I've tried your suggestion -upgradewallet. When I run it then it showed me that can't load blocks and I have to use -reindex. :-/ So I run in with -reindex oprtion - again. Now it is running reindexing but still 0 connections. Tha wallet is unusable like this. I cannot access my coins :-/ I have backup of wallet.dat and exported private key. But there is no other wallet I can use :-/

[johnny-b2]

@altagir export and backup your private key when you have loaded wallet.dat from your backup (you can see your coins), then run hush-cli dumpprivkey "hushaddress" (adress with your coins). That is extra backup if we can find another working wallet program we can get to our coins by importing private key. If I understand well there is 1 private key to every hush address, so if you have more addresses with your coins then you have to backup private keys from all your addresses.

[leto]

@altagir try

addnode=explorer.myhush.org
addnode=stilgar.myhush.org

to help with your syncing problems. The error LoadExternalBlockFile: Processing out of order child does sound like you CTRL-C'ed or perhaps filled up a harddrive, it's not a common error, but as you found, a reindex will fix it.

[altagir]

@leto

• the 2 nodes were present in my hush.conf
• Ctrl-C is normally caught by program, and hush is closed normally
• I just finished reindexing and then use hush-cli stop, wait a bit, restart daemon, and same problem as before. stuck

so in bried,every time I stop the daemon, it will fail again. and i have to reindex next time

[altagir]

started a fresh .hush while importing my private keys just used hush-swing-ui to start stop server let it run all night, restarted it and :

- : Error loading block database.
Please restart with -reindex to recover.

and logs during indexing are

2018-02-12 16:59:11 UpdateTip: new best=00000515836c34064ced2692355166c074a02739e22a2c2927ffef3618c36863  height=13215  log2_work=37.01185  tx=25588  date=2016-12-14 15:40:29 progress=0.066038  cache=6.2MiB(8230tx)
2018-02-12 16:59:11 LoadExternalBlockFile: Processing out of order child 000004b3e51436b879121206f1d43875a429b5dbfe5d13ac8f1988d74a768c2d of 00000515836c34064ced2692355166c074a02739e22a2c2927ffef3618c36863

this was a fresh database.... lots of HD space, no interruption, and I am not the only one with this issue starting to be fed up to reindex at every use and download one Gb evey day, is there any other client?

[johnny-b2]

Ok, my testing continue. After your suggestion -upgradewallet and error - : Error loading block database. Please restart with -reindex to recover. I run -reindex yesterday.

During reindex process there was 0 connections at the beginning (i think at least 1 hour). Then I have 4 connections and sync go up to 100% - yes.

Then I go to sleep and exit hush with Ctrl+C as if you don't run hushd as daemon you can see at terminal [Press Ctrl+C to exit]. In the debug.log after Ctrl+C hushd is

2018-02-11 22:14:51 connect() to [2a02:c7d:b3a0:1300:9c8a:5c6:67fd:8853]:8888 failed: Network is unreach able (101) 2018-02-11 22:15:49 tor: Thread interrupt 2018-02-11 22:15:49 torcontrol thread exit 2018-02-11 22:15:49 msghand thread interrupt 2018-02-11 22:15:49 scheduler thread interrupt 2018-02-11 22:15:49 net thread interrupt 2018-02-11 22:15:49 addcon thread interrupt 2018-02-11 22:15:53 opencon thread interrupt 2018-02-11 22:15:53 Shutdown: In progress... 2018-02-11 22:15:53 StopRPC: waiting for async rpc workers to stop 2018-02-11 22:15:53 StopNode() 2018-02-11 22:15:53 Shutdown: done

The same output on debug.log is after I run hush-cli stop. So I don't understand why Ctrl+C is bad when it is same as run hush-cli stop.

Today I run hushd. I had 0 connections for almost 30 minutes and I have now 1 wierd connection because I'm at block 255947 but last block at blockachain now is 256471. Also wallet validated 815 transactions at the start of the program and no more. So there is definitely something wrong.

I have similar wallets - zend, zclassic and they are working fine. When I sync the wallet to 100% and I end it with Ctrl+C (as is advised) the next run it connect in few minutes to 8 nodes and syncing the missed blocks.

What is wrong with hushd? Is there any other wallet for hush? I really don't want to reindex every time I run hushd wallet - the syncing take almost 3 hours and it is heavy on CPU load and network data download.

[altagir]

I was about to write than using just the SWING ui was working after a reindex worked 3 times exactly (closing, reopening, synching)

but it is not anymore right now, so giving up

[fellu]

Same here. Working after -reindex, but after closing and waiting some time it will find 0 connections and have to resync again to get connections back. After resync it working untill closing.

[todw1fd]

Same experience and very frustrating. Ctrl-c should cause a graceful shutdown and yet often it does not. After the reindex, leaving daemon running and opening swing-ui...swing-ui works fine and shows 8 to 10 connections and shows fully sync'd. Shut down the gui, then shut down (or attempt to )the daemon with ctrl-c (log doesn't show daemon stopped at this point), end up having to close the command prompt window to stop the process. Not a good solution and of course, restarting the swing wallet ui next time without a re-index and you're SOL. Wishing the devs luck and speed in finding a fix.

[altagir]

@todw1fd , you can also use

hush-cli stop

[johnny-b2]

In my case Cttr+C working exactly the same as hush-cli stop. In both cases there is graceful shutdown in the debug.log. In all situations I have to reindex to get any connections.

[thirdorderharmonic]

I have the same issue with closing the windows swing wallet. Glad to see I'm not alone. Nodes in .conf are current and work fine if i delete the chainstate and blocks folders or if i use the -reindex command. Otherwise I can't get to 100% sync unless I leave the wallet open at all times after the reindex.

[FireMartZ]

For sure caused by https://github.com/MyHush/hush/pull/98 and thus fixed in https://github.com/MyHush/hush/tree/v1.0.13-rc which is expected to be released soon.

[altagir]

testing v1.0.13-rc branch, reindexing right now do you know when it is going to be merged in master? also you have wrong labelling in v1.0.13, version is still 1.0.12

[FireMartZ]

There is no need to reindex with 1.0.13, even if 1.0.12 was asking for reindexing.

Where do you see the 1.0.12 label?

You should get this when running hushd --version : Hush Daemon version v1.0.13-afad8af and this when running hush-cli --version : Hush RPC client version v1.0.13-afad8af

[altagir]

actually was my Makefile not updated. I used directly ./zcutil/build-debian-package.sh

even using the build script, after a make distclean

/crypto/wallets/hush$ grep 1.0.12 *

config.status:This file was extended by Zcash $as_me 1.0.12, which was config.status:Zcash config.status 1.0.12 config.status: VERSION='1.0.12' config.status:S["VERSION"]="1.0.12" config.status:S["PACKAGE_STRING"]="Zcash 1.0.12" config.status:S["PACKAGE_VERSION"]="1.0.12" config.status:D["PACKAGE_VERSION"]=" \"1.0.12\"" config.status:D["PACKAGE_STRING"]=" \"Zcash 1.0.12\"" libtool:# Generated automatically by config.status (zcash) 1.0.12 libzcashconsensus.pc:Version: 1.0.12 Makefile:PACKAGE_STRING = Zcash 1.0.12 Makefile:PACKAGE_VERSION = 1.0.12 Makefile:VERSION = 1.0.12 README.md:A HUSH GUI Wallet

[leto]

@FireMartZ @altagir I don't believe we have an updated Debian package for 1.0.13 yet, it may show an incorrect version number or not work at all. Use the source tarball or git repo to get the correct source

[FireMartZ]

I just checked out https://github.com/MyHush/hush/tree/v1.0.13 and ran ./zcutil/build.sh && ./zcutil/build-debian-package.sh and got hush-1.0.13-afad8af-amd64.deb which looks fine and version was set to 1.0.13

Can you try again?

[altagir]

@leto, @FireMartZ , I used the tarball and had correct name hush-1.0.13-gafad8af54-amd64.deb with a clean install

previously I was using the git branch 1.0.13. but even a distclean kept old makefile

[altagir]

Problem seem fixed, many thanks @leto @FireMartZ

[johnny-b2]

I just upgraded hush node to v. 1.0.13. Run it and it connected in few seconds to 7 (TLS: 3) nodes and start syncing. Thank you very much for fixing the sync issue. Great work. Keep it up :+1: I believe hush is very good project and I will keep supporting it.