Opened 17 months ago

Last modified 2 months ago

#21003 new defect

extend_info_describe should list IPv6 address (if present)

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: easy intro ipv6 logging
Cc: Actual Points:
Parent ID: Points: 0.5
Reviewer: Sponsor:

Description (last modified by teor)

When running an IPv6-only client using:

src/or/tor ClientUseIPv4 0 DataDirectory `mktemp -d` UseMicrodescriptors 0

I get log messages like
[info] add_an_entry_guard(): Chose $906933A309F15D7CF379127078A6791DF9B0C763~Unnamed at 91.121.82.25 as new entry guard

But I'm really contacting them on their IPv6 address. So we should list it along with the IPv4 address.

Child Tickets

Change History (11)

comment:1 Changed 17 months ago by teor

Description: modified (diff)

comment:2 Changed 17 months ago by teor

(This only makes sense for entry nodes: (directory) guards, bridges, fallbacks, authorities - all other relays are referred to by their IPv4 addresses.)

Last edited 16 months ago by teor (previous) (diff)

comment:3 Changed 16 months ago by teor

This is a problem with the address chosen by the calling code: an extend_info only has one tor_addr_t in it.

comment:4 Changed 11 months ago by nickm

Keywords: logging added

comment:5 Changed 3 months ago by valentecaio

Is this ticket still valid?

According to teor comments, only entry nodes should be concerned by it.
I've run an IPv6 client (ClientUseIPv4 0 UseMicrodescriptors 0) and I can't find any log of entry points using an IPv4 address.
However, other nodes are referred to by their IPv4 addresses.

An example:

[debug] onion_extend_cpath(): Chose router $A6EDA578BA3CA94AB207841DBD468B0FF991643B~FalkensteinTor01 at 2a01:4f8:1c17:4216::1 for hop #1 (exit is inwaiting)
[debug] onion_extend_cpath(): Chose router $AC153580D1DE33051AFC975C7108BCD31CBBC9A1~spaghetti2 at 176.31.181.71 for hop #2 (exit is inwaiting)
[debug] onion_extend_cpath(): Chose router $18BFF1DEAA073003108CFDA2C0DE970D8F604478~inwaiting at 178.175.138.98 for hop #3 (exit is inwaiting)

comment:6 Changed 3 months ago by teor

Yes, this ticket is about log messages that look like:

[info] add_an_entry_guard(): Chose %s as new entry guard

where %s is the output of extend_info_describe().

But it is good to see that messages like:

[debug] onion_extend_cpath(): Chose router %s for hop #%d (%s)

work correctly.

comment:7 Changed 2 months ago by meryemz

I can't reproduce this output:

[info] add_an_entry_guard(): Chose %s as new entry guard

I think the function: add_an_entry_guard() has been deleted somewhere between the versions 0.2.3 and 0.2.4 .
Is there any other function with the same bug?

comment:8 Changed 2 months ago by valentecaio

I would add that we have four functions for describing routers and nodes:

const char *router_describe(const routerinfo_t *ri);
const char *node_describe(const node_t *node);
const char *routerstatus_describe(const routerstatus_t *ri);
const char *extend_info_describe(const extend_info_t *ei);

But three of them use IPv4 addresses when describing the node.
The only one that can use IPv6 is extend_info_describe().

comment:9 Changed 2 months ago by teor

Ok, then they should all be modified so they can use IPv6.
In particular, each of the first 3 functions takes a struct with an IPv4 and IPv6 address, and so it should report both, if they are present.

comment:10 Changed 2 months ago by valentecaio

Do you think it would be better to be able to show both addresses?

By now, the buffer used has space for this output format:

"$FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF~xxxxxxxxxxxxxxxxxxx at 
[ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255]"

But I think the functions only return strings in one of the following formats (please confirm this if you can):

"$FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF~xxxxxxxxxxxxxxxxxxx at ffff:ffff:ffff:ffff:ffff:ffff"
or
"$FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF~xxxxxxxxxxxxxxxxxxx at 255.255.255.255"

We could add a separator and show both addresses, something like (increasing the buffer size by 2):

"$FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF~xxxxxxxxxxxxxxxxxxx at 
[ffff:ffff:ffff:ffff:ffff:ffff | 255.255.255.255]"

And we could let the caller decide what address it want as output (only IPv4, only IPv6 or both), letting "only IPv4" as default.

What do you think about this?

Last edited 2 months ago by valentecaio (previous) (diff)

comment:11 in reply to:  10 Changed 2 months ago by teor

Replying to valentecaio:

Do you think it would be better to be able to show both addresses?

By now, the buffer used has space for this output format:

"$FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF~xxxxxxxxxxxxxxxxxxx at 
[ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255]"

This legacy format prints the last 4 bytes of the IPv6 address like an IPv4 address, it is never used in Tor.

But I think the functions only return strings in one of the following formats (please confirm this if you can):

"$FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF~xxxxxxxxxxxxxxxxxxx at ffff:ffff:ffff:ffff:ffff:ffff"
or
"$FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF~xxxxxxxxxxxxxxxxxxx at 255.255.255.255"

An IPv6 address has 128 bits, yours is 32 bits short.
We are trying to always print IPv6 addresses between brackets.

We could add a separator and show both addresses, something like (increasing the buffer size by 2):

"$FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF~xxxxxxxxxxxxxxxxxxx at 
[ffff:ffff:ffff:ffff:ffff:ffff | 255.255.255.255]"

The IPv6 address should be last, and in brackets.
The IPv4 address should not be in brackets.
I suggest using "or", to match "at".

And we could let the caller decide what address it want as output (only IPv4, only IPv6 or both), letting "only IPv4" as default.

We should always print all the addresses that are present.

What do you think about this?

Let's make it happen

Edit: spelling

Last edited 2 months ago by teor (previous) (diff)
Note: See TracTickets for help on using tickets.