Opened 3 years ago

Last modified 3 weeks ago

#1697 assigned defect

Please write to the log when I2P is ready for use

Reported by: killyourtv Owned by: mhatta
Priority: minor Milestone: 0.9.39
Component: apps/i2ptunnel Version: 0.9.22
Keywords: Cc: mhatta, zzz, zab
Parent Tickets:


To demonstrate what I'm seeking, Tor logs the following to its log:

Oct 27 10:42:00.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.

This would be of use within Tails, for example. I'd be happy with a log entry when the Shared Clients tunnel has a green star next to it and/or a log entry for the eepsite or irc2p tunnel.

Subtickets (add)

Change History (14)

comment:1 Changed 3 years ago by killyourtv

In previous versions of I2P (or java?) one could reliably check whether port 4444 was open using `netstat -nlp |grep 4444' but this doesn't work any longer. Perhaps this is related to #1698?

comment:2 Changed 3 years ago by zzz

... and you're going to programmatically look for that log message and do something in tails? Or is this just to assist diagnosis of user's problems?

If the former, perhaps there's better ways (i2pcontrol?)
If the latter, is this the best way to do it?

Either way, a log message sounds rather ad hoc.

Looking for 4444 with netstat should work, but as you say, #1698 / #1650 may be related

comment:3 Changed 3 years ago by killyourtv

One of my tasks with Tails was/is to write I2P tests for use with their automated test suite. I discovered #1698/#1650 in the process when tests which should have passed were instead consistently failing because my tests were running before I2P was ready.

I2PControl wouldn't work for what I have in mind since that would require the plugin to be installed, new ports to be allowed through the firewall, etc.

I'm just looking for some reliable way to gauge whether I2P can be used without relying on static sleeps and which can be scripted.

comment:4 Changed 3 years ago by zzz

Thanks for filling us in on the big picture.

If this is only for automated testing, then presumably it can be enabled with some config option, and I am much less concerned about making it general-purpose or 'pretty'.

Without changes, you could scrape and grep for the 'green star', although that's fragile. With changes, you could scrape /debug or /oldconsole to look for something we put in there.

Other alternatives: the event log, or some status file or other output.

comment:5 Changed 3 years ago by zzz

Fix in #1650 may make this less pressing? Please test.

comment:6 Changed 3 years ago by killyourtv

Unfortunately, checking whether port 4444 is open is still not a reliable way of checking whether the HTTP Proxy tunnel is ready.

I do not know when this changed but I think it was within the last 5-6 months.

comment:7 Changed 3 years ago by zzz

It certainly wouldn't be if the tunnel is set for delay-open, but that's not the default for us, and probably not for tails. And yes we probably do open the socket now before we start building tunnels. Did it change recently? Not sure, but probably doesn't matter.

Is an output to a log file your preferred solution, or would some other facility (possibly from those listed in comment 4) be better?

comment:8 Changed 3 years ago by str4d

  • Status changed from new to open

comment:9 Changed 3 years ago by zzz

  • Component changed from router/general to package/other
  • Owner set to pr0ng
  • Status changed from open to assigned

Reassigning to the new Tails maintainer, pr0ng, for re-evaluation and a proposal if necessary.

comment:10 Changed 13 months ago by zzz

  • Cc mhatta added
  • Milestone changed from undecided to 0.9.34
  • Owner changed from pr0ng to zzz

This or some alternative (console scraping? i2pcontrol?) is needed to get back into Tails. Not just for testing.

comment:11 Changed 9 months ago by zzz

  • Component changed from package/other to apps/i2ptunnel
  • Milestone changed from 0.9.34 to 0.9.35

@mhatta need requirements ASAP if this is going into .35

comment:12 Changed 8 months ago by zzz

  • Owner changed from zzz to mhatta

reassigning to mhatta, please reassign back to me when you have specified the requirements

comment:13 Changed 4 weeks ago by mhatta

  • Cc zzz added

Some memo based on the meeting at 35c3:

What Tor on Tails does:

Tails uses a Sys Tray application called onioncircuits (git repo:, also in Debian: to notify users when Tor is ready. This is written in Python, uses Tor control library called Stem (, also available in Debian: Stem employs Tor Control Protocol (spec:

I2P has its own Sys Tray app (DesktopGUI), but currently, it's disabled by default on GNU/Linux. There is a plugin called I2PControl which provides JSONRPC2-based interface to a running I2P instance.

onioncircuits - Stem library - Tor control protocol is not equal to DesktopGUI - I2PControl.

comment:14 Changed 3 weeks ago by zzz

  • Cc zab added
  • Milestone changed from 0.9.35 to 0.9.39

Also: we discussed the namespace problem, that there's no namespace for tunnels other than the dest hash, there's no way on the router side to identify the proxy tunnel, the user-visible names are not unique.

However, we do have a namespace for services that provide ports. The PortMapper? subsystem (which is just a HashMap?) allows services to register a port. That subsystem has a namespace, and the proxy does register with it. See /debug in the console to see the current state, see PortMapper?.java for the defined names.

If the tunnel's i2cp.delayOpen option is true, the port will be opened and registered before tunnels are built, but if it's false, that won't happen until we have tunnels. The default is false.

So I think we can hook something into PortMapper?, or into I2PTunnelHTTPClient (appx line 330), or into i2pcontrol to check with the PortMapper?, to do this.

Depends on if we want a polling interface, or a notification such as writing to a file. Also, what happens on shutdown (or even tunnel breakage, we lose all our tunnels), do we need to notify that as well?

Note: See TracTickets for help on using tickets.