Opened 7 weeks ago

Closed 9 days ago

#2345 closed defect (not our bug)

I2CP does not support identical clients

Reported by: jogger Owned by:
Priority: minor Milestone: undecided
Component: api/i2cp Version: 0.9.37
Keywords: Cc:
Parent Tickets:

Description

I tried to connect via I2CP from identical clients on different IPs (try BiglyBT with the i2p helper). Connections made are kicked on each connect/disconnect from the other machine.

Subtickets

Change History (5)

comment:1 Changed 6 weeks ago by echelon

  • Component changed from unspecified to api/i2cp
  • Priority changed from major to minor
  • Status changed from new to infoneeded_new

Do they use the same setup, port, config, key?

comment:2 Changed 5 weeks ago by jogger

  • Status changed from infoneeded_new to new

I have two identical BiglyBT instances on different machines. They connect on port 7654 and generate a single entry "BIGLYBT: DHT PURE" in the router console. When one instance is started the other one gets stalled and vice versa.

comment:3 Changed 3 weeks ago by zzz

  • Status changed from new to infoneeded_new

Not a lot of explanation, please tell me if I have it right: you have two different biglyBT instances connecting to the same router via I2CP. You say they are "identical" - what does that mean? Same client destination (b32) ? That's not allowed and I2CP will reject two connections with the same destination.

There's not enough info here to know if it's a I2P or a Bigly issue. Please attach more info and some logs indicating the problem.

comment:4 Changed 10 days ago by jogger

  • Status changed from infoneeded_new to new

You are perfectly right. Cloned a config and BiglyBT defaults to change the address only every 7 days. Now 7 days are over and it works. Sorry, thought it was the ID shown in the console that Snark standalone randomizes.

comment:5 Changed 9 days ago by zzz

  • Resolution set to not our bug
  • Status changed from new to closed

OK, so it appears that I2P is correctly rejecting the client with the duplicate destination. You didn't supply any logs but I presume that I2P was logging the error and delivering the error to BiglyBT via I2CP. If you think BiglyBT should do a better job of getting that message to the user you can discuss it with the Bigly devs.

Note: See TracTickets for help on using tickets.