Opened 5 years ago

Last modified 4 years ago

#1384 testing defect

Reseeding can take place before the netDb is ready

Reported by: killyourtv Owned by: zzz
Priority: minor Milestone: 0.9.18
Component: router/netdb Version: 0.9.15
Keywords: Cc:
Parent Tickets:

Description

Split from #1192.

While testing, I made my own i2pseeds.su3 file to reseed I2P in Tails. My i2pseeds.su3 contained 200 router infos and was hosted on my PC. I configured myself to be a reseed host, copied my certificate to the reseed directory and started I2P.

The I2P router was running within Tails in a virtual machine. The virtual machine was running on the same host as the makeshift reseed host.

2014/09/21 20:33:54 | Starting I2P 0.9.15-0-1~deb7u+1
2014/09/21 20:33:54 | INFO: Native CPUID library jcpuid-x86-linux loaded from file
2014/09/21 20:33:54 | INFO: Locally optimized native BigInteger library loaded from file
2014/09/21 20:33:56 | INFO: Jetty 8.1.15.v20140411 logging to I2P logs using class org.eclipse.jetty.server.Server
2014/09/21 20:33:56 | Reseed start
2014/09/21 20:33:56 | Reseeding from http://MYHOST/i2pseeds.su3
2014/09/21 20:33:56 | 2014-09-21 20:33:56.497:INFO:oejs.Server:jetty-8.1.15.v20140411
2014/09/21 20:33:56 | INFO: 200 files extracted to /tmp/i2p-daemon/i2p-LeRMVO7E.tmp/reseeds-591027946
2014/09/21 20:33:56 | Reseed got 200 router infos from http://MYHOST/i2pseeds.su3 with 0 errors
2014/09/21 20:33:56 | Reseed complete, 200 received
2014/09/21 20:34:26 | 2014-09-21 20:34:26.360:INFO:oejs.Server:jetty-8.1.15.v20140411
9/21/14 8:33:57 PM INFO  [JobQueue 3/4] networkdb.reseed.ReseedChecker: Downloading peer router information for a new I2P installation
9/21/14 8:40:05 PM ERROR [JobQueue 2/4] db.kademlia.IterativeSearchJob: We don't know any peers at all

After running for 38 minutes, I still didn't have any peers. The netDb in the console was empty, but the RIs were correctly placed into the 64 subdirectories.y

There were 4 exploratory tunnels listed and 4 client tunnels, but no peers.

I then restarted I2P. I immediately saw

Peers

  • Active: 2/2
  • Fast: 75
  • High Capacity: 102
  • Integrated: 91
  • Known: 199

Of course, after a few minutes I was able to access services within I2P.


With a normal installation and using our default reseed hosts, I am able to get find other peers and connect to I2P. With my single i2pseeds.su3 file I could not.


<zzz> looking at the ticket, the reseed was completed 2 seconds after startup. I think maybe it happened too fast
<zzz> like the netdb wasn't ready to hear about the reseed being done

Subtickets (add)

Change History (2)

comment:1 Changed 4 years ago by zzz

  • Milestone changed from 0.9.16 to 0.9.18
  • Status changed from new to accepted

In 2985798e33b03f58635fa7e66030fef8fcf817e0 0.9.17-7, state machine added. Now to investigate how to fix this problem.

comment:2 Changed 4 years ago by zzz

  • Status changed from accepted to testing

can't reproduce or completely understand what's happening, I don't see anything happening out of order, but non-volatile fields and the precise order in which we set them may have caused it.

Possible fixes to PersistentDataStore? in c1b10adca273a2e65028d9ac7e9e274531c3b902 0.9.17-8

Note: See TracTickets for help on using tickets.