You are making it much harder than needed. The seednode in the source should be like coin.seednode.org - Then you point that DNS to your node(s). When it looks for a seednode it looks for a list of IPs to basically addnode
This is why you only have connections through addnodes
Topic: Help with DNS Seeder and hardcoded Seednodes - page 2. (Read 5208 times)
It's going to be very hard to see where the connection is blocked from where you're standing but my bet is that a firewall policy above and beyond the access your hosting company provides to you is intercepting the traffic before it hits your seed node. The tech guys at DotEasy helpdesk probably won't have a clue what the problem is but I bet their network and security guys do if they were asked to look into it.
Another option is to set up SSL certificates between your web server and a test machine to see if that resolves the trust issue but my gut feeling is that it won't because access is being blocked at a different level altogether.
I may be wrong on the above but spent days and days of serious headaches with one faucet and as soon as everything was migrated to a VPS, the dreaded 111 error was solved almost instantly. With seed nodes you don't have databases, usernames and password etc to throw further spanners into the works, so troubleshooting the issues should be a bit easier (famous last words).
It's pretty setting easy up a VPS and I can provide you a DigitalOcean one for a few days if it's of any help?
P.S. Are you 100% sure that you've changed your port numbers in the seeder's bitcoin.cpp, main.cpp, protocol.cpp and protocol.h files before you compiled it?
Another option is to set up SSL certificates between your web server and a test machine to see if that resolves the trust issue but my gut feeling is that it won't because access is being blocked at a different level altogether.
I may be wrong on the above but spent days and days of serious headaches with one faucet and as soon as everything was migrated to a VPS, the dreaded 111 error was solved almost instantly. With seed nodes you don't have databases, usernames and password etc to throw further spanners into the works, so troubleshooting the issues should be a bit easier (famous last words).
It's pretty setting easy up a VPS and I can provide you a DigitalOcean one for a few days if it's of any help?
P.S. Are you 100% sure that you've changed your port numbers in the seeder's bitcoin.cpp, main.cpp, protocol.cpp and protocol.h files before you compiled it?
I've decided on self hosting and after many support tickets and phone calls I now have DotEasy pointing my webhost NS records to my master and slave VPS name servers.
However, while the dnsseeder now shows DNS requests and db queries, it does not appear to be logging my client IP addresses nor is it reciprocating information to peers attempting a DNS request. This is reflected in
dnsstats.log
1411083359 0 0 0 0 0
1411083559 0 0 0 0 0
1411083959 0 0 0 0 0
1411084759 0 0 0 0 0
and in dnsseed.dump, which is empty.
On the DNS Seeder I get the following output;
$ 0/1 available (1 tried in 800s, 0 new, 0 active), 0 banned; 48 DNS requests, 4 db queries
On my clients I get the following;
...
1 addresses found from DNS seeds
dnsseed thread exit
connect() to 104.131.20.192:9751 failed after select(): Connection refused (111)
connect() to 104.131.20.192:9751 failed after select(): Connection refused (111)
Cannot connect to kjy2eqzk4zwi5zd3.onion:9751: unsupported network
Cannot connect to kjy2eqzk4zwi5zd3.onion:9751: unsupported network
connect() to 104.131.20.192:9751 failed after select(): Connection refused (111)
Cannot connect to kjy2eqzk4zwi5zd3.onion:9751: unsupported network
Using bind9 my DNS is set up as follows;
Master
/etc/hosts
127.0.0.1 localhost
127.0.1.1 ns1.cryptodistributed.org ns1
#
/etc/hostname
ns1
#
/etc/bind/named.conf.options
options {
directory "/var/cache/bind";
recursion no;
allow-transfer { none; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
#
/etc/bind/named.conf.local
zone "cryptodistributed.org" {
type master;
file "/etc/bind/zones/db.cryptodistributed.org";
allow-transfer { 104.131.18.252; };
};
zone "55.131.104.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.104.131.55";
};
#
/etc/bind/zones/db.cryptodistributed.org
$TTL 604800
@ IN SOA ns1.cryptodistributed.org. email.cryptodistributed.org. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers
cryptodistributed.org. IN NS ns1.cryptodistributed.org.
cryptodistributed.org. IN NS ns2.cryptodistributed.org.
seed.cryptodistributed.org. IN NS 104.131.20.192.
; A records for name servers
ns1 IN A 104.131.55.112
ns2 IN A 104.131.18.252
seed IN A 104.131.20.192
; Other A records
@ IN A 104.131.53.44
www IN NS 104.131.53.44
#
/etc/bind/zones/db.104.131.55
$TTL 604800
@ IN SOA example.com. admin.example.com. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers
IN NS ns1.cryptodistributed.org.
IN NS ns2.cryptodistributed.org.
; PTR records
112 IN PTR ns1.cryptodistributed.org.
252.18 IN PTR ns2.cryptodistributed.org.
44.53 IN PTR www.cryptodistributed.org.
192.20 IN PTR seed.cryptodistributed.org.
#
Curiously, nslookup and dig do not give the expected output.
Specifically, they are not returning an authorative NS record for subdomain seed.cryptodistributed.org. I had read that bind may be stripping off the authorative answer bit in the reply, https://www.mail-archive.com/[email protected]/msg05514.html, but I am not not sure how I might fix such a problem or whether I may have made some error elsewhere.
I'm going to try hosting the website on a vps and see if that resolves the issue.
Thank you very much for offering a vps for a few days but I've already got a few cheap digitalocean vps'.
I re-checked the ports on the seeder for sanity and it looks fine.
Thank you very much for offering a vps for a few days but I've already got a few cheap digitalocean vps'.
I re-checked the ports on the seeder for sanity and it looks fine.
It's going to be very hard to see where the connection is blocked from where you're standing but my bet is that a firewall policy above and beyond the access your hosting company provides to you is intercepting the traffic before it hits your seed node. The tech guys at DotEasy helpdesk probably won't have a clue what the problem is but I bet their network and security guys do if they were asked to look into it.
Another option is to set up SSL certificates between your web server and a test machine to see if that resolves the trust issue but my gut feeling is that it won't because access is being blocked at a different level altogether.
I may be wrong on the above but spent days and days of serious headaches with one faucet and as soon as everything was migrated to a VPS, the dreaded 111 error was solved almost instantly. With seed nodes you don't have databases, usernames and password etc to throw further spanners into the works, so troubleshooting the issues should be a bit easier (famous last words).
It's pretty setting easy up a VPS and I can provide you a DigitalOcean one for a few days if it's of any help?
P.S. Are you 100% sure that you've changed your port numbers in the seeder's bitcoin.cpp, main.cpp, protocol.cpp and protocol.h files before you compiled it?
Another option is to set up SSL certificates between your web server and a test machine to see if that resolves the trust issue but my gut feeling is that it won't because access is being blocked at a different level altogether.
I may be wrong on the above but spent days and days of serious headaches with one faucet and as soon as everything was migrated to a VPS, the dreaded 111 error was solved almost instantly. With seed nodes you don't have databases, usernames and password etc to throw further spanners into the works, so troubleshooting the issues should be a bit easier (famous last words).
It's pretty setting easy up a VPS and I can provide you a DigitalOcean one for a few days if it's of any help?
P.S. Are you 100% sure that you've changed your port numbers in the seeder's bitcoin.cpp, main.cpp, protocol.cpp and protocol.h files before you compiled it?
It's kinda clutching at straws here but could there be any kind of firewall or router blocking the connection?
Bitcoin 111 errors are because of RPC access being blocked. Although slightly different, I've had nightmare problems in the past with faucets that refuse connections when used on webhosts rather than a dedicated VPS setup. Even jailbroken hosting plans don't give as much access as they would have you believe.
An NS record is pretty important and a lot of hosts won't allow you to change one (even if you ask their support for a record change). If you come up against a brick wall, my suggestion is that you try to host the seeder and website yourself on a cheap VPS. You can't beat DigitalOcean's VPSs for the flexibility you get at such a small cost if you find that the hosts aren't accommodating your requests.
Bitcoin 111 errors are because of RPC access being blocked. Although slightly different, I've had nightmare problems in the past with faucets that refuse connections when used on webhosts rather than a dedicated VPS setup. Even jailbroken hosting plans don't give as much access as they would have you believe.
An NS record is pretty important and a lot of hosts won't allow you to change one (even if you ask their support for a record change). If you come up against a brick wall, my suggestion is that you try to host the seeder and website yourself on a cheap VPS. You can't beat DigitalOcean's VPSs for the flexibility you get at such a small cost if you find that the hosts aren't accommodating your requests.
The connection isn't blocked, as far as I can tell, and netstat shows the dnsseed listening on port 53.
I'm using DotEasy as my webhost which could be the problem. I've changed my NS record to point to my vps rather than the subdomain, but I'll have to wait for the change to take effect before I can confirm that it was the issue. Considering their support had no idea what I was talking about I'll probably have to try hosting the website on a vps.
Any thoughts on why the client isn't connecting to previously connected peers?
It's kinda clutching at straws here but could there be any kind of firewall or router blocking the connection?
Bitcoin 111 errors are because of RPC access being blocked. Although slightly different, I've had nightmare problems in the past with faucets that refuse connections when used on webhosts rather than a dedicated VPS setup. Even jailbroken hosting plans don't give as much access as they would have you believe.
An NS record is pretty important and a lot of hosts won't allow you to change one (even if you ask their support for a record change). If you come up against a brick wall, my suggestion is that you try to host the seeder and website yourself on a cheap VPS. You can't beat DigitalOcean's VPSs for the flexibility you get at such a small cost if you find that the hosts aren't accommodating your requests.
Bitcoin 111 errors are because of RPC access being blocked. Although slightly different, I've had nightmare problems in the past with faucets that refuse connections when used on webhosts rather than a dedicated VPS setup. Even jailbroken hosting plans don't give as much access as they would have you believe.
An NS record is pretty important and a lot of hosts won't allow you to change one (even if you ask their support for a record change). If you come up against a brick wall, my suggestion is that you try to host the seeder and website yourself on a cheap VPS. You can't beat DigitalOcean's VPSs for the flexibility you get at such a small cost if you find that the hosts aren't accommodating your requests.
Hi esotericizm, thanks for the suggestion.
As far as I can tell the DNS appears to be properly configured;
$ nslookup seed.cryptodistributed.org
Server: 8.8.8.8
Address: 8.8.8.8:53
Non-authoritative answer:
Name: seed.cryptodistributed.org
Address: 104.131.53.44
however when I run:
dig -t NS seed.cryptodistributed.org
;;Question Section:
;seed.cryptodistributed.org. IN NS
;;AUTHORITY SECTION
cryptodistributed.org. IN SOA dns5.doteasy.com hostmaster.doteast.com
I contacted my hosting provider but they said it looks correct.
Re-reading https://bitcointalksearch.org/topic/a-basic-guidetutorial-for-creating-dns-seeders-599623 I'm now wondering if I should have created an NS record like so;
NS Record:
seed.cryptodistributed.org 104.131.53.44
Rather than;
cryptodistributed.org seed.cryptodistributed.org
As far as I can tell the DNS appears to be properly configured;
$ nslookup seed.cryptodistributed.org
Server: 8.8.8.8
Address: 8.8.8.8:53
Non-authoritative answer:
Name: seed.cryptodistributed.org
Address: 104.131.53.44
however when I run:
dig -t NS seed.cryptodistributed.org
;;Question Section:
;seed.cryptodistributed.org. IN NS
;;AUTHORITY SECTION
cryptodistributed.org. IN SOA dns5.doteasy.com hostmaster.doteast.com
I contacted my hosting provider but they said it looks correct.
Re-reading https://bitcointalksearch.org/topic/a-basic-guidetutorial-for-creating-dns-seeders-599623 I'm now wondering if I should have created an NS record like so;
NS Record:
seed.cryptodistributed.org 104.131.53.44
Rather than;
cryptodistributed.org seed.cryptodistributed.org
I find it easier just to manually edit the zone file config.
***************************************************
SOLUTIONS POSTED FOLLOWING QUESTIONS
***************************************************
I'm creating an altcoin based on Pfennig (https://github.com/project-bitmark/pfennig), the cloneable reference implementation of Bitmark (https://github.com/project-bitmark/bitmark), in order to gain a deeper understanding of cryptocurrency. This coin is not going to market. It's intended only as a means of educating myself about different cryptocurrencies and their inner workings.
Please don't poop on me with posts about crappy altcoins, etc.
The difficulties I'm experiencing are as follows;
1. Clients do not connect to seednodes;
chainparams.cpp
22 unsigned int pnSeed[] =
23 {
24 0x688312e4 // Updated seed node
25 };
After first run to set the rpcuser and rpcpassword, the daemon does not attempt to connect to hardcoded seed nodes.
In the above example, taken from the coin source, shows the hex IP of my VPS seednode at 104.131.20.192.
The VPS at 104.131.20.192 is set to listen using the following;
./betacoind -listen=1 -printtoconsole &
and reports the following;
Betacoin version v0.9.2.1-7ecf3af-dirty-beta (2014-08-16 21:43:28 -0400)
Using OpenSSL version OpenSSL 1.0.1e 11 Feb 2013
Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
Default data directory /home/ubox/.betacoin
Using data directory /home/ubox/.betacoin
Using at most 125 connections (1024 file descriptors available)
Using 8 threads for script verification
Using wallet wallet.dat
init message: Verifying wallet...
CDBEnv::Open : LogDir=/home/ubox/.betacoin/database ErrorFile=/home/ubox/.betacoin/db.log
Bound to [::]:9751
Bound to 0.0.0.0:9751
init message: Loading block index...
Opening LevelDB in /home/ubox/.betacoin/blocks/index
Opened LevelDB successfully
Opening LevelDB in /home/ubox/.betacoin/chainstate
Opened LevelDB successfully
LoadBlockIndexDB(): last block file = 0
LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=1, size=254, heights=0...0, time=2014-08-16...2014-08-16)
LoadBlockIndexDB(): transaction index disabled
LoadBlockIndexDB(): hashBestChain=c44dec01e2ba3f7d0376654b4fb790fd0e3e7c2996c389a57ca3e48270f1c57a height=0 date=2014-08-16 02:36:49 progress=0.000008
init message: Verifying blocks...
block index 126ms
init message: Loading wallet...
nFileVersion = 90201
Keys: 101 plaintext, 0 encrypted, 101 w/ metadata, 101 total
wallet 160ms
init message: Loading addresses...
Loaded 1 addresses from peers.dat 0ms
mapBlockIndex.size() = 1
nBestHeight = 0
setKeyPool.size() = 100
mapWallet.size() = 0
mapAddressBook.size() = 1
ext-ip thread start
dnsseed thread start
Loading addresses from DNS seeds (could take a while)
opencon thread start
addcon thread start
net thread start
msghand thread start
dumpaddr thread start
init message: Done loading
1 addresses found from DNS seeds
dnsseed thread exit
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
GetMyExternalIP() received [184.75.210.198] 184.75.210.198:0
GetMyExternalIP() returned 184.75.210.198
AddLocal(184.75.210.198:9751,4)
ext-ip thread exit
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
SOLVED:
https://bitcointalksearch.org/topic/m.8901349
https://bitcointalksearch.org/topic/m.1983185
2. Clients only connect when using -connect or -addnode commands;
After first run to set the rpcuser and rpcpassword, the daemon will only connect to another client if using -addnode or -connect commands.
Using the following command, I am able to connect a client to my seednode at 104.131.20.192 ;
./betacoind -listen=1 -connect=104.131.20.192 &
and successfully mine blocks using;
./betacoind -listen=1 -gen=1 -connect=104.131.20.192 &
SOLVED:
This was the result of improper pnSeed formatting and broken DNS seed. Peers now connect automatically via seednode or dns.
3. Client does not pull from peers.dat;
On all subsequent instances of the daemon no connection is made unless -connect or -addnode is specified.
The following instance of the daemon results in no connections despite having peers in the peer.dat file.
./betacoind -listen=1 -gen=1
Why is the client not pulling peers from the peer.dat file?
4. Clients are not able to connect to the DNS Seeder;
The DNS seeder shows no attempted connections.
I have my domain configured with both and A record and NS record as follows;
A Record:
seed.cryptodistributed.org 104.131.53.44
www.seed.cryptodistributed.org 104.131.53.44
NS Record:
cryptodistributed.org seed.cryptodistributed.org
Which appears to be functioning correctly as per
https://www.whatsmydns.net/#A/seed.cryptodistributed.org
The address of the dnsseed is entered as such in;
chainparams.cpp
64 vSeeds.push_back(CDNSSeedData("cryptodistributed.org", "seed.cryptodistributed.org"));
On the clients attempting to connect:
Betacoin version v0.9.2.1-7ecf3af-dirty-beta (2014-08-16 21:43:28 -0400)
Using OpenSSL version OpenSSL 1.0.1e 11 Feb 2013
Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
Default data directory /home/ubox/.betacoin
Using data directory /home/ubox/.betacoin
Using at most 125 connections (1024 file descriptors available)
Using 8 threads for script verification
Using wallet wallet.dat
init message: Verifying wallet...
CDBEnv::Open : LogDir=/home/ubox/.betacoin/database ErrorFile=/home/ubox/.betacoin/db.log
Bound to [::]:9751
Bound to 0.0.0.0:9751
init message: Loading block index...
Opening LevelDB in /home/ubox/.betacoin/blocks/index
Opened LevelDB successfully
Opening LevelDB in /home/ubox/.betacoin/chainstate
Opened LevelDB successfully
LoadBlockIndexDB(): last block file = 0
LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=1, size=254, heights=0...0, time=2014-08-16...2014-08-16)
LoadBlockIndexDB(): transaction index disabled
LoadBlockIndexDB(): hashBestChain=c44dec01e2ba3f7d0376654b4fb790fd0e3e7c2996c389a57ca3e48270f1c57a height=0 date=2014-08-16 02:36:49 progress=0.000008
init message: Verifying blocks...
block index 126ms
init message: Loading wallet...
nFileVersion = 90201
Keys: 101 plaintext, 0 encrypted, 101 w/ metadata, 101 total
wallet 160ms
init message: Loading addresses...
Loaded 1 addresses from peers.dat 0ms
mapBlockIndex.size() = 1
nBestHeight = 0
setKeyPool.size() = 100
mapWallet.size() = 0
mapAddressBook.size() = 1
ext-ip thread start
dnsseed thread start
Loading addresses from DNS seeds (could take a while)
opencon thread start
addcon thread start
net thread start
msghand thread start
dumpaddr thread start
init message: Done loading
1 addresses found from DNS seeds
dnsseed thread exit
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
GetMyExternalIP() received [184.75.210.198] 184.75.210.198:0
GetMyExternalIP() returned 184.75.210.198
AddLocal(184.75.210.198:9751,4)
ext-ip thread exit
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
On the DNS seeder:
./dnsseed -h seed.cryptodistributed.org -n 104.131.53.44
Starting 4 DNS threads for seed.cryptodistributed.org on 104.131.53.44 (port 53) ......done
Starting seeder...done
Starting 96 crawler threads...done
0/2 available (2 tried in 100s, 0 new, 0 active), 0 banned; 0 DNS requests, 4 db queries
SOLVED:
In the dnsseeder, main.cpp:
Line 351
- db.Add(CService("kjy2eqzk4zwi5zd3.onion", 9751), true);
+ db.Add(CService("104.131.18.228", GetDefaultPort()), true);
DNS seeder serves peers from seednode.
I will happily provide additional details if anyone has an idea as to what might be the problem.
Thanks!
SOLUTIONS POSTED FOLLOWING QUESTIONS
***************************************************
I'm creating an altcoin based on Pfennig (https://github.com/project-bitmark/pfennig), the cloneable reference implementation of Bitmark (https://github.com/project-bitmark/bitmark), in order to gain a deeper understanding of cryptocurrency. This coin is not going to market. It's intended only as a means of educating myself about different cryptocurrencies and their inner workings.
Please don't poop on me with posts about crappy altcoins, etc.
The difficulties I'm experiencing are as follows;
1. Clients do not connect to seednodes;
chainparams.cpp
22 unsigned int pnSeed[] =
23 {
24 0x688312e4 // Updated seed node
25 };
After first run to set the rpcuser and rpcpassword, the daemon does not attempt to connect to hardcoded seed nodes.
In the above example, taken from the coin source, shows the hex IP of my VPS seednode at 104.131.20.192.
The VPS at 104.131.20.192 is set to listen using the following;
./betacoind -listen=1 -printtoconsole &
and reports the following;
Betacoin version v0.9.2.1-7ecf3af-dirty-beta (2014-08-16 21:43:28 -0400)
Using OpenSSL version OpenSSL 1.0.1e 11 Feb 2013
Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
Default data directory /home/ubox/.betacoin
Using data directory /home/ubox/.betacoin
Using at most 125 connections (1024 file descriptors available)
Using 8 threads for script verification
Using wallet wallet.dat
init message: Verifying wallet...
CDBEnv::Open : LogDir=/home/ubox/.betacoin/database ErrorFile=/home/ubox/.betacoin/db.log
Bound to [::]:9751
Bound to 0.0.0.0:9751
init message: Loading block index...
Opening LevelDB in /home/ubox/.betacoin/blocks/index
Opened LevelDB successfully
Opening LevelDB in /home/ubox/.betacoin/chainstate
Opened LevelDB successfully
LoadBlockIndexDB(): last block file = 0
LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=1, size=254, heights=0...0, time=2014-08-16...2014-08-16)
LoadBlockIndexDB(): transaction index disabled
LoadBlockIndexDB(): hashBestChain=c44dec01e2ba3f7d0376654b4fb790fd0e3e7c2996c389a57ca3e48270f1c57a height=0 date=2014-08-16 02:36:49 progress=0.000008
init message: Verifying blocks...
block index 126ms
init message: Loading wallet...
nFileVersion = 90201
Keys: 101 plaintext, 0 encrypted, 101 w/ metadata, 101 total
wallet 160ms
init message: Loading addresses...
Loaded 1 addresses from peers.dat 0ms
mapBlockIndex.size() = 1
nBestHeight = 0
setKeyPool.size() = 100
mapWallet.size() = 0
mapAddressBook.size() = 1
ext-ip thread start
dnsseed thread start
Loading addresses from DNS seeds (could take a while)
opencon thread start
addcon thread start
net thread start
msghand thread start
dumpaddr thread start
init message: Done loading
1 addresses found from DNS seeds
dnsseed thread exit
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
GetMyExternalIP() received [184.75.210.198] 184.75.210.198:0
GetMyExternalIP() returned 184.75.210.198
AddLocal(184.75.210.198:9751,4)
ext-ip thread exit
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
SOLVED:
https://bitcointalksearch.org/topic/m.8901349
https://bitcointalksearch.org/topic/m.1983185
2. Clients only connect when using -connect or -addnode commands;
After first run to set the rpcuser and rpcpassword, the daemon will only connect to another client if using -addnode or -connect commands.
Using the following command, I am able to connect a client to my seednode at 104.131.20.192 ;
./betacoind -listen=1 -connect=104.131.20.192 &
and successfully mine blocks using;
./betacoind -listen=1 -gen=1 -connect=104.131.20.192 &
SOLVED:
This was the result of improper pnSeed formatting and broken DNS seed. Peers now connect automatically via seednode or dns.
3. Client does not pull from peers.dat;
On all subsequent instances of the daemon no connection is made unless -connect or -addnode is specified.
The following instance of the daemon results in no connections despite having peers in the peer.dat file.
./betacoind -listen=1 -gen=1
Why is the client not pulling peers from the peer.dat file?
4. Clients are not able to connect to the DNS Seeder;
The DNS seeder shows no attempted connections.
I have my domain configured with both and A record and NS record as follows;
A Record:
seed.cryptodistributed.org 104.131.53.44
www.seed.cryptodistributed.org 104.131.53.44
NS Record:
cryptodistributed.org seed.cryptodistributed.org
Which appears to be functioning correctly as per
https://www.whatsmydns.net/#A/seed.cryptodistributed.org
The address of the dnsseed is entered as such in;
chainparams.cpp
64 vSeeds.push_back(CDNSSeedData("cryptodistributed.org", "seed.cryptodistributed.org"));
On the clients attempting to connect:
Betacoin version v0.9.2.1-7ecf3af-dirty-beta (2014-08-16 21:43:28 -0400)
Using OpenSSL version OpenSSL 1.0.1e 11 Feb 2013
Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
Default data directory /home/ubox/.betacoin
Using data directory /home/ubox/.betacoin
Using at most 125 connections (1024 file descriptors available)
Using 8 threads for script verification
Using wallet wallet.dat
init message: Verifying wallet...
CDBEnv::Open : LogDir=/home/ubox/.betacoin/database ErrorFile=/home/ubox/.betacoin/db.log
Bound to [::]:9751
Bound to 0.0.0.0:9751
init message: Loading block index...
Opening LevelDB in /home/ubox/.betacoin/blocks/index
Opened LevelDB successfully
Opening LevelDB in /home/ubox/.betacoin/chainstate
Opened LevelDB successfully
LoadBlockIndexDB(): last block file = 0
LoadBlockIndexDB(): last block file info: CBlockFileInfo(blocks=1, size=254, heights=0...0, time=2014-08-16...2014-08-16)
LoadBlockIndexDB(): transaction index disabled
LoadBlockIndexDB(): hashBestChain=c44dec01e2ba3f7d0376654b4fb790fd0e3e7c2996c389a57ca3e48270f1c57a height=0 date=2014-08-16 02:36:49 progress=0.000008
init message: Verifying blocks...
block index 126ms
init message: Loading wallet...
nFileVersion = 90201
Keys: 101 plaintext, 0 encrypted, 101 w/ metadata, 101 total
wallet 160ms
init message: Loading addresses...
Loaded 1 addresses from peers.dat 0ms
mapBlockIndex.size() = 1
nBestHeight = 0
setKeyPool.size() = 100
mapWallet.size() = 0
mapAddressBook.size() = 1
ext-ip thread start
dnsseed thread start
Loading addresses from DNS seeds (could take a while)
opencon thread start
addcon thread start
net thread start
msghand thread start
dumpaddr thread start
init message: Done loading
1 addresses found from DNS seeds
dnsseed thread exit
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
GetMyExternalIP() received [184.75.210.198] 184.75.210.198:0
GetMyExternalIP() returned 184.75.210.198
AddLocal(184.75.210.198:9751,4)
ext-ip thread exit
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
connect() to 104.131.53.44:9751 failed after select(): Connection refused (111)
On the DNS seeder:
./dnsseed -h seed.cryptodistributed.org -n 104.131.53.44
Starting 4 DNS threads for seed.cryptodistributed.org on 104.131.53.44 (port 53) ......done
Starting seeder...done
Starting 96 crawler threads...done
0/2 available (2 tried in 100s, 0 new, 0 active), 0 banned; 0 DNS requests, 4 db queries
SOLVED:
In the dnsseeder, main.cpp:
Line 351
- db.Add(CService("kjy2eqzk4zwi5zd3.onion", 9751), true);
+ db.Add(CService("104.131.18.228", GetDefaultPort()), true);
DNS seeder serves peers from seednode.
I will happily provide additional details if anyone has an idea as to what might be the problem.
Thanks!
Jump to: