Opened 8 years ago

Last modified 3 months ago

#1776 reopened defect

Allow regular relays (if they have a dirport open) to be used as bridges

Reported by: Sebastian Owned by: asn
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: regression, crash, tor-bridge
Cc: korobkov@…, teor, isis Actual Points:
Parent ID: #11301 Points:
Reviewer: Sponsor:

Description

When we fetch a bridge descriptor and already have a descriptor with the same identity digest cached, we refuse to add the new one. This means that when we have an old descriptor with purpose general, we won't change the purpose to bridge when we configured that relay as bridge in the Tor client.

Child Tickets

Attachments (2)

158097 (2.6 KB) - added by asn 6 years ago.
wanoskarnet's patch
158081 (658 bytes) - added by asn 6 years ago.
non-extended version of wanoskarnet's patch

Download all attachments as: .zip

Change History (101)

comment:1 Changed 8 years ago by Sebastian

Status: newneeds_review

See branch bug1776 in my repo as a proposed fix

comment:2 Changed 8 years ago by arma

  • if (sdmap_get(routerlist->desc_digest_map,
  • router->cache_info.signed_descriptor_digest)) {

+ if (sdmap_get(routerlist->desc_digest_map, id_digest)) {

This part is bad news. Descriptor digests and identity digests are different things, and we shouldn't mix them. We shouldn't try looking up the id_digest in the desc_digest_map -- it'll never be there.

comment:3 Changed 8 years ago by Sebastian

Good point. bug1776_v2

comment:4 Changed 8 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

merged; thanks

comment:5 Changed 8 years ago by arma

Resolution: fixed
Status: closedreopened

comment:6 Changed 8 years ago by arma

Bug not fixed.

Check out git master (e.g. 8d588e7b1a4fccf), run Tor to fetch all your directory stuff, kill Tor, then run Tor pointing to a public relay as your bridge. It will fetch that relay's descriptor using router purpose bridge, and successfully store it (so the above patch worked to that extent).

But then it will discover that it doesn't have any general-purpose descriptor for that relay, and it's listed in the consensus so clearly it should have one. So it fetches one, and then replaces the bridge-purpose descriptor with the general-purpose descriptor, and then Tor freaks out because none of its bridges are up anymore.

comment:7 Changed 8 years ago by arma

Owner: set to arma
Status: reopenedaccepted

Options:

A) Teach the Tor directory stuff that if a descriptor it wants is a
configured bridge, it doesn't want the general-purpose descriptor.

B) If you get a general-purpose descriptor for a relay which is currently
one of your bridges, for god's sake don't accept it.

C) ?

We clearly need to do A. It's not clear that doing B as
belt-and-suspenders helps -- if we do A correctly, then we don't
need B, and if we do B but don't do A correctly, we end up doing the
fetch-and-discard-repeat dance.

comment:8 Changed 8 years ago by nickm

Milestone: Tor: 0.2.2.x-final

comment:9 Changed 8 years ago by arma

Ok. Removing the changelog entry for 0.2.2.15-alpha, since it's not fixed and we're not going to get a fix in by release.

comment:10 Changed 8 years ago by nickm

Well, we did change something. Shouldn't there be a changelog entry for what the patch did do?

comment:11 Changed 8 years ago by Sebastian

So back when I wrote the patch, I tested it and it appeared to work.

I'm testing with "src/or/tor --UseBridges 1 --Bridge 78.47.18.110:80", and could just use Tor for a few minutes without any problem. While I did that, "Dropping descriptor that we already have for router 'fluxe3'" was logged exactly once. I'm not quite sure what's up here.

comment:12 Changed 8 years ago by Sebastian

It certainly seems we're not overzealously fetching the descriptor again. After running for more than one hour, my Tor only logged "Dropping descriptor that we already have for router 'fluxe3'" three times, roughly 15 minutes apart.

I have no problem using fluxe3 as a bridge.

comment:13 Changed 8 years ago by Sebastian

Ahhh, now I can reproduce the problem. It happens when I have a descriptor for fluxe3 without the bridge annotation when I first start up. It isn't dependant on how much other network information is present, the important thing is that there is a general-purpose descriptor in my cached-descriptors file. So I believe that this is *not* related to fetching a new descriptor from the network, but rather Tor goes back to the descriptor it has on disk.

comment:14 Changed 8 years ago by Sebastian

Status: acceptedneeds_review

So my original patch was being extremely silly when it did this:

if (old_router && (!routerinfo_is_a_configured_bridge(router)

routerinfo_is_a_configured_bridge(old_router))) {

because routerinfo_is_a_configured_bridge() will either be true for both or neither one of them.

bug1776_v3 should fix that, I think.

comment:15 Changed 8 years ago by yetonetime

crap.

comment:16 Changed 8 years ago by Sebastian

Have a more helpful comment maybe?

comment:17 Changed 8 years ago by yetonetime

All is known, and patch still go to merge. No need more words then it.

comment:18 Changed 8 years ago by Sebastian

I talked to arma about whether the assert is appropriate. He said to leave it in for now until he can review, but see bug1776_v4 for an alternative that doesn't assert, but just warns and continues.

comment:19 Changed 8 years ago by yetonetime

Just warns and continues is not enough, descriptor must be dropped for good reason.

comment:20 Changed 8 years ago by arma

Triage: we should get this in for 0.2.2.x (but maybe it's ok to not block the rc)

comment:21 Changed 8 years ago by arma

yetonetime: can you clarify your comment? I don't know what it means.

comment:22 Changed 8 years ago by arma

Sebastian: for context, I originally put in the if (old_router) check just as a defensive programming measure, so we don't look at *old_router if it's NULL.

The first case that comes to mind where old_router could be NULL is if Tor has a bug somewhere such that routerlist->desc_digest_map and routerlist->identity_map get out of sync. We don't know of bugs now, but that's no promise they won't be introduced later.

I guess the second case that you're pointing out is if somebody can create a sha1 collision on structured data (relay descriptors here), such that they give you a descriptor A for relay identity B, and then when you're fetching a bridge descriptor for bridge identity C they give you a new descriptor D signed by C whose hash matches the hash of A. That would cause you to trigger the assert and exit.

I have to say, I'm not much worried about that DoS vulnerability. Somebody should audit the Tor code in their spare time for other such cases, to get a sense of how many there are, but I bet there are lots.

Nick, can you give some insight here? How pedantic should we be? bug1776_v3 seems like it resolves the issues, and it has an assert that shouldn't be triggered except if we have a bug or a bad assumption about sha1. Good enough?

comment:23 Changed 8 years ago by arma

Saying Nick's name again since he keeps bugging me to review patches

comment:24 Changed 8 years ago by nickm

Switching an assert to a log-and-carry-on is pretty trivial. I wouldn't be to worried about that, if the assert is as hard-to-trigger as you say. Is there something else you wanted insight on here?

I do not know what yetonetime is talking about; I can't figure out what he is saying. I am _trying_ to translate it as 'It's not enough to warn and continue; we must drop the descriptor for a good reason [in the hash collision case]".

I am fine with either v3 or v4. If I were pushing for a v5, I'd also say "drop the descriptor in a collision case too," since it's not nice to have hash collisions flying around. Still, v3 is okay with me; I like v4 least. I'd push harder for my "v5", except for the fact that if if somebody can use hash collisions to attack Tor users, this isn't the right vector to do it with.

comment:25 Changed 8 years ago by arma

So the summary is that both nickm and arma say "v3 looks like the best option so far"?

I say we put it in then.

comment:26 Changed 8 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Merged v3 then; closing.

comment:27 Changed 8 years ago by arma

Resolution: fixed
Status: closedreopened

comment:28 Changed 8 years ago by arma

We're baaack!

bug1776_v3 introduced an assert that could trigger on directory authorities.

The issue is that router_get_by_digest(id_digest) and sdmap_get(routerlist->desc_digest_map, router->cache_info.signed_descriptor_digest) are deliberately not kept in sync if you're a directory cache. That's because the desc_digest_map includes descriptors that are in old_routers, that is, the descriptors that are cached but not in the currently recommended routerlist.

The assert should only be triggerable on directory authorities, since other Tors avoid downloading something they already have: e.g. router_get_by_descriptor_digest() in update_consensus_router_descriptor_downloads() looks at routerlist->desc_digest_map, which is what we want.

The logic is going to be messy here, because it's not just a matter of "drop or don't drop if !old_router" -- we want to drop the new descriptor if desc_digest_map already has it and the copy we have (whether in routerlist or old_routers) is not worth replacing.

Probably we'll be happier working out the logic, using intermediate variables, rather than trying to cram it into one awful if. For example, a truth table based on all the variables would help us sort out what we actually want to *do* in each case.

comment:29 Changed 8 years ago by Sebastian

We had a user (not authority operator!) report this assert:

Oct 09 11:31:40.393 [Error] router_add_to_routerlist(): Bug: routerlist.c:3215: router_add_to_routerlist: Assertion old_router failed; aborting.

Nothing more yet, since he didn't reply to questions; so no idea what kind of configuration he was running. He only said Tor crashed with this, twice.

comment:30 Changed 8 years ago by nickm

So first off, this isn't authorities only: caches also have a nonempty routerlist->old_routers.

Second, assuming the behavior we want is:

"Drop duplicate descriptors, unless adding this one would turn a nonbridge into a bridge" then the inputs we need are:

  • 'Is this a duplicate?' (Yes if we got anything from the sdmap_get(desc_digest_map) call.
  • 'Is it a bridge?' (Yes if router->purpose says it is.)
  • 'Was the old one a bridge?' (Yes if old_router != NULL and old_router->purpose says it is. But what if old_router == NULL? We'd want to look at the result of the sdmap_get() call. Can a bridge descriptor even make it into old_routers? Should it? If "yes" and "yes", is there anything about the signed_descriptor_t that tells us whether it's a bridge?)

comment:31 Changed 8 years ago by cypherpunks

Caches have a nonempty routerlist->old_routers but the assert can be detonated on a directory authorities only (by default). Another story is client with configured UseBridges and Bridge options.

comment:32 Changed 7 years ago by nickm

Status: reopenedneeds_review

See branch "1776_redux_v1" in my public repo.

comment:33 Changed 7 years ago by nickm

piebeer was concerned that some of the calls from router_add_to_routerlist to the routerlist manipulation functions could fail if we do an operation on the routerlist when we already have a routerinfo or a signed_descriptor_t with the same identity_digest. I should fix that before we merge.

comment:34 Changed 7 years ago by nickm

err, I should have said, "if we already have a routerinfo or a signed_descriptor with the same *descriptor digest*."

comment:35 Changed 7 years ago by nickm

There, have a look at the branch now. This code needs careful review.

comment:36 Changed 7 years ago by arma

accc51b68c looks plausible.

What 114a371c0ea4 does doesn't match its comment though.

     /* If we have this descriptor already and the new descriptor is a bridge
      * descriptor, replace it. If we had a bridge descriptor before and the
      * new one is not a bridge descriptor, don't replace it. */

But if

routerinfo_is_a_configured_bridge(router) && !was_bridge

then we'll keep it, even if the new descriptor isn't a purpose_bridge.

We need to think more about what we're actually trying to do here (ugh).

comment:37 Changed 7 years ago by nickm

Well, this is a crash bug atm, so we should think about what we're trying to do here before the next 0.2.2.x release. I believe that the new code fixes that crash bug, even if the logic could be improved. I do not know what the right logic is. Maybe build a truth table and figure out what it should be? I tried that, and came up with this, so I am not the one to to it.

comment:38 Changed 7 years ago by cypherpunks

lol

comment:39 Changed 7 years ago by nickm

Thanks for "helping", cypherpunks.

comment:40 Changed 7 years ago by nickm

Priority: normalmajor

comment:41 Changed 7 years ago by nickm

Updated with a fix suggested by sebastian.

comment:42 Changed 7 years ago by arma

I merged it. It will be in 0.2.2.18-alpha.

comment:43 Changed 7 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Closing as fixed then.

comment:44 Changed 7 years ago by cypherpunks

--- routerlist.c Mon Nov 22 06:06:38 2010
+++ routerlist.c.punks Mon Nov 22 08:56:36 2010
@@ -56,7 +56,8 @@

int with_annotations);

static void list_pending_downloads(digestmap_t *result,

int purpose, const char *prefix);

-
+static void routerlist_remove_old(routerlist_t *rl, signed_descriptor_t *sd,
+ int idx);

DECLARE_TYPED_DIGESTMAP_FNS(sdmap_, digest_sd_map_t, signed_descriptor_t)
DECLARE_TYPED_DIGESTMAP_FNS(rimap_, digest_ri_map_t, routerinfo_t)
DECLARE_TYPED_DIGESTMAP_FNS(eimap_, digest_ei_map_t, extrainfo_t)

@@ -2797,9 +2798,7 @@

ri->cache_info.signed_descriptor_digest,
&(ri->cache_info));

if (sd_old) {

  • rl->desc_store.bytes_dropped += sd_old->signed_descriptor_len;
  • sdmap_remove(rl->desc_by_eid_map, sd_old->extra_info_digest);
  • signed_descriptor_free(sd_old);

+ routerlist_remove_old(rl, sd_old, -1);

}


if (!tor_digest_is_zero(ri->cache_info.extra_info_digest))

comment:45 Changed 7 years ago by cypherpunks

routerlist_assert_ok() is problems :)
--- routerlist.c Mon Nov 22 06:06:38 2010
+++ routerlist.c.punks Wed Nov 24 16:24:48 2010
@@ -56,7 +56,8 @@

int with_annotations);

static void list_pending_downloads(digestmap_t *result,

int purpose, const char *prefix);

-
+static void routerlist_remove_old(routerlist_t *rl, signed_descriptor_t *sd,
+ int idx);

DECLARE_TYPED_DIGESTMAP_FNS(sdmap_, digest_sd_map_t, signed_descriptor_t)
DECLARE_TYPED_DIGESTMAP_FNS(rimap_, digest_ri_map_t, routerinfo_t)
DECLARE_TYPED_DIGESTMAP_FNS(eimap_, digest_ei_map_t, extrainfo_t)

@@ -2796,11 +2797,6 @@

sd_old = sdmap_set(rl->desc_digest_map,

ri->cache_info.signed_descriptor_digest,
&(ri->cache_info));

  • if (sd_old) {
  • rl->desc_store.bytes_dropped += sd_old->signed_descriptor_len;
  • sdmap_remove(rl->desc_by_eid_map, sd_old->extra_info_digest);
  • signed_descriptor_free(sd_old);
  • }


if (!tor_digest_is_zero(ri->cache_info.extra_info_digest))

sdmap_set(rl->desc_by_eid_map, ri->cache_info.extra_info_digest,

@@ -2808,6 +2804,9 @@

smartlist_add(rl->routers, ri);
ri->cache_info.routerlist_index = smartlist_len(rl->routers) - 1;
nodelist_add_routerinfo(ri);

+ if (sd_old) {
+ routerlist_remove_old(rl, sd_old, -1);
+ }

router_dir_info_changed();

#ifdef DEBUG_ROUTERLIST

routerlist_assert_ok(rl);

comment:46 Changed 7 years ago by cypherpunks

Useless. Thats non repairable. Ignore it if anyone reading.

comment:47 Changed 7 years ago by cypherpunks

history note: signed_descs_update_status_from_consensus_networkstatus() was very happy with non actual signed_descriptor_t *d. software was good enough long time ago.

comment:48 Changed 7 years ago by nickm

Priority: majornormal
Resolution: fixed
Status: closedreopened

Reopening till we figure out what's up here.

comment:49 Changed 7 years ago by arma

I don't know what cypherpunks might mean here. Perhaps we should interpret his "ignore it if anyone reading" as permission to close again?

comment:50 in reply to:  49 Changed 7 years ago by cypherpunks

Replying to arma:

I don't know what cypherpunks might mean here. Perhaps we should interpret his "ignore it if anyone reading" as permission to close again?

That mean it's urepairable with exist funcs. So if you wish random crashes then go to close it. Else you need to rework that stuff.

comment:51 Changed 7 years ago by rransom

2011-01-18 12:54 <piebeer> routerlist_insert() is problem. if (sd_old) means only one it was a member of rl->old_routers. And it doesn't mean that "sdmap_remove(rl->desc_by_eid_map, sd_old->extra_info_digest)"+"signed_descriptor_free(sd_old)" is enough.

comment:52 Changed 7 years ago by arma

Component: Tor ClientTor Bridge

comment:53 Changed 7 years ago by nickm

Priority: normalmajor

comment:54 Changed 7 years ago by arma

Owner: arma deleted
Status: reopenedassigned

comment:55 Changed 7 years ago by Sebastian

Status: assignedneeds_information

comment:56 Changed 6 years ago by nickm

Milestone: Tor: 0.2.2.x-finalTor: 0.2.3.x-final

comment:57 Changed 6 years ago by nickm

Keywords: regression added

comment:58 Changed 6 years ago by nickm

Keywords: crash added

Changed 6 years ago by asn

Attachment: 158097 added

wanoskarnet's patch

comment:59 Changed 6 years ago by asn

Owner: set to asn
Status: needs_informationaccepted

Attached some wanoskarnet warez:

< wanoskarnet> http://paste.debian.net/plain/158081 must have for success of revolution.
< wanoskarnet> http://paste.debian.net/plain/158097 extended version.
< wanoskarnet> directory_caches_dir_info() must return 0 if UseBridges defined, as fool proof.

(I only attached the "extended version".)

comment:60 Changed 6 years ago by asn

Status: acceptedneeds_review

Changed 6 years ago by asn

Attachment: 158081 added

non-extended version of wanoskarnet's patch

comment:61 Changed 6 years ago by korobkov

Cc: korobkov@… added

comment:62 Changed 6 years ago by nickm

Hm. This could probably go on 0.2.2.x -- at least, the non-extended version could. Whether or not if you can't trigger the bug there, the extended check is probably wise. I think I also want to add a few more checks to make sure that the referential integrity checks work out how we want. See branch "bug1776_one_more_time" in my public repository for merge into 0.2.2 and later.

The original reporter has said that the extended fixes are wrong, since they could prevent downloading the correct descriptors entirely. I also have worries about their anonymity properties: it seems to leak a little information, via what you aren't fetching, about what you have as your bridges.

comment:63 Changed 6 years ago by nickm

Merged the non-extended version into 0.2.2. Put the remaining parts of the other one into a branch called "no_dl_bridges", for posterity.

I don't think the no_dl_bridges fix is the right way to solve its problem: it would seem to leak the fact that we have a node configured as a bridge by the fact that we don't fetch its descriptor at all when you might expect us to do so.

Not crediting, since he has asked to not be credited: I'll be glad to add credits if I misunderstand or if he changes his mind.

comment:64 Changed 6 years ago by nickm

Status: needs_reviewneeds_revision

comment:65 Changed 6 years ago by arma

Fyi, SponsorF today wanted to do something that involved having this bug fixed. Specifically, Micah Sherr et al are working on alternate path selection algorithms (http://freehaven.net/anonbib/#DBLP:conf:pet:SherrBL09), and SponsorF wants to combine that in a demo with a pluggable transport. I believe configuring a pluggable transport is way more fun when you configure it as a bridge.

comment:66 Changed 6 years ago by nickm

Keywords: tor-bridge added

comment:67 Changed 6 years ago by nickm

Component: Tor BridgeTor

comment:68 Changed 5 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.5.x-final

comment:69 Changed 5 years ago by lunar

Answering arma's call for testing: I am able to use a “normal” relay as a bridge, both with and without microdescriptors enabled.

comment:70 Changed 5 years ago by nickm

For how long?

comment:71 Changed 5 years ago by lunar

Enough time to let Tor reach 100% bootstrap, but not much more. I can do longer tests if needed.

comment:72 Changed 5 years ago by arma

The crash, in the past, happened when you'd been running for a while. It happens when you fetch a descriptor of one purpose, store it, then get a replacement that's the same descriptor but with a different purpose.

comment:73 Changed 5 years ago by arma

Summary: Allow regular relays to be used as bridgesAllow regular relays (if they have a dirport open) to be used as bridges

comment:74 Changed 5 years ago by lunar

I have been using a relay as a bridge on 0.2.4.16-rc for 2 weeks. No crash to report.

comment:75 Changed 4 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

Moving nearly all needs_revision tickets into 0.2.6, as now untimely for 0.2.5.

comment:76 Changed 4 years ago by nickm

Keywords: 026-triaged-1 added
Status: needs_revisionneeds_information

Does this still happen with 0.2.5 and later?

comment:77 Changed 4 years ago by teor

Using a relay as a bridge has just worked for me on 2.6.0-alpha on and off for at least a month. Relay is stable (1 week+), client is stable (days).

Works with TBB as if the relay is a bridge.

AFAIR, never had an unexplained crash or any other unexpected behaviour.

comment:78 Changed 4 years ago by Sebastian

Can you check your log? Istr that there were a bunch of lines about believing the bridge to be down last time I tried.

comment:79 Changed 4 years ago by arma

I think it works smoothly if you're using microdescriptors (which is the default). In that case there's no conflict between the bridge descriptor and the relay microdescriptor, so no asserts trigger.

But if you set UseMicrodescriptors 0 and then set a public relay as your bridge, I think you will still trigger an assert.

And that isn't such a big deal these days, because a fine interim answer is "then don't do that".

comment:80 Changed 4 years ago by teor

Sebastian: no errors in the tor client logs like that, and as far as I can see, nothing about bridges being inaccessible at all. I'm using git tor with the TBB 3.6.6.

comment:81 Changed 4 years ago by teor

arma: Running with UseMicrodescriptors 0 now. Everything seems OK so far.

Last edited 4 years ago by teor (previous) (diff)

comment:82 Changed 4 years ago by teor

The assert that arma mentions may have been fixed by the changes in #13163 to ensure we check the BRIDGE_DIRINFO flag bitwise rather than using equality (this broke matching in some cases where microdescriptor flags were set/unset):

git 2d499f63addfcf86c0ef644cfe4cc37c01e0e118 Bitwise check BRIDGE_DIRINFO

But I haven't actually seen it happen with the old code, so I can't be sure it was that particular fix that did it.

comment:83 Changed 4 years ago by teor

Cc: teor added

comment:84 Changed 3 years ago by nickm

Resolution: fixed
Status: needs_informationclosed

Tentatively calling closed. Let's reopen if it turns out not to be fixed.

comment:85 Changed 3 years ago by isis

Cc: isis added

I have suspected that #11301 is due to normal relays getting used as "bridges", and they appear to jump from the bridge_list in entryguards.c to the normal routerlist, possibly when entry_guards_compute_status() is called, when it's discovered that the chosen "bridges" don't have ROUTER_PURPOSE_BRIDGE. After that, there is a weird catch-22 state where no DirectoryGuards exist
to fetch the other "bridge" descriptors, or something else that I'm not sure about yet.

Arma also pointed out that #14216 could also be related to this behaviour of sorting tables of routers, with different tables for each purpose, and not allowing one router to exist in multiple tables simultaneously. Either way, there are definitely still some bugs when using normal relays as bridges.

comment:86 Changed 3 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final
Resolution: fixed
Status: closedreopened

comment:87 Changed 3 years ago by nickm

Keywords: 027-triaged-1-out added

Marking triaged-out items from first round of 0.2.7 triage.

comment:88 Changed 3 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.???

Make all non-needs_review, non-needs_revision, 027-triaged-1-out items belong to 0.2.???

comment:89 in reply to:  85 Changed 3 years ago by isis

Replying to isis:

I have suspected that #11301 is due to normal relays getting used as "bridges" […]


Possibly related to: #11301

comment:90 Changed 18 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:91 Changed 17 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:92 Changed 11 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:93 Changed 11 months ago by nickm

Keywords: 027-triaged-in added

comment:94 Changed 11 months ago by nickm

Keywords: 027-triaged-in removed

comment:95 Changed 11 months ago by nickm

Keywords: 027-triaged-1-out removed

comment:96 Changed 11 months ago by nickm

Keywords: 026-triaged-1 removed

comment:97 Changed 11 months ago by nickm

Resolution: worksforme
Severity: Normal
Status: reopenedclosed

I believe this is actually doing pretty well now, but please reopen if not.

comment:98 Changed 3 months ago by arma

#11301 is now entitled "Tor does not reconnect after network loss with guards used as bridges", which I think is a hint that this bug is not actually squashed. :(

comment:99 Changed 3 months ago by teor

Parent ID: #11301
Resolution: worksforme
Status: closedreopened
Note: See TracTickets for help on using tickets.