Opened 5 years ago

Last modified 8 weeks ago

#8001 assigned defect

obfsproxy makes tor warn when one bridge is down

Reported by: arma Owned by: isis
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client, tor-bridge, tor-pt, logging easy
Cc: dcf, asn, isis Actual Points:
Parent ID: Points: 1
Reviewer: Sponsor: SponsorS-can

Description

When you run the fancy new flashproxy/obfsproxy bundle:
https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles
you get

Jan 19 15:09:17.120 [Warning] Proxy Client: unable to connect to 208.79.90.242:55564 ("server rejected connection")

That's because that bridge is down currently.

When a bridge fails, we should probably only [warn] if no bridges have succeeded.

Child Tickets

Change History (16)

comment:1 Changed 5 years ago by dcf

The way it works now, warning immediately for every failed bridge, is what I expect to happen. Is the problem that it makes the Message button blink in Vidalia? Do you suggest that the "bridge down" message be [info], with a [warn] only if all bridges for all transports fail, i.e., if we have no connectivity at all?

comment:2 in reply to:  1 Changed 5 years ago by arma

Replying to dcf:

Do you suggest that the "bridge down" message be [info], with a [warn] only if all bridges for all transports fail, i.e., if we have no connectivity at all?

That is what I was thinking, yes.

Quoting from https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#WhatloglevelshouldIuse :
"warn": something bad happened, but we're still running. The bad thing might be a bug in the code, some other Tor process doing something unexpected, etc. The operator should examine the message and try to correct the problem.

If the operator had selected these bridges herself, I could see a warn here. But since they come prechosen, and there are many of them exactly to tolerate some being down, it doesn't seem like something the user needs to know about.

That said, there's a messy race condition here: if the down one is the first one we try, there aren't any working at the time, so we would end up warning anyway. I'm not sure how to fix.

comment:3 Changed 5 years ago by asn

(Note (to self): implementation-wise, this does not look like a trivial change. The Proxy Client error message is currently coming from connection_read_proxy_handshake() which is completely isolated and has no way to know whether tor successfully connected to the rest of the bridges.)

comment:4 Changed 5 years ago by nickm

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

comment:5 Changed 4 years ago by nickm

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

comment:6 Changed 3 years ago by nickm

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

comment:7 Changed 2 years ago by isis

Cc: isis added
Keywords: tor-bridge added
Milestone: Tor: 0.2.???Tor: 0.2.8.x-final
Owner: set to isis
Points: small
Priority: normalminor
Status: newassigned

I think we want [NOTICE] level instead of [INFO], because nobody ever sees the latter and a bridge being unreachable is probably something that the user should know about. If it's just a level change, then this is easy. As asn points out above, it we actually want to log only when no bridge are reachable, then we need some bigger changes.

FWIW, I'll take this.

comment:8 Changed 21 months ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

These seem like features, or like other stuff unlikely to be possible this month. Bumping them to 0.2.9

comment:9 Changed 19 months ago by nickm

Keywords: tor-pt added
Severity: Normal
Sponsor: SponsorS-can

comment:10 Changed 18 months ago by isabela

Points: small1

comment:11 Changed 15 months ago by isis

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

Defer some of my 029 tickets to ???

comment:12 Changed 12 months ago by teor

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

Milestone renamed

comment:13 Changed 11 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:14 Changed 6 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:15 Changed 6 months ago by nickm

Keywords: logging easy added

comment:16 in reply to:  15 Changed 8 weeks ago by arma

Replying to nickm:

Nick added the keyword easy, but asn noted "implementation-wise, this does not look like a trivial change". I think asn is right. We need to put flags on each bridge about whether it's been tried and failed, and do a warn when the last one gets the flag set.

Note: See TracTickets for help on using tickets.