Topic: bitcoin.conf connect= option, peers not synchronizing (Read 3679 times)
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.
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.
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.
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.
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.
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)
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.
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.
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.
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
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:
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.
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
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
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.
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.
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.
Jump to: