Opened at 2016-12-29T19:42:04Z
Closed at 2017-01-18T01:14:21Z
#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: |
Description
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
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:
Note: See
TracTickets for help on using
tickets.
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.