Socket recv error connection reset by peer (104)

Technology zcashd client
1

Help me !
I started to mine and for some days all is ok.
Now i have some problems and my zcashd
is stalled for minutes after “reset by peer”

Thank you

2

same issue

socket recv error Connection reset by peer (104)
Adding fixed seed nodes as DNS doesn’t seem to be available.

3

Do you have betatestnet.z.cash or alphatestnet.z.cash in your config?

4

I have betatestnet.z.cashin my config

5

same addnode=betatestnet.z.cash

6

Thanks but i already have
addnode=betatestnet.z.cash

I am a very old programmer and internet engineer
and a bit worried about zcache protocol.

7

The zcash daemon stall for w few minutes and run for a few step

8

same problem in old post with no answer

9

spending a lot of time to test mining on Google Cloud Computer engine (in state of amazon) i discovered this:

  1. after some time minutes/hours the node, is able to connect and start to mine but only one connection even if has a dedicated public ip (probably I have to investigate about subnet visibility, cloud dns, firewall etc.)

  2. is possible to force connection by addnode command

a) run on a connected node the following command

~/zcash/./src/zcash-cli getpeerinfo

obtain something like

[
{
“id” : 94,
“addr” : “104.198.227.8:40816”,
“addrlocal” : “138.201.202.001:18233”,
“services” : “0000000000000001”,
“lastsend” : 1474389736,
“lastrecv” : 1474389830,
“bytessent” : 2331759,
“bytesrecv” : 209877,
“conntime” : 1474377850,
“timeoffset” : 0,
“pingtime” : 0.11944500,
“version” : 170002,
“subver” : “/Satoshi:1.0.0/”,
“inbound” : true,
“startingheight” : 32,
“banscore” : 0,
“synced_headers” : 6508,
“synced_blocks” : 6508,
“inflight” : [
],
“whitelisted” : false
},
{
“id” : 96,
“addr” : “104.198.24.211:40592”,
“addrlocal” : “138.201.202.001:18233”,
“services” : “0000000000000001”,
“lastsend” : 1474389797,
“lastrecv” : 1474389830,
“bytessent” : 24345,
“bytesrecv” : 5438,
“conntime” : 1474386916,
“timeoffset” : 0,
“pingtime” : 0.11699600,
“version” : 170002,
“subver” : “/Satoshi:1.0.0/”,
“inbound” : true,
“startingheight” : 6491,
“banscore” : 0,
“synced_headers” : 6508,
“synced_blocks” : 6508,
“inflight” : [
],
“whitelisted” : false
}
]

b) use the following command on the unconnected node coping the ip node you obtain from the connected one

~/zcash/./src/zcash-cli addnode “104.198.227.8:40816” “onetry”
~/zcash/./src/zcash-cli addnode “104.198.24.211:40592” “onetry”

1 Like
10

What happen to betatestnet.z.cash ?
betatestnet.z.cash ip address is 198.199.112.230 and
so i addnode=198.199.112.230:18233 to config file to exclude
evenctually my dns provider problem. In any case i modify
my resolv.conf to public dns servers.
Sometimes the connection is ok but many times not
and the problem is getting worse.
I checked with wireshark and, as i had suspected the TCP connection
with the betatestnet.z.cash is reset with a FIN-ACK in response to my SYN.

11

Has anyone found a solution to this problem yet? After having success with numerous builds over the past month, I am having the same issue. Hoping to avoid a fresh install thats all. Any help would be appreciated. I tried the solution listed here, but no luck so far.

12

In my opinion the problem is on betatestnet.z.cash due to overload or some bug in low level socket communication bug. The problem is serious.

13

I am also experiencing the same bug.

I have not been able to sync the blockchain at all with the beta.

I was able to follow along the alpha guide and sync fully just a couple of weeks ago.

Should I file an issue on Github?

My most recent attempt was on a large DigitalOcean droplet - I had port 8333 open just like when running a full bitcoin node.

14

testnet has 18233 port

1 Like
15

Thanks iCimo, I’ll try that later today.

Is it mandatory to have this port open to sync the Zcash blockchain, or should it be possible without it open?

16

I am not shure i think depend on your UPnP router services, if it do not open the port you are non connected

after that wait because the dns discovery seed look like unstable

you should force a specific node connection just to start with

~/zcash/./src/zcash-cli addnode “138.201.202.201” “onetry”

(it is in my connection peer now!) or add the following line to file zcash.conf here some I took note just in case

testnet=1
addnode=betatestnet.z.cash
addnode=138.201.202.201
#addnode=159.203.96.26
#addnode=147.90.57.58
#addnode=176.9.3.148
#addnode=112.126.95.18
#addnode=138.68.59.119
#addnode=142.54.190.234
#addnode=52.41.64.197
#addnode=47.90.57.58
#addnode=159.203.96.26
#addnode=54.70.106.158
#addnode=212.47.244.188
#addnode=210.186.199.53
#addnode=212.171.81.103
rpcuser=rpcusername
rpcpassword=rpcpassword
gen=1
genproclimit =4

gud luck

1 Like
17

iCimo, great thanks worked

18

The problem is that everyone is connecting to the same node, so it can easily exhaust local connection limits at some times. We have recently fixed the DNS seeding issue however, so once some peers start being classified as “good” (can take a week or two by default to get the right uptime ratios) we should start to see peers being announced through that.

1 Like
19

Thanks for peer addressee

20

Hi there,

I’m from the Zcash team. We harden some of our boxes, including betatestnet.z.cash with a Linux kernel patch called grsecurity. We noticed today that there was some resource overstepping of memory limits that were resulting in connections being reset for a very small fraction of users, which could potentially be the cause of your problem. The issue has since been resolved. Sorry for the inconvenience.

3 Likes