Opened 3 years ago

Last modified 2 years ago

#2425 assigned defect

Bootstrap nodes are unreachable

Reported by: subatomic Owned by: str4d
Priority: critical Milestone: undecided
Component: apps/plugins Version: 0.9.38
Keywords: i2p-bote Cc: Masayuki Hatta
Parent Tickets: Sensitive: no


As of Feb 2019 all hardcoded bootstrap nodes are unreachable making new installs unable to join the Kademlia network and rendering them non-functional.


Change History (5)

comment:1 Changed 3 years ago by subatomic

As a workaround I have published a list of peers:

comment:2 Changed 3 years ago by zzz

Cc: Masayuki Hatta added
Owner: changed from zzz to str4d
Status: newassigned

Research by mhatta;

There are 4 hardcoded bootstraps.

  • 1 run by kytv, who vanished several years ago.
  • 1 run by thetinhat
  • 2 run by str4d

mhatta contacted thetinhat and str4d.

  • thetinhat said he forgot he was running it, will try to bring it back, but is not sure he can do so, and it will take a few days to investigate
  • str4d said he would restore them, but did not provide a time estimate, and hasn't yet.

Until one of them comes back, or people start new bootstrap nodes AND somebody releases a new bote version (which would require people delete the old version, because the signer is different), bote is dead.

Another possibility is for str4d to give one or both of his keys to others to run the bootstraps.

comment:3 Changed 2 years ago by str4d

My primary bootstrap has always been running, and was definitely active at the time mhatta contacted me (I checked after he asked me). My secondary bootstrap has been down for a while due to server issues, but I did back up the key, and can see about setting it back up.

Most likely the problem is that Bote's DHT implementation simply isn't functional with only one bootstrap node (I've never delved into it in any depth, so I don't actually know off-hand how it behaves under such conditions). So we need new bootstrap volunteers.

Also as a reminder, all I2P-Bote issues have been moved to, and new issues should be opened there.

comment:4 Changed 2 years ago by str4d

Hmm, another possible cause: my bootstrap peer has been alive for so long, that when restarting it tries connecting to peers that no longer exist instead of searching for new ones. A fresh I2P-Bote plugin install on a fresh I2P Router appears to bootstrap far more quickly. I've restarted my bootstrap peer after deleting its dht_peers.txt and relay_peers.txt files, and it is now connected to far more peers.

comment:5 Changed 2 years ago by str4d

Nope, my primary bootstrap subsequently disconnected from them all. Perhaps it is because it is on a router that is also overloaded? I'm seeing lots of log messages of the form:

4/24/19, 2:30:25 AM DEBUG [Kademlia    ] ademlia.ClosestNodesLookupTask: Looking up nodes closest to [Hash: 118-MC07OoO5lqDQdssRrsCxMrr6Mgw6nkX0jAQAQko=]
4/24/19, 2:30:25 AM DEBUG [Kademlia    ] ademlia.ClosestNodesLookupTask: Lookup status for key 118-MC07...: resp=0 pend=0 notQ=1
4/24/19, 2:30:25 AM ^^^ 1 similar message omitted ^^^
4/24/19, 2:30:36 AM DEBUG [RelayPeerMgr]  : Finished waiting. Time now: 1556073036025, #incoming=0, #outgoing=50
4/24/19, 2:30:50 AM ERROR [leTimer2 1/4] lient.impl.I2PSessionMuxedImpl: [OPEN I2P-Bote #64565]:  Client not responding? Message not processed! id=60260254: [MessagePayloadMessage: 
	SessionId: 64565
	MessageId: 60260254
	Payload: [Payload: 520 bytes]]
4/24/19, 2:30:50 AM ^^^ 15 similar messages omitted ^^^
4/24/19, 2:30:56 AM DEBUG [Kademlia    ] ademlia.ClosestNodesLookupTask: FindCloseNodes request to peer zegsejfq... timed out.
4/24/19, 2:30:57 AM INFO  [SeedlessInit] ce.seedless.SeedlessParameters: Testing Seedless API
4/24/19, 2:30:57 AM DEBUG [Kademlia    ] ademlia.ClosestNodesLookupTask: Node lookup for [Hash: 118-MC07OoO5lqDQdssRrsCxMrr6Mgw6nkX0jAQAQko=] found 0 nodes (may include local node).
Note: See TracTickets for help on using tickets.