Bug #9324

I2P fails to start in current stable

Added by intrigeri 2015-05-01 11:52:20 . Updated 2015-05-12 18:35:41 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Target version:
Tails_1.4
Start date:
2015-05-01
Due date:
% Done:

100%

Feature Branch:
kytv:bugfix/9324-i2p-start
Type of work:
Code
Blueprint:

Starter:
Affected tool:
I2P
Deliverable for:

Description

On current stable branch: boot, add i2p to the kernel cmdline, set an admin passwd + enable win camouflage, wait => “I2P failed to start” notification. Full /var/log/i2p/wrapper.log is attached. Can’t reproduce on 1.3.2, hence the >normal priority.

Note that both I2P (in a stable branch? hmm…) and Java were updated in the meantime:

-i2p    0.9.18-1~deb7u+1
-i2p-router     0.9.18-1~deb7u+1
+i2p    0.9.19-3~deb7u+1
+i2p-router     0.9.19-3~deb7u+1
[...]
-openjdk-7-jre:i386     7u75-2.5.4-1~deb7u1
-openjdk-7-jre-headless:i386    7u75-2.5.4-1~deb7u1
+openjdk-7-jre:i386     7u79-2.5.5-1~deb7u1
+openjdk-7-jre-headless:i386    7u79-2.5.5-1~deb7u1

Files

i2p-wrapper.log (8178 B) intrigeri, 2015-05-01 11:50:19

Subtasks

History

#1 Updated by kytv 2015-05-01 13:46:55

  • Status changed from Confirmed to Fix committed
  • Type of work changed from Research to Code

The problem is in the i2p_router_console_is_ready() and i2p_has_bootstrapped() checks in the shell library. For whatever reason netstat isn’t returning the listening ports.

This doesn’t make sense to me whether it’s apparmor or not because I did test it in Tails. A lot. Hmm :|

It seems the fix might just be changing the netstat parameters to -nlp. Testing.

#2 Updated by kytv 2015-05-01 15:04:30

  • Status changed from Fix committed to In Progress
  • Assignee changed from kytv to intrigeri
  • % Done changed from 0 to 40
  • QA Check set to Ready for QA
  • Feature Branch set to kytv:bugfix/9324-i2p-start

Indeed, something changed recently. Without the 4 in the parameters the checks work again, with I2P starting as it used to. The | TERM trapped. Shutting down. in the wrapper.log proved to me that it wasn’t I2P doing it, but Tails within a minute (or so) of attempting to start.

Note that /usr/local/sbin/tails-i2p has the following line:

I2P_STARTUP_TIMEOUT=60

After the proposed changes, I2P starts as it did just a week or so ago.

# netstat -nlp |grep '7657\|4444'
tcp6       0      0 127.0.0.1:4444          :::*                    LISTEN      6314/java       
tcp6       0      0 127.0.0.1:7657          :::*                    LISTEN      6314/java

#3 Updated by intrigeri 2015-05-02 01:06:54

  • Assignee changed from intrigeri to anonym

#4 Updated by kytv 2015-05-02 05:45:44

Applied in changeset commit:5d749dc3148a6e87b10784b73dcb7d1a470da815.

#5 Updated by anonym 2015-05-02 05:45:44

  • Status changed from In Progress to Fix committed
  • % Done changed from 40 to 100

Applied in changeset commit:e57eb4fedd28255403db447ef8f1b5d425e2b74a.

#6 Updated by anonym 2015-05-02 05:48:46

  • Assignee deleted (anonym)
  • QA Check changed from Ready for QA to Pass

Interesting change. The reason for netstat -4 was to explicitly avoid finding the router console running on a TCP6 port, since we’d block access to it via our netfilter rules.

#7 Updated by kytv 2015-05-02 08:23:59

anonym wrote:
> Interesting change. The reason for netstat -4 was to explicitly avoid finding the router console running on a TCP6 port, since we’d block access to it via our netfilter rules.

IIRC I added the -4 myself. But as you can see it is still listening on IPv4 but with TCP6 instead of TCP? What’s that about? I have no idea. :|

[This is kinda annoying because it sort of looks like I didn’t test anything…but I did. Grrrr.]

#8 Updated by BitingBird 2015-05-12 18:35:41

  • Status changed from Fix committed to Resolved