Opened 5 years ago
Closed 5 years ago
#11226 closed defect (invalid)
Client connections to freenode's hidden services are getting refused
| Reported by: | wfn | Owned by: | |
|---|---|---|---|
| Priority: | High | Milestone: | Tor: 0.2.5.x-final |
| Component: | Core Tor/Tor | Version: | |
| Severity: | Keywords: | tor-hs 024-backport | |
| Cc: | nickm, rfree, wfn | Actual Points: | |
| Parent ID: | Points: | ||
| Reviewer: | Sponsor: |
Description
As of now, most of the hidden services run by freenode (http://freenode.net/irc_servers.shtml#tor) are unreachable (5jebommkgbfl6agc.onion (port 6667) seems to be reachable.) This was spotted and inquired by rfree.
The question is "what is causing this / where is the bottleneck?" Is this a case of #8902, or something else?
Some logs from vanilla tor clients attempting to reach a freenode HS:
- https://privatepaste.com/download/d05ef8f575 (tor 0.2.4.21-1~d70) (tomaw's log)
- http://ravinesmp.com/volatile/vanilla-debug.log (tor 0.2.5.2-alpha, git-cd9d08a5e14d2339) (wfn's log) (attempted client connection to p4fsi4ockecnea7l.onion)
Seems that INTRODUCE{1,2} succeeds (from debug log; from controller events) (nickm, et al.), rendezvous is successful, "client sends RELAY_BEGIN, HS replies with RELAY_END [...] with reason set to END_STREAM_REASON_CONNECTREFUSED" (nickm).
Why does the HS close the stream? Either it gets an actual ECONNREFUSED (why?), or this errno is incorrect / read when it's not supposed to be read / mixed up (why); or something else entirely.
Child Tickets
Attachments (1)
Change History (9)
comment:1 Changed 5 years ago by
| Keywords: | tor-hs 024-backport added |
|---|---|
| Milestone: | → Tor: 0.2.5.x-final |
| Priority: | normal → major |
comment:6 Changed 5 years ago by
skruffy debugged this problem more. I attached a file he pastebined, that shows two descriptors; one that belongs to the non-working HS, and one that belongs to the working HS.
He claims that the non-working HS is running tor < 0.2.4.16 since the publication time is not rounded up to the nearest hour. OTOH, the working HS is running a newer version of tor, since its publication time is rounded.
skruffy also believes that the bad HS publishes descriptors only for the old freenode HS addresses: p4fsi4ockecnea7l.onion lgttsalmpw3qo4no.onion 5jebommkgbfl6agc.onion and lbkwyb2csfcgoxwa.onion. The new address vgh6tbfjk65zj5ep.onion is only hosted by the good HS, so people who use that should not have problems.
This is weird; especially since tomaw is sure that the HS is not running from any other boxes...
comment:7 Changed 5 years ago by
skruffy notes that rounded down timestamp appears on 0.2.4.18 not on 0.2.4.16:
https://gitweb.torproject.org/tor.git/commitdiff/fd2954d06d2e9b8b0d33bcd0a2e3dfb947ff662e
comment:8 Changed 5 years ago by
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
skruffy was right, there was a second HS running.
tomaw found it and shut it down.
all is good.
THE END
Don't waste your time. k thx.