improve documentation clarity around i2p settings

[arvidn]

Slightly simplify session_interface

[Vort]

Not sure if this information is useful, but I made checks with client_test and I2P download still works.

[jiigen]

Not sure if this information is useful, but I made checks with client_test and I2P download still works.

Did you modify the code of test client or left it unchanged? If changed can you post the modified code? Thanks

[Vort]

Did you modify the code of test client or left it unchanged?

I did not changed it.
Just launched with such run.bat file: client_test -f log.txt --alert_mask=all --enable_dht=false --proxy_type=i2p_proxy --i2p_hostname=127.0.0.1 --i2p_port=7656 magnet:?xt=urn:btih:cb18974db461c640c0d938710203bb263a746694^&dn=I2P%%2B+Universal+Installer+2.0.0%%2B^&tr=http://tracker2.postman.i2p/announce.php

[jiigen]

@Vort uhm..so you still used the option "--proxy_type=i2p_proxy" that confuses me cuz according to #7285 (comment) which has been confirmed by @arvidn here #7285 (comment) it should work even without that setting...Am I correct or I didn't understand??

[jiigen]

@arvidn as suggestion wouldn't be useful to add an "i2p_simple_client" among the examples to test about the different i2p options? (disabled,alone,mixed...)

[Vort]

it should work even without that setting

I tested and it works without --proxy_type=i2p_proxy.
However, without proxy_type, client_test opens lots of TCP and UDP listeners and I'm not sure if it is correct way of interaction with I2P network.
Maybe I should add some different option to prevent it from happening? Why so many listeners are needed when connections should go only via I2P?

[jiigen]

I dont see those listeners...anyway I must look more carefully.

[jiigen]

However so far the client which connect faster and grabs more peers is Deluge, I can even see the peers list after my little patch:
deluge-torrent/deluge@cae6454
Would be able to modify the code to try without i2p_proxy setting and mixed mode but failed so far...

[jiigen]

@Vort Using this plugin for deluge: https://github.com/ratanakvlun/deluge-ltconfig and manually setting i2p_hostname and i2p_port makes deluge work with i2p leaving proxy setting to none.
I got a torrent from postman tracker which was even on clearnet trackers added those trackers to the tracker list and it connected to both i2p and cleanet peers.
Oddly if I don't disable dht and pex it doesn't connect to clearnet peers even if it gets them from the trackers.

[Vort]

I got a torrent from postman tracker which was even on clearnet trackers added those trackers to the tracker list and it connected to both i2p and cleanet peers.

Shouldn't it work this way only when allow_i2p_mixed is set?

[jiigen]

Shouldn't it work this way only when allow_i2p_mixed is set?

Oh yes...sorry forgot to tell that with that same plugin I've enabled i2p_mixed too. In any case even with i2p_mixed enabled something goes wrong when I leave dht enabled...the peers from the clearnet tracker are found and added but not connections to them. Anyway it works even without i2p_mixed, so I'm wondering exactly what's the meaning of this setting

[jiigen]

From the libtorrent reference:

allow_i2p_mixed
 "if this is true, i2p torrents are allowed to also get peers from other sources than the tracker, 
 and connect to regular IPs, not providing any anonymization."

So I'm wondering, if peers comes from a clearnet tracker they are used regardless of this setting?

[arvidn]

@Vort

Maybe I should add some different option to prevent it from happening? Why so many listeners are needed when connections should go only via I2P?

This is because the libtorrent session supports adding multiple torrents, and opening listen sockets is preparing for supporting non-i2p torrents. The i2p torrents aren't supposed to accept connections via them.

@jiigen

So I'm wondering, if peers comes from a clearnet tracker they are used regardless of this setting?

My recollection is that traditional trackers shouldn't be used at all in i2p mode (unless mixed mode is enabled). But if they are, that might be a bug.

[Vort]

opening listen sockets is preparing for supporting non-i2p torrents. The i2p torrents aren't supposed to accept connections via them

Do it means that allow_i2p_mixed have no effect on clearnet-only torrents?
It makes some sense, however, I think with such approach it is too easy to leak i2p torrent to clearnet in case of user mistake.

[arvidn]

I'm not sure I understand what the (potentially) problematic scenario is. You mean if someone accidntally sticks a normal (public) tracker into an i2p torrent?

[Vort]

what the (potentially) problematic scenario is

I may be wrong, but I think that user can accidentally delete i2p tracker from torrent, making it lose its i2p status and consequently telling whole world about BTIH -> IP relation.

[jiigen]

@jiigen

So I'm wondering, if peers comes from a clearnet tracker they are used regardless of this setting?

My recollection is that traditional trackers shouldn't be used at all in i2p mode (unless mixed mode is enabled). But if they are, that might be a bug.

Do you mean a bug in the client (Deluge in thiscase)?

[jiigen]

what the (potentially) problematic scenario is

I may be wrong, but I think that user can accidentally delete i2p tracker from torrent, making it lose its i2p status and consequently telling whole world about BTIH -> IP relation.

So there's an "i2p status" ? and how it is recognized? just if it has an i2p tracker? From what I've seen so far:

• if i2p is used as proxy only i2p peers/tracker can be reached.
• if I don't use the proxy option but only set the host/port of i2p router regardless of mixed mode if one adds a clearnet tracker it is contacted and peers retrived.
  So probably only DHT and PEX needs mixed mode? IDK My only guess is that cosidering the client isn't made to support i2p in this way (not through a proxy setting) it can't manage correctly the scenario.
  @Vort did you test deluge with that plugin too?

[arvidn]

Generally, the notion of a torrent being an i2p-torrent is vague. This is roughly how it works:

• If a SAM connection is configured (via the i2p_hostname and i2p_port settings) a connection will be opened by the session, on startup.
• A torrent has a list of trackers, any tracker whose hostname ends with ".i2p" is contacted via the SAM connection
• any announce request made to any such tracker is recorded as an "i2p" request and will interpret the response specially. It will treat the "peers" field as a compact list of 32 byte addresses.
• Any tracker that responds with the old peer-list style (of strings for peer IPs or hostname) where a peer hostname ends with ".i2p" and the session has a SAM connection, the peer will be contacted via the SAM connection.

One weird quirk right now is the allow_i2p_mixed. What this setting does is it prevents adding non-i2p peers to the peer-list, if the torrent is an i2p torrent. This is determined by if the .torrent file has a tracker whose hostname ends with .i2p. This is problematic for i2p magnet links. Their .torrent file won't have any trackers. The trackers were added separately.

This probably needs fixing. I'm open to suggestions of other tweaks to these rules (ideally in the direction of making them simpler and more intuitive).

[Vort]

This is problematic for i2p magnet links.

It may be also problematic when user want to download clearnet torrent and change tracker to i2p one with torrent client. Ideally this should convert torrent to "i2p mode" and block clearnet connections unless user enables mixed mode.

Another similar question is how DHT behaves when i2p torrent is added. It should not leak IP<->BTIH connection unless mixed mode is enabled. Ideally, it also should use i2p DHT modification in cases of i2p torrents, however it is not urgent, most important is to prevent leaks.

[arvidn]

#7362

With this treating a torrent as i2p-mode or not becomes explicit.

[glassez]

What if some torrent contains both regular and i2p trackers?

[arvidn]

then it's considered an i2p torrent, and will not allow regular peers unless allow_i2p_mixed is true (but it defaults to false).

Currently, it may still announce to the plain trackers, it just won't connect to any of the peers. I'm fixing that to not even announce to non-i2p trackers when in i2p mode in #7362

[glassez]

Currently, it may still announce to the plain trackers, it just won't connect to any of the peers. I'm fixing that to not even announce to non-i2p trackers when in i2p mode in #7362

👍

then it's considered an i2p torrent, and will not allow regular peers unless allow_i2p_mixed is true (but it defaults to false).

Does adding/removing trackers behave consistently? I.e.:

1. Adding i2p tracker. I expect that it should turn torrent to i2p mode and disconnect it from regular peers (stop announcing to regular trackers) in case of disabled allow_i2p_mixed
2. Removing last i2p tracker. I expect that it should turn torrent to non-i2p mode

What if non-i2p torrent received i2p peers from regular tracker (is it possible?) or from user (manually added)?

I think if you really want to define a "strict i2p torrent" model, then all such questions should be answered so that it is consistent.

[arvidn]

Does adding/removing trackers behave consistently? I.e.:

1. Adding i2p tracker. I expect that it should turn torrent to i2p mode and disconnect it from regular peers (stop announcing to regular trackers) in case of disabled allow_i2p_mixed
2. Removing last i2p tracker. I expect that it should turn torrent to non-i2p mode

Currently, a torrent is only considered an i2p-torrent if you add it as a .torrent file, and it contains a tracker with an i2p URL. That's it.

With #7362 the situation is improved. There's torrent flag added to indicate whether a torrent should be treated as an i2p torrent or not. It's set automatically when loading a .torrent file with an i2p tracker, or parsing a magnet URI including an i2p tracker. It can then be altered explicitly by the client, via the new torrent flag.

What if non-i2p torrent received i2p peers from regular tracker (is it possible?) or from user (manually added)?

That's supposed to work, as long as the client has configured a SAM connection. The restriction introduced by allow_i2p_mixed only affects i2p torrents, not regular torrents.

I believe the documentation in #7362 is consistent with this description