Opened 8 years ago

Closed 3 years ago

#1050 closed defect (fixed)

Hostnames published in netdb

Reported by: zzz Owned by: zzz
Priority: minor Milestone: 0.9.32
Component: router/transport Version:
Keywords: ntcp ssu Cc:
Parent Tickets: Sensitive: no

Description (last modified by str4d)

If user configures a hostname on /confignet, it should be published as a hostname for both NTCP and SSU. Right now (, that's true only for NTCP; SSU publishes the IP address.

The massive changes for IPv6 in 0.9.8 may have broken it further. Most of the code in CSFI was moved to NTCP. CSFI.notifyReplaceAddress() calls Transport.externalAddressReceived() but it takes a numeric IP only. As a result, NTCP probably will publish a numeric address. externalAddressReceived() probably needs to be changed to take an InetAddress?. Not clear what SSU will publish. Needs testing. Maybe it all is working but I doubt it.


Change History (6)

comment:1 Changed 7 years ago by str4d

Description: modified (diff)
Keywords: ntcp ssu added
Milestone: 0.9.9

comment:2 Changed 6 years ago by zzz

Milestone: 0.9.25
Status: newaccepted

This is still a thing. A hostname configured in 'IP configuration' on /confignet is only used for the SSU address, even if NTCP is configured for 'auto-detected'. The workaround is for the hostname to be specified in the form for NTCP as well.

The hostname is lost in CSFI.notifyReplaceAddress(). The TransportManager? and Transport methods externalAddressReceived() only take a byte[] IP. We could replace that argument with an InetAddress? but we'd have to be careful with when it's resolved. Neither INetAddress nor InetSocketAddress? may be appropriate, even with ISA.createUnresolved(). We could just create our own class containing a String and a byte[]. replaceExternalAddress() ripples a long way so this could get messy.

Alternative is to just force the NTCP config or otherwise hack around it, e.g. in NTCPTransport.externalAddressReceived()

comment:3 Changed 5 years ago by zzz


comment:4 Changed 5 years ago by zzz


Related fix in e33d07c942bb021d5a6c6b6641d8974aed589956 to be 0.9.25-12, bind all v4 and v6 addresses (rather than first v4 only) for a hostname. This doesn't fix the above problem. It still publishes v4 and v6 for NTCP, and after this change, publishes a v6 for SSU also. but…

Another thing to fix is that when resolving a hostname for connecting, we use InetAddress?.getByName(), which returns v4 unless all it has is v6… like for the -12 fix, we could use getAllByName(), but that will require changes in RouterAddress? and the transports, and some way to pick the preferred one.

So actually, since we don't have that fix yet, hostnames only in the netdb precludes v6 and so isn't the best thing to do for now.

comment:5 Changed 5 years ago by zzz


Initial work in Addresses utility in a06a45135a71e024de4fb50064e832f5cba32b1d 0.9.27-6

comment:6 Changed 3 years ago by zzz

Resolution: fixed
Status: acceptedclosed

We went the other direction instead. Hostnames were removed from netdb entries in 0.9.32 as documented in proposal 141 http://i2p-projekt.i2p/spec/proposals/141-deprecate-hostnames-in-addresses

Note: See TracTickets for help on using tickets.