I2P Tracker always stuck at Updating 4.6.0RC2

[absolutep]

qBittorrent & operating system versions

Information about software used.

What is the problem?

The I2P trackers are always stuck at Updating or Not Working.

Irrespective, of how many times qBittorrent is restarted – the state remains the same.

This hinders the ability to seed/leech a torrent via I2P as we know [I2P DHT & I2P PeX are still missing]

The torrent displayed below is very well seeded [20/5]

(i) The state remains the same after multiple qBittorrent restarts as well as I2PD router restarts. [I2PD router works perfectly on other supported clients].

(ii) qBittorrent is only restarted after 10 minutes of i2pd router so as to provide i2pd router sufficient time to establish connections properly.

(iii) The I2P trackers themselves have no issues & work 24x7 in other I2P supported BitTorrent client.

(iv) The I2PD router works very well for other I2P related works, so even that is not a problem.

Steps to reproduce

No response

Additional context

No response

Log(s) & preferences file(s)

No response

[Vort]

Can you try to set single tracker (either postman or w7tpb) and restart qBittorrent?
I suspect that simultaneous use of two trackers may trigger a bug.

[absolutep]

Can you try to set single tracker (either postman or w7tpb) and restart qBittorrent? I suspect that simultaneous use of two trackers may trigger a bug.

Did what you asked.

No change.

[Vort]

Another thing to try to lower hop count (i2p_inbound_length and i2p_outbound_length) to 2 or 1.
Maybe i2p network is just too slow and you did not wait enough.

Also you can look at SAM sessions section of i2pd webconsole. Maybe info there will give some clues.

[absolutep]

lower hop count

Hop count is 1 throughout.

Maybe i2p network is just too slow and you did not wait enough.

As aforementioned in point (ii), so that is not an issue at all.
I2PD configuration is set to unlimited.

Also you can look at SAM sessions section of i2pd webconsole. Maybe info there will give some clues.

Already, checked nothing out of the ordinary.

As aforementioned in point (iv) - all other I2P services work.

Even normal qBittorrent was facing tracker issues a little while ago so it may be related to it.

[Vort]

i2pd establishes connection in several steps:

1. Tunnels are created;
2. Leaseset is found;
3. Stream is created;
4. Data starts flow through stream.

At what step your connection to tracker hangs with "Updating..." state?

[absolutep]

after all these steps are in working condition yet the updating state exists

also, peers connect but the speed is slow [7-10kbps]

same torrents I checked with i2psnark and they work with full speed

[luzpaz]

Still reproducible on 4.6.0 ?

[OvercookedBeef]

Still reproducible on 4.6.0 ?

I think so, at least for some trackers. One of the trackers has been stuck updating for 10+ minutes, but the message is timed out so maybe it just keeps trying to reconnect?

The tracker went from Updating (waiting for i2p acceptor), to not working (timed out I think), to now updating (timed out)

BTW, I'm not able to connect to any peers for any I2P torrent. Haven't tried mixed mode. I've tried both the c++ and java implementation.

Edit: Just realized I also get constant updating for some regular trackers too, is that a bug? I probably misunderstood this bug report, sorry.

[anikey-from-i2p]

This is likely a problem with I2P, not with qBittorrent itself.

I'll explain. There are two encryption types in i2p destinations: elgamal and ecies. Some destinations support one, or the other, or both.

You see, some trackers, including Postman and Skank (from what i see) disabled elgamal support. This is a bit of a problem, because i2p's SAM bridge does not seem to work well with ecies-only destinations:

• java i2p tells the client that it "cannot_reach_peer", with comment "Unsupported encryption options"
• i2pd times out

I've written about both implementations on i2p forums, it is easily found in respective sections of it. I2P link and clearnet link.

In java i2p you can check encryption type in 'netdb search'.

Please note that not all trackers are ecies-only. But (most importantly) tracker2.postman.i2p has elgamal switched off and it will be kept that way (i asked postman about that).

opentracker.dg2.i2p (which is the same as w7tpbzn...) has both elgamal and ecies, so it should work with SAM. (and it appears to be working with qbittorrent).

So the way out is to fix i2p implementations of SAM. After all, the sites are accessible over http proxy, so it is clearly not a core issue with i2p implementations, maybe just an issue in the SAM subsystem itself.

(please note that i am NOT official i2p OR i2pd, i am just some random person using that software and hoping it improves).

[Vort]

i2pd times out

the sites are accessible over http proxy

Do you think proxy destination and SAM destination works differently in i2pd?

[anikey-from-i2p]

Do you think proxy destination and SAM destination works differently in i2pd?

Well, that's what my experience was. Check i2pd forum post (i2p link and clearnet link) for some info i wrote about it.

If tracker2.postman.i2p works for anyone using qBT, could they please tell if they also enabled HTTP proxy (port :4444) in qBT connection settings?

If HTTP proxy is disabled, then my hypothesis about encryption types is wrong.

If HTTP proxy is enabled (and ecies trackers do not work when disabled), then the connection to the tracker might be going through that proxy (i don't know whether qBT/libtorrent bypasses http proxy for i2p trackers or not), which according to official i2p docs is discouraged.

[Vort]

Well, that's what my experience was. Check i2pd forum post (i2p link and clearnet link) for some info i wrote about it.

i tried adding postman's tracker and also some other tracker to the same torrent, and that other tracker worked, while postman's tracker kept timing out all the time

Because support for using of several trackers at once is broken in libtorrent. I don't remember if I made report specifically about "your" situation, but here is very similar report: arvidn/libtorrent#7535.

could they please tell if they also enabled HTTP proxy (port :4444) in qBT connection settings?

I never tested SAM + HTTP combination.
There may be bugs in such case, right.

I was comparing just access with browser (and actually I use SOCKS, not HTTP) and access with SAM only using single tracker.
Browser access was more reliable, but both variants eventually made connections successfully.

[anikey-from-i2p]

Because support for using of several trackers at once is broken in libtorrent.

That's not what i'm trying to point out. Several trackers work fine for me. I've already said what is not working and a possible cause for the constant 'Updating'/'Not working' status of some trackers (i.e. that they are ecies-only and SAM is having trouble with that).

Trackers that work fine for me are: opentracker.dg2.i2p, opentracker.r4sas.i2p (both show 'Working' and some peers when i add them to a torrent).

I've said that it is not specific to qBT. In fact, just now I posted some more detailed instructions to that i2pd forum thread on how to reproduce this issue outside of qBT (i.e. with netcat connection to SAM bridge).

Should I file an issue on i2pd repo?

[Vort]

In fact, just now I posted some more detailed instructions to that i2pd forum thread on how to reproduce this issue outside of qBT (i.e. with netcat connection to SAM bridge).

@orignal helped to figure out what is needed to be done:
i2cp.leaseSetEncType=0,4 should be added to SESSION CREATE.
Try this: SESSION CREATE STYLE=STREAM ID=testing123 DESTINATION=TRANSIENT SIGNATURE_TYPE=7 i2cp.leaseSetEncType=0,4 inbound.length=2 outbound.length=2 inbound.quantity=3 outbound.quantity=3
This is corresponding line in libtorrent in case someone want to modify it:
https://github.com/arvidn/libtorrent/blob/44598ba5d76e0aa118e656b281b89014032d4868/include/libtorrent/i2p_stream.hpp#L450

[Vort]

Java i2p will tell you "Unsupported encryption options".
i2pd will happily say that it connected.

i2pd should return CANT_REACH_PEER as well: PurpleI2P/i2pd#2004.

[anikey-from-i2p]

Great, thanks!! This works on both i2pd and java i2p!

Minor notice: the docs say that the recommended value for i2cp.leaseSetEncType is 4,0, not 0,4.

So i guess it all comes down to not reading documentation in depth.. It might as well be such a common issue to deserve mention at the SAM docs page, instead of some 'recommended value' in a table buried somewhere else in the docs...

(note: replace i2p-projekt.i2p with geti2p.net in the links if you access from clearnet).

By the way, while reading i2pd source i noticed some undocumented SAM option called CRYPTO_TYPE. is it intended to be used?

[glassez]

@anikey-from-i2p, @Vort
IIRC, you've found some bug in libtorrent i2p code, right? I believe it's better to create an appropriate Issue in libtorrent bug tracker. Or (if you really know of how to fix it) you could create PR instead.

[Vort]

IIRC, you've found some bug in libtorrent i2p code, right? I believe it's better to create an appropriate Issue in libtorrent bug tracker.

@anikey-from-i2p already created issue: arvidn/libtorrent#7578.

Or (if you really know of how to fix it) you could create PR instead.

I think fix is easy, just i2cp.leaseSetEncType=4,0 needs to be added:

diff --git a/include/libtorrent/i2p_stream.hpp b/include/libtorrent/i2p_stream.hpp
index ca0ec74ae..cc6c40a68 100644
--- a/include/libtorrent/i2p_stream.hpp
+++ b/include/libtorrent/i2p_stream.hpp
@@ -447,7 +447,8 @@ private:
 		m_state = read_session_create_response;
 		char cmd[400];
 		int size = std::snprintf(cmd, sizeof(cmd),
-			"SESSION CREATE STYLE=STREAM ID=%s DESTINATION=TRANSIENT SIGNATURE_TYPE=7 "
+			"SESSION CREATE STYLE=STREAM ID=%s "
+			"DESTINATION=TRANSIENT SIGNATURE_TYPE=7 i2cp.leaseSetEncType=4,0 "
 			"inbound.quantity=%d outbound.quantity=%d inbound.length=%d outbound.length=%d\n",
 			m_id, m_session_options.m_inbound_quantity, m_session_options.m_outbound_quantity,
 			m_session_options.m_inbound_length, m_session_options.m_outbound_length); 

(I made additional line for code to be little more readable)

[zzzi2p]

Thanks to everybody above for helping to track this down. ACK to the suggested libtorrent patch by Vort. I have updated both our bittorrent and SAM docs to include the recommendation to add this to the SESSION CREATE config. I have also filed an issue with bitcoin, which needs to do the same thing.