Low peers: UDP use of closed network connection

[jgrizzled]

Not sure if this is a separate issue from other low peer problems but here it is. I can't get more than ~3 peers now. Deleting nodekey, the nodes dir, or trying various flags hasn't helped. I was often maintaining 20-50 nodes during olympic.

Here is a log with lots of "use of closed network connection" alerts:

https://gist.github.com/TalkingAntColony/eade156c0bd0b84f6823

Here is my current startup flags:

geth --genesis genesis_block.json --rpc --rpcaddr localhost --rpcport "8545" --nat extip:71.225.210.78 --maxpeers "100" console 2>C:\Ethereum\geth_log.txt

Platform is Windows 8.1, high performance machine, high speed internet.

[tryphe]

Same problem for me. I'm on a DSL connection in Miami, and although I initially connect to around 200-2000 peers, it stalls some time between a few minutes to an hour later, and I'm sitting mining the same block that never changes. I've tried things like --maxpeers "32" and --maxpendpeers "1", but these options don't seem to be respected in any regard.

Edit:
After specifying(or not) --nat "extip:local.subnet.address.here" or --nat "extip:my.public.address.here", the socket appears to be listening on 0.0.0.0.

Edit 2:
Turns out it was properly listening on the "any" interface, but a rule on my router was tripped and subsequently dropping the insanely large amount of connections. Is there any way to make it not go completely crazy and flood my connection upon initialization?

Edit 3:
After dropping this rule, things are working a little better, but this is in no way a solution. After an hour, I still only get 1 outbound connection, with ~50-150 inbound.

Edit 4:
Nope. 700 seconds on the same block when the chain is clearly moving on etherchain.org. This is with 1 outbound connection and ~200 inbound.

[jgrizzled]

I updated. Still having low peers. Node restart yields a few dozen, then a
slow trickle down to a just a few over a few days.

On Thu, Aug 20, 2015 at 8:55 AM, Felix Lange notifications@github.com
wrote:

geth 1.0.2 has been released and contains the linked pull request. Please
check whether this issue still occurs with geth 1.0.2.

—
Reply to this email directly or view it on GitHub
#1579 (comment)
.

[tryphe]

The bug still exists for me, however the problem of the chain being out of sync with many inbound connections has been resolved. The chain used to stall when my outbound connections would dwindle to around 1 or 0 despite having many inbound connections, but now the chain stays synced with 0 outbound, with around 100 inbound connections. This is after running 1.1.0 for about 36 hours, where it used to stall with 1.0.1 around an hour, no matter the number of inbound connections (outbound would always trickle to 0 and inbound connections would not sync).

In other words, it looks like this is now a non issue if port forwarding is configured properly because the inbound peers are always diligent to sync the chain. The lack of outbound connections still raises an eyebrow though.

Edit: the version I'm actually running is 1.1.0, and I've been running it for a few days which trickled down to only inbound peers, but the chain is still kept up to date.

[fjl]

Sorry, my previous comment was a bit too early (1.0.2 did not contain the fix).
Geth 1.1.0 was released today. Please upgrade and report whether the
situation has improved.

[tryphe]

Heh, turns out I was already running the 1.1.0 branch and my 1.0.2 comment was incorrect. I was actually on 1.1.0. Sorry for the confusion.

[fjl]

                                                                                  In that case, do you still see these messages containing "use of closed network connection" when running with --verbosity=6 or --vmodule=udp=6?