Bitcoin Forum
October 25, 2020, 07:39:37 PM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: bitcoin.conf connect= option, peers not synchronizing  (Read 3580 times)
dooferorg
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile
September 22, 2012, 12:05:04 AM
 #1


Hi,

I am trying to set up my 'wallet holding' machine behind my gateway machine and have both of them run bitcoind. The gateway machine can run its copy and connect to peers, the 'wallet holding machine' (that runs truecrypt, RAID-1 etc) should connect to the gateway bitcoin server.

I have both installations installed and they can sync to the bitcoin network. My problem is when I change the internal peer to connect (via adding the connect=x.x.x.x:8333 line in its bitcoin.conf) that peer no longer will keep synchronization. I am judging network synchronization by seeing the block count increase on the gateway peer, but it does not on the internal peer.

Anyone have this happen and/or any hints?

Thanks.

BTC: 1dooferoD3vnwgez3Jo1E4bFfgMf81LR2
ZEC: t1gnToN2HZW4GD52kofEVdijhRijWjCNfYi
1603654777
Hero Member
*
Offline Offline

Posts: 1603654777

View Profile Personal Message (Offline)

Ignore
1603654777
Reply with quote  #2

1603654777
Report to moderator
1603654777
Hero Member
*
Offline Offline

Posts: 1603654777

View Profile Personal Message (Offline)

Ignore
1603654777
Reply with quote  #2

1603654777
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1001


View Profile
September 22, 2012, 12:43:49 AM
 #2

The gateway machine can run its copy and connect to peers, the 'wallet holding machine' (that runs truecrypt, RAID-1 etc) should connect to the gateway bitcoin server.

Does the gateway peer possibly have Windows firewall blocking incoming ports?

Can you telnet to it?  e.g,

 telnet 192.168.2.2 8333
If that cannot connect, then neither can the bitcoin client from your wallet holding machine.


Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


dooferorg
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile
September 22, 2012, 03:43:36 AM
 #3

All systems are Linux, and no, the internal machine has full accessibility to TCP/8333 on the gateway machine. Further to that, the gateway machine is open on TCP/8333 to everyone so it can be a better part of the bitcoin network at large.

Background: I'm not new to Linux or to networking (doing both since 1996). Not trying to be 'snarky', you started with a plausible explanation and didn't know what I'd tried Smiley

Looking at the debug.log I see numerous times that the internal peer is trying to connect to the correct IP and port but then is disconnecting and 'trying again'

Log excerpt from earlier:
Code:
trying connection 192.168.1.1 lastseen=0.0hrs
connected 192.168.1.1
send version message: version 60002, blocks=199878, us=0.0.0.0:0, them=0.0.0.0:0, peer=192.168.1.1:8333
Flushed 11442 addresses to peers.dat  32ms
socket no message in first 60 seconds, 0 1
disconnecting node 192.168.1.1

I can telnet to 8333 on 192.168.1.1 just fine, so I'm confused if there's some authentication thing that's needed for 'trusted peers', or what it is that I'm missing.

BTC: 1dooferoD3vnwgez3Jo1E4bFfgMf81LR2
ZEC: t1gnToN2HZW4GD52kofEVdijhRijWjCNfYi
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1001


View Profile
September 22, 2012, 06:53:08 PM
Last edit: October 02, 2012, 04:52:18 AM by Stephen Gornick
 #4

Code:
send version message: version 60002, blocks=199878, us=0.0.0.0:0, them=0.0.0.0:0, peer=192.168.1.1:8333

I see the us= and them=  being 0.0.0.0.  That will normally show the external address, but if you have no WAN access, that would explain that.


The current block looks to be pretty close to being caught up (199,878) ... was that because you brought over a current blockchain?   Or perhaps is this problem intermittent where sometimes it is getting new blocks?

It looks like you are using Bitcoin.org client v0.7 on the wallet holding machine.  What version on the gateway machine?

Also, does your bitcoin.conf on each have anything regarding networking?

This is something I can't easily set up to try to replicate -- perhaps someone else can confirm that v0.7 has no problem connecting to a local peer when it has no external/WAN connectivity.

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


dooferorg
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile
September 23, 2012, 12:49:46 AM
 #5

Both systems are on the same 0.7, even copied the same archive file I downloaded. Both are running the same version of Debian Squeeze 64-bit.

RPC allow for networks is my own internal subnet of 192.168.0.0/16. I set that on the gateway machine. I also set server=1 on that config too.

The RPC passwords can be different between the machines can't they? They're not communicating via the RPC interface are they I thought? RPC port is set to 8335. The gateway machine is still listening on 8333, presumably for peer connections.

rpcport=8335
rpcallowip=127.*
rpcallowip=192.168.*

That section exists for both machines config, although it seems to be irrelevant AFAIK.

BTC: 1dooferoD3vnwgez3Jo1E4bFfgMf81LR2
ZEC: t1gnToN2HZW4GD52kofEVdijhRijWjCNfYi
zvs
Legendary
*
Offline Offline

Activity: 1666
Merit: 1000


www.nogleg.com


View Profile WWW
September 24, 2012, 01:55:48 AM
 #6

Both systems are on the same 0.7, even copied the same archive file I downloaded. Both are running the same version of Debian Squeeze 64-bit.

RPC allow for networks is my own internal subnet of 192.168.0.0/16. I set that on the gateway machine. I also set server=1 on that config too.

The RPC passwords can be different between the machines can't they? They're not communicating via the RPC interface are they I thought? RPC port is set to 8335. The gateway machine is still listening on 8333, presumably for peer connections.

rpcport=8335
rpcallowip=127.*
rpcallowip=192.168.*

That section exists for both machines config, although it seems to be irrelevant AFAIK.


this happened to me once, where i could telnet to port 8333, but would be disconnected immediately.

no clue what it was.  i recompiled and it worked fine.  probably some ipv6 crap (or upnp)

Akakakakakak.
dooferorg
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile
September 24, 2012, 02:14:13 PM
 #7

GAH

Found the problem. I was running a stratum proxy on the gateway machine and IT was listening on TCP 8333. I had forgotten about that program.

I only noticed this when I compiled the bitcoind from source and ommited IPv6. I think the previous build was quite happy binding to IPv6 TCP/8333, but I was trying to connect to IPv4 TCP/8333. When the source build that didn't use IPv6 tried to bind an address, it couldn't and flagged the error. I'm still used to using IPv4 internal subnets on my own stuff so IPv6 isn't a bit deal for me right now especially considering my ISP doesn't even give me an IPv6 address.  Roll Eyes

So, finally it's figured out. Just a silly configuration issue. Thank you to all that replied. It was the suggestion to recompile that made me try the source tree, thank you.

BTC: 1dooferoD3vnwgez3Jo1E4bFfgMf81LR2
ZEC: t1gnToN2HZW4GD52kofEVdijhRijWjCNfYi
100%digital
Member
**
Offline Offline

Activity: 100
Merit: 10


View Profile
October 01, 2012, 05:20:38 PM
 #8

http://bitcoin.sipa.be/seeds.txt
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!