RaspberryPi wallet will not make connection with peers

  • Hey,

    I'm having a problem with one of my raspberry pi's that I'm using to stake. I have two set up, and one is working fine, however the other will not connect.

    I have re-installed multiple times, tried previous versions, newest version etc. I updated both Pi's but no matter what I do one of them will not work! I have even re installed Raspbian on different SD cards and even used a new Raspberry Pi out the box.... Still nothing.

    When I compare the debug files of the working and not working they are not the same, but being a bit of a noob I don't really know what I am looking at. Is there anyone that knows why this would be happening? Is there a way to kick start the connection to start the block sync? Any help would be greatly appreciated! Thanks!

  • Provided you are on the same network segment, then the firewall/router should not be blocking the connection from the 3rd RPi.

    Some people have had success using the addnode command to "jump start" a wallet. You can grab some nodes off your other wallets and give it a try. Here is the format:

    addnode "node" "add|remove|onetry"

    Attempts add or remove a node from the addnode list.
    Or try a connection to a node once.


    1. "node" (string, required) The node (see getpeerinfo for nodes)
    2. "command" (string, required) 'add' to add a node to the list, 'remove' to remove a node from the list, 'onetry' to try a connection to the node once


    qtum-cli addnode "" "onetry"
    curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "addnode", "params": ["", "onetry"] }' -H 'content-type: text/plain;'
    (code -1)

  • jb395,

    Thank you so much for replying to my post, I managed to use the getpeerinfo from the other RPi and copied and pasted all the addresses for the connected nodes in using the "add" command, and it finally made connection with peers and started to sync the blocks.

    I then copied in my backup file and let it sync. Upon coming back to it and using the "getinfo" command to check progress I got an error returned back to me... "read oldest key in keypool failed". Is this because I didnt let it sync before I uploaded my backup? I did get it running again after anyway and I am back online but I was just curious?

    Aside from this other query, I have a some questions regarding my initial problem...

    • Does this mean now that my wallet will not connect after rebooting unless I manually add the nodes every time?

    • If so, is there a way to add all available nodes in one?

    • Upon checking the debug file of the "working" wallet on my other Pi, I noticed a lot of failed attempts to nodes with the following messages:

      • connect() to failed after select(): Connection refused (111)

      • connect() to failed after select(): No route to host (113)

      • connect() to failed after select(): Network is unreachable (101)

        (Mainly Connection refused (111) & No route to host (113).)

    And another couple of errors:

    • ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 1af8......., time-too-new, block timestamp too far in the future (code 16)

    • ERROR: invalid header received

    Are these all normal?

    Thanks again for taking the time to respond and help!

  • Good questions!

    1. No the oldest key and keypool is a different issue. The wallet manages a pool of 100 private keys, that it uses for various transactions. This is a lot of keys though, so I wouldn’t worry about this message unless you have problems with a particular address in the wallet. However, you should never do staking (mining) using an address with more than one wallet. Using the same wallet.dat file and mining from two wallets will cause difficult problems.

    2. Probably not. Once your wallet is connecting to peers it should be able to keep track of them better. It creates a “peers.dat” file, which I think, helps it remember some good nodes.

    3. Your staking wallet is a full node on the Qtum network. That means it “sees” all the transactions and blocks that are sent to the network from 7,000 other nodes, and some of those nodes are going to have problems. Your wallet will be continuously disconnecting and connecting to new nodes (those are their IP addresses you see logged). Your wallet will also see blocks with bad timestamps “time-too-new”. This is the important work the wallet/full node does securing the network, that the bad traffic gets tossed out. I recently wrote a blog about the debug log, if you would like to read more about it https://medium.com/@jb395official/the-debug-log-the-virtual-machine-log-march-13-2018-76ddbe568f2

  • jb395,

    Really appreciate you clarifying these questions for me. So far the RPi is running fine, I don't stake the same wallet.dat on separate devices simultaneously, I was just mining on the Desktop GUI Wallet on my PC while I was fixing the issue, other than that I just open the GUI when I want to check the balance.

    Hopefully not, but otherwise I know what to do now!! The "peers.dat" file is always there even after deleting and rebooting, but must have been empty file, hopefully now its not any more.

    Yes I noticed the debug file on the recently working RPi and it had all the same messaged which made me think it was normal! But clarification is always good. When I get a bit more spare time I will check out your blog and try to understand some more.

    Once again, Thank you very much

Log in to reply