Windows(?): Extremely poor connectivity with new encryption

[FreefallHeavens]

I am unsure if the crucial detail here is Windows but me and mesh on IRC corroborated not only this but also another quirk which I've seen no one else mention, so I will now speak of it all in here.

On both 2.10 and 2.11 switching encryption type to any variant of ML-KEM-X25519, be it standalone or dual with ECIES-X25519, results in extremely poor reach of eepsites. I'm talking open 10 popular sites and keep refreshing and maybe you will have one of them load after half an hour. Once loaded a site is responsive, but if the tunnel is allowed to go idle it will go out of reach again for god knows how many hours.

This happened both when I tried it on 2.10 explicitly and up til now on 2.11 regardless of network attack status. I am writing this from Android where there are no such issues or I would not be able to post at all. Windows version is 10 x64 and Java is 21. Internet connection is NAT with no uPnP or manual port forward. Active peer numbers always appear healthy.

The other common complaint me and mesh had was that on 2.10 I2PSnark was barely able to ever connect, but 2.11 fixed that. Again making me believe some Windows-specific issues are being missed.

Finally there is a problem with the encryption type and the console in 2.11. When stopping a hidden service, changing encryption, saving, and restarting, the encryption type doesn't change at all. It stays on ML-KEM768-X25519+ECIES-X25519. It is not persisted in the tunnel's config file either, as option.i2cp.leaseSetEncType doesn't change.

I am observing the same issues on two nodes on two different Windows machines, as well as a VM with a fresh install of 2.11. After 3 hours of running the VM node, connectivity remained as bad as the other 2 nodes. As happens with a fresh 2.10 if new encryption is used.

[zzz]

Thanks for the report, will investigate

[sidereal]

I had been looking into some weird behavior of my own (in certain cases, sites being browsed are appearing in http://localhost:7657/netdb?l=1 and not http://localhost:7657/netdb?l=7 - whenever that happens, the site will not load), and there may be an oversight in IterativeSearchJob when looking up leasesets for clients?

In the current version of sendQuery, if the lookup is for a client tunnel and we don't have the RouterInfo for the next peer on hand,

• if the client tunnel supports ElG encryption, it'll use an inbound client tunnel if there are any
• if it doesn't, it will use an exploratory inbound tunnel (therefore, due to netDB partitioning, the reply will go to the router netDB - not the client netDB)

The practical effect of this is that "once loaded a site is responsive", but if it doesn't load it probably won't load for a good while. If this really is the issue, I expect routers with low known peers to be more likely to have issues loading sites, and pure ECIES (leaseSetEncType=4) client tunnels to have issues similar to PQ client tunnels.

I don't think we've ever commonly had client tunnels that don't have ElG (it was 0 and then 4,0), so I don't find it surprising that it only came up while we're deploying PQ.

EDIT: In other news, I also have the "can't switch encryption type away from 6,4" issue.