Had some strange things happening within the last update of I2P. The router console didn’t come up after the update, which made me think router wouldn’t be running. Here’s what happened ….

The update was a mess overall. I had the package sources of killyourtv activated (using .i2p addresses). These reported download errors during apt-get upgrade. The following installation reported no errors then, though. I assumed here that some package could not be updated due to the download problems. As the router console wasn’t reachable I assumed something went wrong.

So I removed the i2p-sources and attempted to update/upgrade again. Nothing to install it said, hm. Still no router console. So I went and did a remove/clean/install on i2p and i2p-router. Still the same.

I was like “wtf …” and started to take a closer look. The router actually was running (process running) and actually functional besides the router console (could open i2p-addresses as usual). The log revealed that the client “Router Console” couldn’t be started due to problems with the keystore. I was using SSL to access the router console as I don’t use a locally hosted router, but one for the whole LAN. Removing the according -s the router console was accessible without SSL. But I want to use SSL, so what do I do now?

Next I asked in IRC and zzz responded, but after all wanted me to open a ticket, so I did that. In the ticket I tried to describe the problem in more detail. As an answer he explained some of the mechanisms.

What Happened?

There are two passwords in the router.config: keyPassword (a long random string or so), and a keystorePassword, which is set to “changeit”. Now seeing this, I immediately remembered to have “met” this changeit. And I also remember to have done as told, and actually changed it. Still unsure what happened here, but I tried to change the keystorePassword back to “changeit”. After a restart, the SSL was working again.

So for now it feels, one rather shouldn’t change “changeit”, or what? Interesting at least. I did try to find this information in a documentation but did not succeed. This might be just dumb me again. But it might also give a hint that we should improve documentation here?

Resetting SSL as described by zzz in the ticket:

To start over, stop i2p, delete the keystore and remove the two password lines from the router.config file, then add the ‘-s’ back to clients.config.

For me it seems there was a new key generated throughout the update and that this key assumed the unchanged pre-set keystorePassword. But why is that called as it is then? Or did I never restart the router after changing the password and a restart would have failed also? Unsure about this. I still don’t fully understand the mechanisms involved, I must admit. Change it or not? What’s the impact? Why are keys generated for a specific preset password but the password defined isn’t used?

The Reporting Problem

Now although I was able to create a ticket at http://trac.i2p2.i2p just fine, I find myself unable to add a comment to that ticket now. So how do I reply to zzz here? Would like to report/ask the above, but on the page there is button to reply or anything. For now my usage was without Javascript, so that might be related. Anyhow, here are screenshots from what I get in Trac, maybe I’m just blind and don’t see “the thing”?

Screenshot Page Start


Screenshot Page End

To keep the screenshots rather small, I omitted the cited code inbetween. The button to reply shouldn’t at least be there ;)

Update

It’s not a bug at all. The keystore is a Java mechanism for key management. Keystores are protected with a password for conistency (!?). Strange they name it password then. However, by changing that password I denied access to the keystore-file, hence the router-console couldn’t get the certificate for SSL and therefore didn’t start.

About the comments on the ticket: One needs a special permission to write comments. My account was granted that permission in the process, that’s what allowed me to write the comments there and then also to close the ticket.