Cannot get good peers

Hi Team:

Many of you helped me in my debacle during the dust storm and upgrade. Needless to say I’m still synching. I cannot get any reliable peers no matter what I do. Restart does nothing except jumble up the bad peers that connect to me. I cannot connect to anyone no matter what I try and others who have tried to connect to me do but just for an instant and disconnects and there is nothing in either of the persons logs.

I can actually see at the bottom of the peer page that some peers are trying to connect but get blown out immediately. I’m running 1.2.11 and I have notissue getting peers but they are awful with no speed. I have a 1GB up and down network and it is great. I do speed tests all the time.

This is very perplexing. The Chia Devs said after I put my bug in that I must be full or the other user is full of connections. I can validate that this is not true at any level. Not even close. It has been a week and 1/2 and Im only at 700Ksyched.

I also tried to reload windows but it wont as my ssd’s are gpt formatted and I’m not sure on how to resolve this issue without mucking something else up. I cant chage to UEI format in my bios. I have a ASUS Motherboard and there is no setting. I looked at the windows advanced security side of things to change it, but I just get lost.

Anyone have any ideas on the network side of things?

Lastly, if we have a windows stud in the house, please let me know about installing windows 10 pro again. As always, thank you team! Larry

Have you tried a VPN? Some ISPs will configure their routers to drop crypto connections without ever telling you. Some employers do this also, of course.

1 Like

Interesting thought. No I have not done a VPN as I thought it would hurt me with communicating on the network. What would be the best recommended VPN to use?

But how does it explain dozens of crappy peers? IE. no throughput. No up or down network traffic.

Iin your config.yaml, what value you have for “target_peer_count.” Do you have roughly the same number of peers in your “Connection” section?

Could you get a screenshot of your “Full node” / “Connections” section (10-20 will do). How many peers are there?

How do you define “reliable peer”

I would not touch your Windows. Whether it is UEFI or not, it only matters for Win11. Although, I would consider reinstalling Chia to v1.2.6/7.

As far as ISP/VPN, you were running Chia without any issues before upgrading to v1.2.10, so why suspect something that was working fine, and still is basically the same.

1 Like

Another possibility to consider, if other apps are getting randomly lost connections (not just chia), and on other computers as well: consider replacing your modem.

Larry, are those bad peers you describe ahead or behind you with their Height (column in the Connections tab).
If most are at 1.129.xxx (at time of writing this) they are well synched themselves and should be able to feed your synching.

Is your synching just very slow of not moving at all?
You do have enough free diskspace to accomodate the database files of course… (~30GB).
I found syncing to be very CPU intensive, close to 100% cpu usage when out of sync. Are you perhaps plotting with MadMax at the same time (and same system). MadMax also is very cpu intensive, then maybe the syncing process is just competing with the plotting?

Something else you could do as an experiment: install chia (same version) on your laptop, don’t start it yet. Stop chia on the main rig and reboot. Copy the .db files over to the laptop in the appropriate locations. Then restart the main rig and start Chia on the laptop with a new set of keys. Don’t even have to write down the mnemonics, just for testing. Never mind the portforwarding either, just leave that towards your main rig. The laptop should all the same start syncing at the same height as the main rig. If this goes any better there could be someting wrong in the network stack of the main rig.
If the syncing is also very slow or none at all on the laptop you can at least forget about windows issue on the main rig.

Hi Jacek,

About two weeks ago I started my upgrade at the peak of the dust storm. I got wiped out. The community really tried to help, however, the only solution was to scratch chia 100% and rebuild which means re-synching the entire DB. Very painful and slow. I’m currently at 703 height and have 61 connections.

I have a ticket open with the devs as it does appear that Chia does not close all the processes, especially in a windows environment. Even after a shutdown of chia and shutdown of the rig, the wallet could never connect.

So I got a double whammy with the upgrade taking place at the peak of the dust storm. I can say that I never had to do this except when I started back in May.

The peers that connect are at full height and not full height and there is no upload or downloads taking place. 0.0 on over 40 connections. Ther others have like .07 or .02. I have a couple at .14 and .26, but the majority is no helo in synching.

Hi Larry, Thank you for the update. Yes, I was also one of those that tried to chime in at that time.

From what you have described, it looks to me that the only bad / not reliable node is yours. It is not likely that you will have 60 nodes that are bad. The good part is that you still get those peers, and of course the bad is that something is killing those transfers.

Although, you are now at 700 (i.e., you are getting data). Are you stuck at 700, or rather the progress is painfully slow?

Just to clear things out, could you confirm those:

  1. Before upgrade to v1.2.10
    1.1. Were you fully synced; did you have any syncing problems
    1.2. What version did you run
    1.3. Did your pool consistently pay you at whatever rate you had
  2. After upgrade
    2.1. Did you change ISP (ISP settings)
    2.2. Did you change any settings on your modem/router (e.g., fix the connection to your box, or ISP related)
    2.3. Did you change any settings in your config.yaml with respect to port 844x
    2.4. Did you add any AV to your box
    2.5. Did you reinstall Win
  3. Do you have another full node running on your home network

Also, could you run those two commands:

ping google.com -t
ipconfig

Do you see any outliers in your ping output with respect to “time=10ms” By outlier that would be something close to second, or “Request timed out” responses.

With ipconfig, you should see in your main section something like:

IPv4 Address. . . . . . . . . . . : 192.168.1.50

Anything that starts with 192.168, or 10.0 is good (private IP given by your router). How many sections do you have (e.g., “Ethernet adapter Ethernet” and “Ethernet adapter Ethernet 2”)

Also, run Task Manager, and check your CPU and disk utilizations. Are those close to zero, or rather on the higher end.

1 Like

Here is my results…

Reply from 172.217.4.174: bytes=32 time=9ms TTL=117
Reply from 172.217.4.174: bytes=32 time=9ms TTL=117
Reply from 172.217.4.174: bytes=32 time=8ms TTL=117
Reply from 172.217.4.174: bytes=32 time=9ms TTL=117
Reply from 172.217.4.174: bytes=32 time=9ms TTL=117
Reply from 172.217.4.174: bytes=32 time=9ms TTL=117
Reply from 172.217.4.174: bytes=32 time=9ms TTL=117

Ping statistics for 172.217.4.174:
Packets: Sent = 28, Received = 28, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 18ms, Average = 9ms

So, that looks ok…

Windows IP Configuration

Ethernet adapter Ethernet:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : home

Wireless LAN adapter Local Area Connection* 1:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Wireless LAN adapter Local Area Connection* 2:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Wireless LAN adapter Wi-Fi:

Connection-specific DNS Suffix . : home
IPv6 Address. . . . . . . . . . . : fdfa:1d24:d9be:1:cd9f:839a:392b:aea0
Temporary IPv6 Address. . . . . . : fdfa:1d24:d9be:1:c8e2:6b67:2424:62bb
Temporary IPv6 Address. . . . . . : fdfa:1d24:d9be:1:d05d:410a:794b:7a9e
Link-local IPv6 Address . . . . . : fe80::cd9f:839a:392b:aea0%11
IPv4 Address. . . . . . . . . . . : 192.168.254.80
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.254.254

Ethernet adapter Bluetooth Network Connection:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

This looks good

Task manager shows zero on everything except the network but it is not pumping as it should…averaging only about 120kbps send and about 30kbps…

from my yaml file…

inbound_rate_limit_percent: 100
introducer:
host: localhost
logging: *id001
max_peers_to_send: 20
network_overrides: *id002
port: 8445
recent_peer_threshold: 6000
selected_network: mainnet
ssl:
public_crt: config/ssl/full_node/public_full_node.crt
public_key: config/ssl/full_node/public_full_node.key
logging: *id001
min_mainnet_k_size: 32
network_overrides: *id002
outbound_rate_limit_percent: 30
ping_interval: 120
pool:
logging: *id001
network_overrides: *id002
selected_network: mainnet
xch_target_address: xch1ufx3uvr4gghajhz579ujvq2fmulagvxl897p9k2szmm7eaqzulvqqh39kd
private_ssl_ca:
crt: config/ssl/ca/private_ca.crt
key: config/ssl/ca/private_ca.key
selected_network: mainnet
self_hostname: localhost
timelord:

From the chia GUI…
Status from the Chia Gui
Syncing 708,236/1,123,467

VERY SLOOOOOOOW

0xbd289d95925c84c29176c908c931f0c5cc4c927f3e5c4f4cfce544890591e143 171.44.166.76 12508/8444 0/0 Full Node 1,132,299
0x8d16c5d0e35966f774a18845ec7f0a89d635196c6f246395bb7883a5e200dac4 101.26.13.141 63308/8444 0/0 Full Node 1,129,644
0x1998b4844f6ab61db894f7cc4164578af3145c3ca8d4bc5689c22c68322e0c21 89.216.175.31 49995/8444 0/0 Full Node 1,132,299
0xc52c5a546a42b5c881dda9e778bcdd4fe9f3ed2b921b9a4b574f852108e6e3f8 59.149.103.243 52956/8444 0/0.4 Full Node 1,132,289
0x2042de20042513eedf4828e212cab3f9979749eec361fe20a4d8c5cb3c4d4f1f 127.0.0.1 54840/8449 15.4/0 Wallet
0x4c1454c7d2f8ed07eb579bf73a18c357e3b73b504e4ffbc3a8b988c5a5ad99ca 91.98.190.5 2351/8444 0/0 Full Node 12,992
0x0a9132d41544c1a163c5453206fb62367c3cd8189452335d0cc35ae6f22ff8f5 14.120.114.131 6503/8444 0/0 Full Node 1,132,299
0xbdd8451eeb41f0b56acbacb02912c87553ab196891a4f73983a5fe1e07fba499 60.176.119.85 64186/8444 0/0 Full Node 1,090,274
0xf92dcfd891b45431b1ca83ee5d7d7ed8dd80419f91e3407ba69d25f551560670 183.128.172.59 55462/8444 0/0 Full Node 1,036,313

all 0.0 except the wallet and that comes and goes as well.

fast_algorithm: false
full_node_peer:
host: localhost
port: 8444
logging: *id001
max_connection_time: 60
network_overrides: *id002
port: 8446
sanitizer_mode: false
selected_network: mainnet
ssl:
private_crt: config/ssl/timelord/private_timelord.crt
private_key: config/ssl/timelord/private_timelord.key
public_crt: config/ssl/timelord/public_timelord.crt
public_key: config/ssl/timelord/public_timelord.key
vdf_clients:
ip:
- localhost
- localhost
- 127.0.0.1
ips_estimate:
- 150000
vdf_server:
host: localhost
port: 8000
timelord_launcher:
host: localhost
logging: *id001
port: 8000
process_count: 3
ui:
daemon_host: localhost
daemon_port: 55400
daemon_ssl:
private_crt: config/ssl/daemon/private_daemon.crt
private_key: config/ssl/daemon/private_daemon.key
logging: *id001

I know there is something not right causing this as I never had this issue prior to the upgrade. I would synch in minutes if not sooner.

I also just did a speed test and wireless Im getting 478/469 so plenty of bandwidth and direct connect did not change anything either.

I look forward to your reply as I know there is something just not right.

I just ran novabench and my rig is +80% of others. Good score, but there is something going hinky with the network and Chia. Im perplexed.

Lastly, I’m downloading very large files 200G min with no issues and it is fast. FYI.

Did a traceert cloud.google.com and everything was 8-10 MS except one request times out #2 and I have no idea who or what that is or means. FYI.

With the testing I have done, the network seems ok…Im leaning towards a Chia issue. I wonder if I should download to 2.1.9…but the passkey will still be in the chia folder…hmmmmmmm, what to do? lol…i going nuts on this one. lol

I never answered each question…Please see my answers below…

ust to clear things out, could you confirm those:

  1. Before upgrade to v1.2.10
    1.1. Were you fully synced; did you have any syncing problems - Yes and Zero issues
    1.2. What version did you run - 1.2.9
    1.3. Did your pool consistently pay you at whatever rate you had - yes always did
  2. After upgrade
    2.1. Did you change ISP (ISP settings) did not change anything
    2.2. Did you change any settings on your modem/router (e.g., fix the connection to your box, or ISP related) no, no changes
    2.3. Did you change any settings in your config.yaml with respect to port 844x no scared to touch anything
    2.4. Did you add any AV to your box no…standalone rig nothing running on it but chia
    2.5. Did you reinstall Win - no as the format is gtp
  3. Do you have another full node running on your home network - no…just the one rig…

All that look good. I don’t think that you need to run those other tests, as your box and your Internet connection are sound.

Although, I cannot say that I understand your Ethernet status. In my case, I have only one line referring to local-link IPv6, where you also have one permanent and a couple of temp IPv6 addresses. Maybe you can check that one section after few minutes, and see whether any of those IPv6 addresses are rotating (and repeat after 5 mins or so a couple of times)? Here is my section:

Ethernet adapter Ethernet:
   Connection-specific DNS Suffix  . : burrow.int.
   Link-local IPv6 Address . . . . . : fd80::53ae:c1bd:bf5a:8ae3%5
   IPv4 Address. . . . . . . . . . . : 192.168.01.50
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.01.1

I kill IPv6 on my router, that is the reason that I have just that local-link (a private one).

My understanding is that the wallet up/down bytes are just local exchanges between the full node or UI and wallet. This is why we see some numbers there.

Again, I am still running v1.2.6 (1.2.7 is about the same). v…8 was badly broken, v…9 was a quick hack to fix v…8, but stable enough. v…10 had some issues, and again v…11 is a quick hack where potentially a lot of changes were around peer connections. Maybe those last two versions have some issues around IPv6 protocol (just grasping for straws).

There are more people reporting problems with v10/11 comparing to previous upgrades. Based on what you stated, that is the only thing that got changed for you, so that is for me the main reason to focus on those versions.

I am out of bullets right now. The only thing that I would suggest is to drop your version to v1.2.7. Although, don’t rush, as maybe others will be able to see more in the info you provided.

Oh, and I would not be removing any of those peers by hand (as was suggested before).

traceroute is trying to do a DNS lookup for all notes that it hits. Some of those don’t have DNS names, and that is where it is stuck. It is also looking for responses, and not all nodes respond properly, that is where you see those stars. Either way, nothing to worry about.

If that version worked for you before, then no need to drop to v1.2.7. Other people dropped to v1.2.9, so maybe someone that did it will chime in.

Lastly, maybe someone with a fast upload could let you have blockchain db. It zip-compresses to about 15GB. This will not fix anything, but will get you closer to be synced.

Oh, and I would try to disable that IPv6. You go to Control Panel / Network and Internet / Network and Sharing Center / (In the Access type click that blue) WiFi (or whatever you see there) / Properties (on this new dialog) / uncheck Internet Protoco Version 6 (TCP/IPv6) line. I guess, you will need to reboot.
In case you will have any problems (not likely), you just go back there and tick that line to bring it back. Maybe this is the fastest test you could do. (Again, grasping for straws.)

One more thing that you could do, and what was already suggested - setup another full node.

1 Like

well i shutdown chia and installed 1.2.7 and I get the whirlybird 100% with this bad error… :frowning:

sqlite3.ProgrammingError: Cannot operate on a closed database.
2021-11-12T15:56:44.678 full_node chia.full_node.full_node: ERROR sync from fork point failed err: Cannot operate on a closed database.
2021-11-12T15:56:44.700 full_node asyncio : ERROR Task exception was never retrieved
future: <Task finished name=‘Task-4155167’ coro=<RpcServer._state_changed() done, defined at chia\rpc\rpc_server.py:48> exception=ProgrammingError(‘Cannot operate on a closed database.’)>
Traceback (most recent call last):
File “chia\rpc\rpc_server.py”, line 51, in _state_changed
File “chia\rpc\full_node_rpc_api.py”, line 61, in _state_changed
File “chia\rpc\full_node_rpc_api.py”, line 135, in get_blockchain_state
File “chia\rpc\full_node_rpc_api.py”, line 397, in get_network_space
File “chia\full_node\block_store.py”, line 237, in get_block_record
File “aiosqlite\cursor.py”, line 54, in fetchone
File “aiosqlite\cursor.py”, line 31, in _execute
File “aiosqlite\core.py”, line 129, in _execute
File “aiosqlite\core.py”, line 102, in run
sqlite3.ProgrammingError: Cannot operate on a closed database.
2021-11-12T16:08:02.125 wallet asyncio : ERROR Task exception was never retrieved
future: <Task finished name=‘Task-42’ coro=<WalletPeers.ensure_is_closed() done, defined at chia\server\node_discovery.py:701> exception=AttributeError("‘WalletPeers’ object has no attribute ‘connection’")>
Traceback (most recent call last):
File “chia\server\node_discovery.py”, line 704, in ensure_is_closed
File “chia\server\node_discovery.py”, line 118, in _close_common
AttributeError: ‘WalletPeers’ object has no attribute ‘connection’
2021-11-12T16:12:18.493 wallet chia.rpc.rpc_server : WARNING Error while handling message: Traceback (most recent call last):
File “chia\rpc\rpc_server.py”, line 225, in safe_handle
File “aiohttp\client_ws.py”, line 150, in send_str
File “aiohttp\http_websocket.py”, line 687, in send
File “aiohttp\http_websocket.py”, line 643, in _send_frame
File “aiohttp\http_websocket.py”, line 660, in _write
ConnectionResetError: Cannot write to closing transport

2021-11-12T16:12:18.496 wallet chia.rpc.rpc_server : WARNING Exception: Traceback (most recent call last):
File “chia\rpc\rpc_server.py”, line 225, in safe_handle
File “aiohttp\client_ws.py”, line 150, in send_str
File “aiohttp\http_websocket.py”, line 687, in send
File “aiohttp\http_websocket.py”, line 643, in _send_frame

THooughts?

Don’t you like those errors? They show you that the problem is with db, but fail to indicate which one is the problem.

I hope that is not blockchain, but rather wallet db. Blockchain is what you sync, my understanding is that wallet you build off of blockchain (so fast process, local only).

I would shut down, make sure that there is no Chia in your Task Manager, and delete that wallet db.

1 Like

on 1.2.9…will see what happens…more to come…uggggg…I love Chia, but man this SW is buggy as hell. LOL

2 Likes

Take a look at this one, especially that IMPORTANT bullet:

What looked like a good version v1.2.9, is no good anymore. So, if you have some luck with v1.2.9, you may want to drop it to v1.2.7.

1 Like

Not sure (who is?) but if you enabled the passphrase on 1.2.11 your keys are now in an encrypted format, which 1.2.x (x<10) versions does not understand. I don’t think the blockchain db itself is dependant on keys but the wallet has to be.
So gone back to 1.2.x you should start the GUI by 1. deleting all keys and 2. import from mnemonics. 1.2.x should then reconstruct the keys from that in a format it understands.

Another thought from all the info you provided: you’re on a wireless link, with more than enough throughput. But chia is a peer-to-peer network where bits of information arrive from different sources (connections) that have to be reconstructed -in order- to data for the blockchain. Wifi is less well suited than a direct connection (ethernet) for that kind of traffic. You mentioned giving direct connection a try and it didn’t help. But did you think of adjusting the port-forwarding in your router, the direct connection must have had a different ip address!
Also (sorry to ask) have you given your wifi connection a fixed ip-address in windows or a static ip address assigned by the dchp server in your router, where to point the 8444 portforwarding.