Bug in tunnel creation

[DISABLED]

I think I have come across a bug in the creation of tunnels for services.

The following happened: I had two tunnels for two different eepsites running for months without any problem. Than I was creating a third, also for an eepsite. Seemingly everything went smooth. But when I was checking on the eepsite of tunnel nr. 1, I landed on the eepsite behind tunnel nr. 3. It took me a bit to figure out that the third tunnel had the same b32 adress as the first one (which caused a kind of unintentional multihoming, I guess). Creating a forth tunnel and deleting the third solved it, but this should actually never happen.

I believe this is the relevant log entry:

29.07.15 08:07:02 KRITISCH [Reader 11771] 2p.router.client.ClientManager?: Client attempted to register duplicate destination NDSvUUvCiOucqs~c-pybyA9PJO7mlVwdrxYtDIcgIJg=

Thanks,

Guest

[zzz]

Yes, the default tunnel keys file name i2ptunnelXX-privkeys.dat is generated when the new i2ptunnel entry is created. But that configuration isn't changed (nor is the file renamed) after tunnels are added/removed, even though all the property names tunnel.XX.foo get renumbered in i2ptunnel.config. So deletes and adds in a particular order can cause duplicates.

We should check for existence when defaulting. See GeneralHelper?.deleteTunnel() and getPrivateKeyFile().

This has been an issue since forever. The rename fixes in deleteTunnel() are from quite a while ago, but obviously are not a complete solution.

[zzz]

Fixed to not default to a file that already exists.

In 434b58a5892ab0854e543a42b56b7eec530a2a06 to be 0.9.24-10-rc