Recent comments in /f/I2P

cumlord wrote (edited )

it probably could, to me that along with traffic analysis are things that fall more into state sponsored level attack. guess avoiding those chipsets is the way or disabling it, but only 3 people are going to do that. like i'd think that at least with intel it's basically a backdoor, probably would take a fair amount of effort for someone outside of them to exploit it. but i guess that doesn't stop intel from gathering intel, lol

there's a surprising amount of low-lying fruit that can be way easier to do for non state actors. Best to assume your ip address is known to be running i2p as public knowledge, and like just poking around the netdb will give info that can sometimes lead to deanon if not careful

1

blueraspberryesketimine OP wrote (edited )

I wonder how the intel management engine and AMD PSP could be used to track I2P users. They make up the majority of the nodes on this network. We really don't have a way to fight that unless we all jump to RISC-V right? Also, that article is interesting but incredibly outdated. It's from 2010. Id imagine the security posture of i2p has improved dramatically since then.

1

cumlord wrote

you should be able to set the port like z3d said and it'll only use that, dangerous to share obviously because port scanning could be done to identify from suspected ips

i think in theory this is probably true to an extent, we're getting into the realm of traffic analysis. There's some info on this on http://i2p-projekt.i2p/en/docs/how/threat-model

1

righttoprivacy wrote (edited )

As not_bob mentioned, it's useful.

I2P+ comes with feature rich console interface, one that also happens to be a great place for beginners to start out - doesn't mean users would need to keep the outproxy.

Some otherwise might not have opportunity to try outproxy (some lazy, some unsure how).

And having access to browse clearnet also means a user is more likely to keep an i2p browser (in turn, i2prouter) set up - this means more traffic for all of us. And that's good for all.

In this way, I'd say it's a win win, to have built in (by default, not required to keep).

3

blueraspberryesketimine OP wrote (edited )

incorrect. The port the relay uses to the outside world is random and not to be disclosed, and certainly never a fixed port posted on a ramble post. Also, this fails to address my question. products like the firewalla purple can phone home and keep track of all the connections made on the port I granted a firewall exception to. My question was whats stopping the companies behind these products (or even just he ISPs themselves) from linking all the connections people are making on I2P? They wouldn't know the content of the data being sent but they would be able to piece together the paths it took potentially leading to deanon.

1

z3d wrote (edited )

There's no way to create an exception for i2p as the destinations vary.

Allow all inbound and outbound traffic on your configured TCP and UDP port indicated on http://127.0.0.1:7657/confignet#udpconfig in I2P+. You should expect that traffic to only be handled by your Java runtime. No other ports on I2P need to exposed publicly (in your firewall).

1

blueraspberryesketimine OP wrote

I wonder why i2pd has a lower rate than i2p+. Does it just have a different way of evaluating that metric?

I'm continuing to experiment with this and torrents. I migrated it back to my server and tried taking it out of the container since I was running the container rootless when I first tried it there. rootless podman containers supposedly have issues with UDP connections. The torrenting speed in qbittorrent and snark are a little better, but still topping out at only about 200k so there's still more room for tweaking here.

Right now, things seem more stable with I2P+ than I2PD, but I'm blaming that squarely on my own ignorance in how to properly tune this setup.

I'm really excited to see how that emissary project grows too, but I'm not sure I trust it just yet. I'm going to wait for others who actually know what they are doing to vet the project as well as SSU2 support to finish before I give it a try.

1

cumlord wrote (edited )

i assumed which is why i brought up the i2cp thing earlier, but wasn't sure if you had it in some other container or something in the other machine that'd be blocking connections, must've had something going on with the firewall somewhere

weird about the wrapper, never tried it on alpine linux so maybe there's a workaround or the i2prouter script could be modified. jbigi i've had to compile to get it to work right at least with i2p+ sometimes. if you don't see libjbigi.so in your /i2p directory then you'd just need to compile it

the devs are around here, quickest answer to get the wrapper to work right would be to pop in to irc2p

pretty good breakdown, if you end up messing around in both you'll find they can be good for different things. i2p+ is more selective and wants to put resources to things like service tunnels, it happens to be very good for hosting things in i2p and if you want to do other stuff on top of torrents/eepsites. i2pd is bare bones and uses little resources, usually very fast if tunnel build success is good, good for torrenting. it has its own trade offs. i watch the memory usage on that one closely. I like i2pd a lot for certain things but i've learned you do need to be careful with it at times and set conservative limits

i2p+ will usually see build success +70%, i2pd should hang somewhere around 30-50, lower with floodfill. In practice though i2pd should be running great at 30-50, but if it drops under 10 you get problems.

1

blueraspberryesketimine OP wrote

I decided to try running i2p+ on the same equipment as a comparison to see if it works better for me than i2pd. I have some issues with it.

First, I can't get it to use the wrapper. I'm running it in alpine linux aarch64. Looking at the i2prouter script, it doesn't seem to have any way to handle aarch64, though interestingly it does still have the older ARM architectures in the script. I suspect this is why it doesn't want to use the wrapper, even though the wrapper itself does support aarch64. I was able to work around this temporarily with runplain.sh but it's not quite ideal as I'd like to allocate more ram to i2p+. I also want to get jbigi loaded in, but I suspect the wrapper might be needed for that to work anyway.

Anyway, my findings so far in comparing the two on this aarch64 relay:

  • i2pd is way faster to bring up and tear down, though we expected that
  • i2pd uses next to no ram.
  • i2pd is rocket fast but then seems to eventually stop responding to http after being used for a while
  • i2p+ is heavy, but not as bad as I thought it would be. A diskless alpine system is running quite happily at less than 1G of ram used. Seeing as this board has 4GB on it, I still have some room to test further after I can allocate more to the JVM after fixing the wrapper.
  • i2p+ is pretty! :)
  • i2p+ definitely has a higher tunnel success rate the i2pd but it also takes a lot longer to get that high. It's camping out at 83% now. I never got that high with i2pd.
  • i2p+ creates significantly fewer tunnels than i2pd. i2pd would have over 6600 tunnels created at times, just giving away all the bandwidth I had to offer it and coming nowhere near taxing the CPU or memory available on the host. i2p+ seems much more conservative in how it participates with the network. Whereas i2pd would build fast, it would also shed a lot of its tunnels whereas i2p+ can maintain connections better. I suspect I could improve that behavior in i2pd by assigning limits but I'm still feeling this thing out, trying to find where the limits are.
2

blueraspberryesketimine OP wrote

Its actually running on a separate physical device. I wanted to put in the media server itself, but my container network skills aren't great and that server get taken down from time to time for me to mess with. Uptime matters here, so it made sense to keep i2p separated from the server.

1

blueraspberryesketimine OP wrote

I better isolated the i2pd machine on my network just in case something goes wrong with it and I don't notice right away. While doing so, I noticed roughly half the connections to the i2p relay port are being blocked by my firewall. Strangely, the firewall is set to allow all on that port. It says it's blocking based on ingress firewall's IP filtering rules.

What rules? I didn't give it any rules. If it's unsolicited, it's blocked, but the i2p relay is requesting those connections so the firewall shouldn't be blocking them, right?

1

cumlord wrote

i'm not sure about SAM since this is qbit, but with I2CP running either biglybt or snark can be glitchy on separate machines especially with i2pd, java seems to handle random disconnects better where i2pd might not recover, possibly due to latency. As far as i know I2CP is intended to be used on the same machine. you can do this but it runs much better with java routers from what i've found where i think i2pd is best if you keep it on the same machine.

possibly things to check - trackers are working since no dht, in a good swarm, tunnel quantity/number of hops. like are peers available or is it a throughput issue

1

c00kiepast3 wrote

I used to play around with different bittorrent clients for weeks when I first found out about I2P. I tried i2psnark, qbittorrent, XD, BiglyBT but now I have settled using qBittorrent-nox with SAM protocol to i2pd node. Both are on same computer, because I read from IRC that its not good to have them on seperate computers. I mean your i2pd node and your qbittorrent client.

I have disabled DHT, PEX and other stuff in qBittorrent and I only download torrents from the Postman Tracker.

3

altonen wrote

I agree with what zzz said. The project is in the early phase so it's still missing a lot of features and "institutional knowledge" that java and i2pd have. I hope that by EoY most of the missing features have been implemented and the most glaring bugs have been fixed.

All help with testing and development is deeply appreciated.

3