Net: Bitcoin ONLY attempts to connect to addresses from DNS seeders #12195

The issue was discovered due to our strict firewall settings blocking all traffic from DNS Seeders.

OS: OSX 10.13.2 reproduced on Ubuntu 16.04, 17.04

Git branch: master (0.15.99)

Expected behaviour: nodes are failing to receive addresses from DNS seeders, upgraded ones are expected to connect to cached addresses from peers.dat, new ones should fall back to the hard coded seeds. In reality, addresses are reported to be loaded but no connection attempt is made.

2018-01-16 06:22:33 Adding fixed seed nodes as DNS doesn't seem to be available. 2018-01-16 06:22:33 Added 1450 addresses from cgd63h25kfci3gdl.internal: 0 tried, 1053 new

Manually adding live nodes through console or bitcoin.conf will cause a connection to be established.

We were able to reproduce the issue on an open network (no firewall at all) by removing all DNS seeders from chainparams.cpp and there for forcing the node to look after peers.dat and hard coded seeds. Code compiled that way is not establishing a single connection, even it is writing the hard coded nodes to peers.dat

2018-01-16 06:44:08 Flushed 1053 addresses to peers.dat 31ms

We have double-checked by applying the same change to the 0.13 branch where it is working as expected, no DNS available and there for falling back to chainparamsseeds.h and establishing connections.

Hard coded seeds have been broken on master for a while now, see #11512, though they should work fine on 0.15.X and previous versions.

On January 16, 2018 6:59:50 AM UTC, Michael Polzer notifications@github.com wrote:

The issue was discovered due to our strict firewall settings blocking all traffic from DNS Seeders.

OS: OSX 10.13.2 reproduced on Ubuntu 16.04, 17.04

Git branch: master (0.15.99)

Expected behaviour: nodes are failing to receive addresses from DNS seeders, upgraded ones are expected to connect to cached addresses from peers.dat, new ones should fall back to the hard coded seeds. In reality, addresses are reported to be loaded but no connection attempt is made.

2018-01-16 06:22:33 Adding fixed seed nodes as DNS doesn't seem to be available. 2018-01-16 06:22:33 Added 1450 addresses from cgd63h25kfci3gdl.internal: 0 tried, 1053 new

Manually adding live nodes through console or bitcoin.conf will cause a connection to be established.

We were able to reproduce the issue on an open network (no firewall at all) by removing all DNS seeders from chainparams.cpp and there for forcing the node to look after peers.dat and hard coded seeds. Code compiled that way is not establishing a single connection, even it is writing the hard coded nodes to peers.dat

2018-01-16 06:44:08 Flushed 1053 addresses to peers.dat 31ms

We have double-checked by applying the same change to the 0.13 branch where it is working as expected, no DNS available and there for falling back to chainparamsseeds.h and establishing connections.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/issues/12195

Well, I need to enhance my brain-filter when searching for issues. Verified on 0.15 branch -> OK. Anyways thank you for the quick reply, will deploy some workaround for our pre-release test nodes.

Just in case someone stumbling over here again... 0.15 (release) is connecting to fixed seeds down to 0.13 but no older, even there are just one or two newer ones in the firewall environment. Is that really the desired behaviour? Edit: if that's the case, why are we then flushing all the other peers to .dat regardless it's version?

@HashUnlimited No, it's not desired behaviour. It's a known bug, which will be fixed in the next release (a proposed fix is #11512).

Thanks again for the answer. I have tried to implement the PR locally, unfortunately we do still not connect the old nodes (<0.13.x without NODE_WITNESS), even when I add their IPs to chainparamsseeds.h. Now that our target is to gracefully upgrade our servers and nodes behind the firewall, so the only chance I currently see is to run some "gateway nodes" on 0.13 until the whole cluster is up to date. On the global network this might not be a big deal as there are still a lot of intermediate versions around, locally it would isolate the older ones.

Errr...no? Yes, that is the desired behavior. All the static seeds are filtered to at least be 0.13+ (ie have NODE_WITNESS) and #11512 does nto change that. We do not make any outbound connections to non-NODE_WITNESS peers (except feelers) period.

Oh, sorry I misread. Connecting only to witness capable nodes is intentional.