Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#5534 closed enhancement (implemented)

Make bridge authorities add "a" lines to router status entries

Reported by: ln5 Owned by: ln5
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-auth
Cc: karsten Actual Points:
Parent ID: #4563 Points:
Reviewer: Sponsor:

Description

As per prop 186, an "a" line should be added to router status entries
in network status documents for each reachable bridge.

Child Tickets

Change History (28)

comment:1 Changed 7 years ago by ln5

Owner: set to ln5
Status: newassigned

Depends on #5533.

comment:2 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-final

comment:3 Changed 7 years ago by ln5

Branch ipv6-phase3 in my repo implements this.

Current code assumes that a bridge authority has IPv6 connectivity and
will not any "a" lines since it cannot reach any IPv6 OR ports.

TODO: Add a configuration option telling tor if it's supposed to have
IPv6 connectivity. This will be something like
AuthorityHasIPv6Connectivity 0|1|auto. Clients and ordinary relays
will have to detect this.

comment:4 in reply to:  3 Changed 7 years ago by ln5

Replying to ln5:

Current code assumes that a bridge authority has IPv6 connectivity and
will not any "a" lines since it cannot reach any IPv6 OR ports.

Bad phrasing. Let's try again.

Current code assumes that a bridge authority has IPv6 connectivity.
If it doesn't, it won't emit any "a" lines since it cannot reach any
IPv6 OR ports.

comment:5 Changed 7 years ago by ln5

Cc: karsten added

Karsten has promised to test this in a private network. Thanks!

Relevant parts of torrcs I'm using in my network:

# torrc-bridgeauth
Nickname ln5v6bridgeauth1
ORPort 1443 IPv4Only
DirPort 1444
PublishServerDescriptor 0
ExitPolicy reject *:*
SocksPort 0
AuthoritativeDirectory 1
BridgeAuthoritativeDir 1
DisableDebuggerAttachment 0
SafeLogging 0

# torrc-altb1
Nickname ln5v6altb1
ORPort 5700 IPv4Only
ORPort [<MYIPV6>>]:5700
AlternateBridgeAuthority ln5v6bridgeauth1 bridge orport=1443 <BRIDGEAUTH1-IPV4>:1444 40B00802571F4F79615CE6E6CB16BA787086F0F3
SOCKSPort 0
BridgeRelay 1
PublishServerDescriptor 1
ExitPolicy reject *:*
SafeLogging 0

# torrc-altc1
Nickname ln5v6c0klutt
UseBridges 1
AlternateBridgeAuthority ln5v6bridgeauth1 bridge orport=1443 <BRIDGEAUTH1-IPV4>>:1444 40B00802571F4F79615CE6E6CB16BA787086F0F3
Bridge [<LN5V6ALTB1-IPV6>]:5700 B17E448A661D0B46518B36BFF412F6412300CF19
UpdateBridgesFromAuthority 1
SafeLogging 0

comment:6 in reply to:  5 Changed 7 years ago by karsten

Replying to ln5:

Karsten has promised to test this in a private network. Thanks!

Looks like I spoke too soon. I'm having trouble testing your branch in a local VM. Tor is unhappy with things running on localhost only, and I'm afraid if I take out all those warnings, I'm testing a different Tor than the one you want to be tested. I should rather test your branch on a machine that has a public IPv6 address and make sure that neither of my test Tors publishes a descriptor to the official dir auths---which you made sure in your torrcs, AFAICS. Do you have a VM with IPv6 connectivity that I could use for these tests?

comment:7 Changed 7 years ago by ln5

Please send me an ssh key in a signed email.

Can you live without root access? It'd make things easier.

comment:8 in reply to:  7 Changed 7 years ago by karsten

Replying to ln5:

Please send me an ssh key in a signed email.

Sent.

Can you live without root access? It'd make things easier.

Sure, having no root access should be fine.

Thanks!

comment:9 Changed 7 years ago by karsten

I ran f9f67ef on one of ln5's IPv6-capable machines. I successfully set up a private bridge authority and a private bridge publishing its descriptor to the private bridge authority. The bridge authority assigned a Running flag to the bridge and added an "a" line containing the bridge's IPv6 address.

The only change I had to make to tor's code was to post the bridge's descriptor to the bridge authority directly, not via Tor, because the bridge didn't have the bridge authority's descriptor. This is understandable, because the private bridge authority didn't publish its descriptor to moria1 et al. When deploying the code on Tonga, this won't be an issue.

comment:10 in reply to:  9 ; Changed 7 years ago by ln5

Replying to karsten:

The only change I had to make to tor's code was to post the bridge's descriptor to the bridge authority directly, not via Tor, because the bridge didn't have the bridge authority's descriptor. This is understandable, because the private bridge authority didn't publish its descriptor to moria1 et al. When deploying the code on Tonga, this won't be an issue.

How did you do this? Might be useful for testing.

Another option would be to manually add the descriptor for the bridge authority to the bridge. What would be an easy way of doing that?

comment:11 Changed 7 years ago by Sebastian

you can use POSTDESCRIPTOR via the control port

comment:12 Changed 7 years ago by arma

Another option might be to just stick it in the cached-descriptor file before you start Tor.

comment:13 Changed 7 years ago by ln5

Status: assignedneeds_review

Created #5974 to take care the configuration option.

comment:14 Changed 7 years ago by ln5

Getting this merged and Tonga to run it at least a couple of days prior to 6/6 would be great!

comment:15 in reply to:  10 Changed 7 years ago by karsten

Replying to ln5:

Replying to karsten:

The only change I had to make to tor's code was to post the bridge's descriptor to the bridge authority directly, not via Tor, because the bridge didn't have the bridge authority's descriptor. This is understandable, because the private bridge authority didn't publish its descriptor to moria1 et al. When deploying the code on Tonga, this won't be an issue.

How did you do this? Might be useful for testing.

I don't remember the exact code line. It had to do with needing anonymity when fetching descriptors. Search for "anonymized_connection" in directory.c. You can probably look up the change I made by running git diff in ~/tor/ on the host you gave me for testing.

Another option would be to manually add the descriptor for the bridge authority to the bridge. What would be an easy way of doing that?

I tried writing the descriptor to the cached-descriptors file before starting Tor. For some reason that didn't work, so I changed the needs-anonymity thing and got it working. But in theory the cached-descriptors file trick should work, too.

comment:16 Changed 7 years ago by asn

Status: needs_reviewneeds_revision

I looked at the branch briefly. Two little things:

a) changes/bug5891 seems to have some git conflict strings inside.
b) Usually prefer fmt_addr() instead of tor_addr_to_str() when it's possible. In routerstatus_format_entry() I think you are overwriting buf in your call to tor_addr_to_str(). Check out how functions like connection_proxy_connect() are using fmt_addr() in snprintf.

comment:17 in reply to:  16 Changed 7 years ago by ln5

Status: needs_revisionneeds_review

Replying to asn:

a) changes/bug5891 seems to have some git conflict strings inside.

Ugh, repeatedly rebasing to master makes me crazy. My git fu is
clearly imperfect.

b) Usually prefer fmt_addr() instead of tor_addr_to_str() when it's possible. In routerstatus_format_entry() I think you are overwriting buf in your call to tor_addr_to_str(). Check out how functions like connection_proxy_connect() are using fmt_addr() in snprintf.

That's one hell of a sweet shadowing bug. Why doesn't GCC warn me
about that? (Why my brain doesn't refuse to come up with code like
that is another fine question.)

Fixed it in branch ipv6-phase3-0528.

Thanks for finding these!

comment:18 Changed 7 years ago by nickm

Oh dear. The branch seems to be pretty confused. Have a look:

[1038]$ git log  --format='%h %s' master..linus/ipv6-phase3-0528 |cat
6919f39 Don't shadow 'buf'.
2add0c3 Remove git conflict markup.
a2ccdc5 Add changes file for #5534.
3340b29 Add configure option AuthDirHasIPv6Connectivity.
4ef869e Merge branch 'ipv6-phase3' of ssh://torgit/linus/tor into ipv6-phase3
78f7456 Rename routers_have_same_or_addr() to reflect the fact that it now checks both OR ports.
48c69b8 Include IPv6 OR ports in status documents only if we're a bridge authority.
7e376d8 Don't put unreachable IPv6 OR port in routerstatus.
a54f487 Add "a" line to status document.
952290a Add last_reachable and testing_since for IPv6 OR port.
b6b8bd3 Don't assume that a node has routerinfo.
11ab682 Move last_reachable and testing_since from routerinfo_t to node_t.
f9f67ef Merge branch 'ipv6-phase3' of ssh://torgit/linus/tor into ipv6-phase3
a123409 Cherry-pick task-5891.
b67049c Rename routers_have_same_or_addr() to reflect the fact that it now checks both OR ports.
3256a32 Include IPv6 OR ports in status documents only if we're a bridge authority.
6d6d00f Don't put unreachable IPv6 OR port in routerstatus.
8b458b8 Add "a" line to status document.
6868706 Add last_reachable and testing_since for IPv6 OR port.
18126dc Don't assume that a node has routerinfo.
9bc7997 Move last_reachable and testing_since from routerinfo_t to node_t.
1404b32 Cherry-pick task-5891.
8021634 Merge branch 'ipv6-phase3' of ssh://torgit/linus/tor into ipv6-phase3
4e40e48 Rename routers_have_same_or_addr() to reflect the fact that it now checks both OR ports.
d8ffaad Include IPv6 OR ports in status documents only if we're a bridge authority.
9657a87 Don't put unreachable IPv6 OR port in routerstatus.
264d8a7 Add "a" line to status document.
b2b8cae Add last_reachable and testing_since for IPv6 OR port.
2ffa692 Don't assume that a node has routerinfo.
ba5e17e Move last_reachable and testing_since from routerinfo_t to node_t.
a7d0079 Rename routers_have_same_or_addr() to reflect the fact that it now checks both OR ports.
1f160db Include IPv6 OR ports in status documents only if we're a bridge authority.
03e2e19 Don't put unreachable IPv6 OR port in routerstatus.
4ac4f71 Add "a" line to status document.
563267c Add last_reachable and testing_since for IPv6 OR port.
85a9b0e Don't assume that a node has routerinfo.
972a6cb Move last_reachable and testing_since from routerinfo_t to node_t.

See how the same commits show up a few times with different IDs? That looks a lot like you rebased the same branch a few times, and merged all versions of the branch together.

I will try to come up with some kind of cherry-picked thing that has only one copy each of the commits that actually belong here in sequence, unless you can get to it first.

comment:19 in reply to:  18 Changed 7 years ago by ln5

Replying to nickm:

See how the same commits show up a few times with different IDs? That looks a lot like you rebased the same branch a few times, and merged all versions of the branch together.

Oh I'm really sorry. Please see ipv6-phase3-0701 for something possibly more usable.

comment:20 Changed 7 years ago by ln5

linus/ipv6-phase3-0711 is rebased to master as of today.

comment:21 Changed 7 years ago by nickm

Reviewing that branch...

I think that having two functions for the nodelist_*_routerinfo stuff may be needless. Have a look at the commit I added at the head of 56bb011d2db9e2feff5. How does that look? (It needs a better commit message)

Otherwise, this branch looks ok to me.

comment:22 Changed 7 years ago by nickm

err, 56bb011d2db9e2f is the commit I added. It is at the head of nickm/tor.git 's ipv6-phase3-0711 branch.

comment:23 Changed 7 years ago by ln5

<ln5> nickm: dirauths segfault on your branch in nodelist_map_HT_INSERT
      (head=0x8, elm=0x801481550) at nodelist.c:53 but only dirauths it seems.
      i can't really see why.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8014041c0 (LWP 100156)]
0x00000000004179f4 in nodelist_map_HT_INSERT (head=0x8, elm=0x801473550) at nodelist.c:53
53      HT_PROTOTYPE(nodelist_map, node_t, ht_ent, node_id_hash, node_id_eq);
(gdb) bt
#0  0x00000000004179f4 in nodelist_map_HT_INSERT (head=0x8, elm=0x801473550) at nodelist.c:53
#1  0x0000000000417992 in node_get_or_create (identity_digest=0x80145542c "çA·r¥ø¼S\235ðn>rxìüQ\232IÖ,Ò\006P") at nodelist.c:108
#2  0x0000000000417b98 in nodelist_set_routerinfo (ri=0x801455400, ri_old_out=0x0) at nodelist.c:140
#3  0x000000000045031d in routerlist_insert (rl=0x80148c480, ri=0x801455400) at routerlist.c:2883
#4  0x000000000045246a in router_add_to_routerlist (router=0x801455400, msg=0x7fffffffe058, from_cache=0, from_fetch=0) at routerlist.c:3475
#5  0x00000000004da677 in dirserv_add_descriptor (ri=0x801455400, msg=0x7fffffffe058, source=0x53c2ba "self") at dirserv.c:759
#6  0x0000000000443450 in init_keys () at router.c:662
#7  0x0000000000492600 in options_act (old_options=0x0) at config.c:1515
#8  0x0000000000490b6c in set_options (new_val=0x801412f00, msg=0x7fffffffe3a0) at config.c:755
#9  0x000000000049bd80 in options_init_from_string (cf_defaults=0x80141f106 "", 
    cf=0x801420200 "TestingTorNetwork 1\nDataDirectory /usr/u/src/tor/chutney/net/nodes/000a\nRunAsDaemon 1\nConnLimit 60\nNickname test000a\nShutdownWaitLength 0\nPidFile /usr/u/src/tor/chutney/net/nodes/000a/pid\nLog notice f"..., command=0, command_arg=0x0, msg=0x7fffffffe3a0) at config.c:4791
#10 0x000000000049b79c in options_init_from_torrc (argc=5, argv=0x7fffffffe5d8) at config.c:4648
#11 0x000000000040d797 in tor_init (argc=5, argv=0x7fffffffe5d8) at main.c:2333
#12 0x000000000040de7e in tor_main (argc=5, argv=0x7fffffffe5d8) at main.c:2646
#13 0x00000000004087ab in main (argc=5, argv=0x7fffffffe5d8) at tor_main.c:30
(gdb) 

comment:24 Changed 7 years ago by nickm

I'd guess the_nodelist is NULL, especially since this is happening early in the initialization process. Pushed another commit. Better now?

comment:25 Changed 7 years ago by ln5

Better -- no crashes.

Also, this branch seems to work well in a test network including
dirauths, a bridge auth, relays (ordinary and bridge) and clients
(ordinary and using bridges).

comment:26 Changed 7 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

This, plus the contents of enh6404, squashed, became my branch "tickets_5529_5534_5974_6406".

Just merged that branch.

comment:27 Changed 7 years ago by nickm

Keywords: tor-auth added

comment:28 Changed 7 years ago by nickm

Component: Tor Directory AuthorityTor
Note: See TracTickets for help on using tickets.