#2858 closed defect (fixed)

i2p connectivity ordering problem for storage nodes

Reported by: dawuud Owned by: Brian Warner <warner@…>
Priority: major Milestone: 1.12.1
Component: code-network Version: 1.12.0
Keywords: i2p Cc:
Launchpad Bug:


str4d reports: tldr; because client connections were made before the server tub was started, the I2P session for the process was started with transient keys instead of the keypair for the server. This meant that the server tub was listening on a transient Destination that did not match the advertised tub.location.

Change History (6)

comment:1 Changed at 2016-12-29T20:11:44Z by warner

hm, it sounds like the order of startService is important.. maybe to make this work, we need the Tub to be started earlier than anything which might queue a call to getReference.

comment:2 Changed at 2016-12-29T20:17:19Z by warner

  • Component changed from unknown to code-network
  • Milestone changed from undecided to 1.12.1

comment:3 Changed at 2017-01-10T17:11:35Z by daira

  • Priority changed from normal to major

comment:4 Changed at 2017-01-10T17:32:10Z by daira

  • Keywords i2p added

comment:5 Changed at 2017-01-17T16:42:32Z by warner

Will this be fixed by the changes in https://github.com/tahoe-lafs/tahoe-lafs/pull/394 ?

comment:6 Changed at 2017-01-18T01:14:21Z by Brian Warner <warner@…>

  • Owner set to Brian Warner <warner@…>
  • Resolution set to fixed
  • Status changed from new to closed

In 998af5c/trunk:

Pass I2P keyfile to foolscap

If no session management is performed, txi2p starts a process-wide session the
first time a connection (client or server) is opened; all subsequent connections
use that session and its configuration properties.

This commit ensures that the same properties are passed to both client and
server endpoints, so that the correct I2P Destination is started regardless of
whether the first connection made by Tahoe-LAFS is for a client or server.

Closes #2858.

Note: See TracTickets for help on using tickets.