RouterInfo and Lease Set queries

[sxlissxn]

Hello, i'm conducting a simulation of I2pd in a self-contained environment. I'm having a few issues...
Currently it requires the simulation of the reseed server for boostraping and floodfill routers. Those entities requires the su3 files, which can be generated using some available tools. However, the su3 is constructed using the routerinfo.dat files, but the i2pd routers only generates the router.info files. Based on my research the routerinfo.dat file contains additional metadata.Thus are there ways to generate the router.info files and lease sets for a given number of simulated routers?

[Vort]

I don't know exact answer to your question.
However, as far as I know, I2P network can work without reseeds, but you need to manually copy some starting routerinfos to netDb directories.
Here is some example code: https://codeberg.org/weko/i2pd-test-tools/src/commit/4663af6da3b511af1c066940a8535ea32cb15eaf/start_testnet.py.
Also you can look how reseeds work here:
https://github.com/PurpleI2P/pyseeder

[sxlissxn]

thanks :) i did the reseeding manually, however, i am unsure about whether its the reseed which is causing this:


Are there ways to solve this?

[Vort]

Not enough nodes maybe?
You can look if nodes make connections at all:
/debug - SSU2: Connecting to ip:port (hash)
/debug - NTCP2: Connecting to ip:port (hash)

Also you need some nodes to have floodfill option enabled.

[sxlissxn]

i have simulated 15 i2pd routers, however, is the self-contained characteristic of my simulation tool causing the peer discovery issue? i have filled the NetDB, have floodfill and reseed server but i still get the same error.

[Vort]

How IP addresses for your nodes look like?
Also it worth checking for connections as I said before.

There may be bugs in simulation tool of course, but first of all, more probable variants should be checked.

[sxlissxn]

for the ip addresse , now i am getting those errors, the nodes are not making connection at all:

[Vort]

Try using "real" addresses like 1.1.1.1 - 1.1.1.254 for example.
I think simulation environment should allow it.

Not sure if errors will go away, there may be more problems, but changing IP addreses is worth to try.

[sxlissxn]

It does not work :(
For the peer selection, does it take it from the NetDB?
Since i am not connecting to the internet for the simulation, i had to manually add files to the netDB and create the su3 files, is the fact that i changed the extension from router.info to routerInfo-Id.dat probably creating this issue?

[Vort]

It does not work :(

Maybe it worth to try something simpler than i2pd first - web server (nginx) and web client (curl) for example.
Or custom made tcp server and client.

For the peer selection, does it take it from the NetDB?

Yes, but problem in your case appears much earlier:
Node can't open its own ports.
It makes no sense trying to connect to other nodes in such case.
This problem should be solved first.

[sxlissxn]

Maybe it worth to try something simpler than i2pd first - web server (nginx) and web client (curl) for example. Or custom made tcp server and client.

I've already tried those early this year.

Try using "real" addresses like 1.1.1.1 - 1.1.1.254 for example. I think simulation environment should allow it.
I was able to solve the binding problem by assigning ip addresses using the simulation configuration file instead of the i2pd configuration file.

However, i'm still having issues with the peer connection and now i am facing a new issue:

[Vort]

However, i'm still having issues with the peer connection

Do you see Connecting messages like I mentioned eariler?

and now i am facing a new issue:

I don't think this error is much important.
And it affects only SSU2.
NTCP2 should be unaffected.

[Vort]

Also I suggest to look at routerinfos inside of netdb directory for your nodes.
Do they have host and port specified? What caps they have?

[sxlissxn]

[Vort]

PfG caps are not right. Why transit is disabled? It should not be like that.
Also where this RI was located? In netdb of node with other IP (like 100.0.0.2)?

upd: It should be possible to use this node as floodfill, but no tunnels through it will be possible.
upd2: Another thing to check: node can be banned because of unreachability if you started it little later than it was contacted by other node. It is better to clear peerProfiles directory just in case. And start first node slightly earlier than others.

[sxlissxn]

this is the router.info found in the data directory for that specific i2pd router.I haven't enabled the no transit