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:

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)

f033a9dd7f (5.7 KB) - added by asn 5 years ago.
two descriptors

Download all attachments as: .zip

Change History (9)

comment:1 Changed 5 years ago by nickm

Keywords: tor-hs 024-backport added
Milestone: Tor: 0.2.5.x-final
Priority: normalmajor

comment:2 Changed 5 years ago by cypherpunks

Don't waste your time. k thx.

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:3 Changed 5 years ago by cypherpunks

Don't waste your time. k thx.

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:4 Changed 5 years ago by cypherpunks

Don't waste your time. k thx.

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:5 Changed 5 years ago by cypherpunks

Don't waste your time. k thx.

Last edited 5 years ago by cypherpunks (previous) (diff)

Changed 5 years ago by asn

Attachment: f033a9dd7f added

two descriptors

comment:6 Changed 5 years ago by asn

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 asn

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 asn

Resolution: invalid
Status: newclosed

skruffy was right, there was a second HS running.
tomaw found it and shut it down.
all is good.

THE END

Note: See TracTickets for help on using tickets.