Opened 7 years ago

Closed 7 years ago

Last modified 8 months ago

#6815 closed defect (fixed)

Warn: Your server (1.2.3.4:80) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

Reported by: torland Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version: Tor: 0.2.4.2-alpha
Severity: Keywords: tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

After upgrading to Tor 0.2.4.2-alpha Tor warns that the DirPort is not reachable. But testing the ip from outside brings up the configured tor-exit-notice.html. So the DirPort can be reached from outside.

Child Tickets

Attachments (2)

git-bisect.log (22.3 KB) - added by nickm 7 years ago.
git-bisect_revert_vchecks.log (4.7 KB) - added by kargig 7 years ago.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 7 years ago by torland

Component: - Select a componentTor Relay

comment:2 Changed 7 years ago by rransom

This ticket is probably another symptom of the underlying bug that caused #6815.

comment:3 Changed 7 years ago by nickm

Linus, can you think of anything that would cause this that we merged in 0.2.4.2-alpha?

torland, did this happen with 0.2.4.1-alpha too? Which version did you upgrade from?

rransom, this one is #6815. Which ticket did you mean?

comment:4 Changed 7 years ago by torland

I upgraded from 0.2.3.20-rc, so I don't know if it happened with 0.2.4.1-alpha.

comment:5 Changed 7 years ago by kargig

same problem here with 0.2.4.2 commit: 19b2126119cc3eb39bcfd6055557440d84510f51
everything was ok with 0.2.4.1

node has IPv6 functionality enabled and has "AuthDirHasIPv6Connectivity 1" even though it's not a AuthDir.

Other parts of the config:
OrPort 80
OrPort [XXXX:XXXX:XXXX....:XXXX]:80
DirPort 443

comment:6 Changed 7 years ago by nickm

I have a report (currently sent to me via email, and I haven't gotten permission to quote it verbatim yet) attributing this problem to 7988596f66874fd36d1c99bf39736e4b41609a6b (based on git bisect).

Does reverting commit 7988596f66874fd36d1c make it work for anybody? And can anyone figure out why 7988596f66874fd36d1c might be causing this, if it is?

comment:7 Changed 7 years ago by nickm

And apparently reverting 7988596f66874fd36d1c is reported to solve the problem. Can anyone see why?

comment:8 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-final

Changed 7 years ago by nickm

Attachment: git-bisect.log added

comment:9 Changed 7 years ago by nickm

Okay, now I have permission from karkig to say that it was karkig doing the above testing. Great!

With permission, I'm attaching the git bisect log.

wrt the revert, karkig said:

yeap after git revert 7988596f66874fd36d1c99bf39736e4b41609a6b
I get the following inside the log file:
Sep 12 02:27:09.000 [notice] Bootstrapped 100%: Done.
Sep 12 02:27:12.000 [notice] Self-testing indicates your DirPort is
reachable from the outside. Excellent.
Sep 12 02:27:17.000 [notice] Performing bandwidth self-test...done.

so I think that git bisect had correctly identified the problem.

comment:10 Changed 7 years ago by nickm

I still can't see what's wrong with the commit in question though.

comment:11 Changed 7 years ago by nickm

Okay; next step here is to have a look at the branch "revert_vchecks" in my public repository at https://git.torproject.org/nickm/tor.git . It reverts the offending commit, then re-applies it in a separate piece for each bit that I removed. If you do a git bisect on that -- assuming that the first commit in it is good and the last is bad, that might tell us where the problem is exactly.

comment:12 Changed 7 years ago by nickm

(The outcome of my re-creating the original branch is not *exactly* the same as the first one, so it's possible that there are no bugs in revert_vchecks. I'd be surprised, but it's worth testing)

Changed 7 years ago by kargig

comment:13 Changed 7 years ago by kargig

from bisecting on your revert_vchecks branch

git bisect good 75c9ccd4f851bac6d32cb08ded557ac207bc8002
git bisect bad ece39e28ce544d211444f951fb6bce0903a28357

2f0734f874b203ee06ab8b9a2e3ab3c4cf3bb529 is the first bad commit
commit 2f0734f874b203ee06ab8b9a2e3ab3c4cf3bb529
Author: Nick Mathewson <nickm@…>
Date: Tue Sep 11 19:57:10 2012 -0400

Remove version_supports_begindir

:040000 040000 380e3d4181b24a943cf559fc1bd45f2afb138b8d 5f644ad91c3f7bc05b405f1d00359a69c77df3d2 M src

I've attached another log as well.

comment:14 in reply to:  3 Changed 7 years ago by rransom

Replying to nickm:

rransom, this one is #6815. Which ticket did you mean?

I meant #6814.

comment:15 Changed 7 years ago by arma

I experience this bug on moria1 (dir authority) too.

comment:16 Changed 7 years ago by arma

Looks like in our zeal to get rid of supports_begindir, we switched to use_begindir==1 for our dirport reachability tests.

comment:17 Changed 7 years ago by arma

@@ -955,7 +955,7 @@ consider_testing_reachability(int test_or, int test_dir)
     directory_initiate_command(me->address, &addr,
                                me->or_port, me->dir_port,
                                0, /* does not matter */
-                               0, me->cache_info.identity_digest,
+                               me->cache_info.identity_digest,
                                DIR_PURPOSE_FETCH_SERVERDESC,
                                ROUTER_PURPOSE_GENERAL,
                                1, "authority.z", NULL, 0, 0);

We had been using supports_begindir==0 to indicate that you'd better not choose to tunnel this dir conn, even if directory_command_should_use_begindir() would otherwise choose to.

Looks like we should find a new way to pass that "not in this case" goal through.

comment:18 Changed 7 years ago by rransom

And #6814 could be caused by the DirPort reachability test being launched before the ORPort reachability test succeeds, thus before the relay has created a descriptor for itself.

comment:19 Changed 7 years ago by nickm

Status: newneeds_review

Thanks, everyone! I have a likely fix in branch "bug6815" in my public repository. Please test and review! (Especially look for logic errors where I made non-anonymous some connection type that needs to be anonymous, or vice versa)

comment:20 in reply to:  19 Changed 7 years ago by rransom

Replying to nickm:

Thanks, everyone! I have a likely fix in branch "bug6815" in my public repository. Please test and review! (Especially look for logic errors where I made non-anonymous some connection type that needs to be anonymous, or vice versa)

Looks good. (I haven't tested it.)

comment:21 Changed 7 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

It still looks good to me too. Merging to master.

comment:22 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:23 Changed 7 years ago by nickm

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