Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:43:31Zhttps://gitlab.torproject.org/legacy/trac/-/issues/4600Spec doesn't mention password quotes2020-06-13T14:43:31ZDamian JohnsonSpec doesn't mention password quotesSection 5.1 of the control-spec [1] provides a nice description of authentication, but doesn't mention how to handle quotes in the password. Unsurprisingly controllers are expected to provide escaped quotes...
<pre>
atagar@morrigan:~$ t...Section 5.1 of the control-spec [1] provides a nice description of authentication, but doesn't mention how to handle quotes in the password. Unsurprisingly controllers are expected to provide escaped quotes...
<pre>
atagar@morrigan:~$ tor --hash-password "this has a \" in it"
16:E6DC1BCEDF55EDCA607ADDB8781795772E42AAC75F7B7630B6227232E4
atagar@morrigan:~$ telnet localhost 9051
Connected to localhost.
AUTHENTICATE "this has a \" in it"
250 OK
</pre>
I'm gonna guess that only quotes should be escaped by controllers.
I've been finding it a little frustrating to figure out when and what escaping is expected so I'm generally working from the assumption that I should ignore escaping unless specifically called out by the spec (like it is for authentication cookie paths, though that wasn't enough to work from alone [2]).
Cheers! -Damian
[1] https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt#l1924
[2] https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/socket.py#l54Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/6027Directory authorities on IPv62020-06-13T14:29:48ZLinus Nordberglinus@torproject.orgDirectory authorities on IPv6Directory authorities don't know enough about IPv6. There are a lot
of issues here, two of which are mentioned in #4847:
- init_keys()
- dirserv_generate_networkstatus_vote_obj()Directory authorities don't know enough about IPv6. There are a lot
of issues here, two of which are mentioned in #4847:
- init_keys()
- dirserv_generate_networkstatus_vote_obj()Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6456Merge parse_client_transport_line() and parse_server_transport_line()2020-06-13T14:21:26ZGeorge KadianakisMerge parse_client_transport_line() and parse_server_transport_line()There is too much code duplication between `parse_client_transport_line()` and `parse_server_transport_line`. We should probably merge them into one function during 0.2.4.x.There is too much code duplication between `parse_client_transport_line()` and `parse_server_transport_line`. We should probably merge them into one function during 0.2.4.x.Tor: 0.2.6.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/legacy/trac/-/issues/9580Tor should accept combined pluggable transport names2020-06-13T18:34:31ZGeorge KadianakisTor should accept combined pluggable transport namesThe plan for #7167 is to have flashproxy understand pluggable transporst like "websocket|obfs2", that is the combination of websocket and obfs2.
The good thing about our plan for #7167 is that it requires no real modifications to little...The plan for #7167 is to have flashproxy understand pluggable transporst like "websocket|obfs2", that is the combination of websocket and obfs2.
The good thing about our plan for #7167 is that it requires no real modifications to little-t-tor. However, in little-t-tor we do some checks on the transport names (in torrc, etc.) and ensure that they are C-identifiers -- but "websocket|obfs2" is not a C-identifier.
We should relax those checks so that they don't choke when we give them "websocket|obfs2".https://gitlab.torproject.org/legacy/trac/-/issues/10067Have `reject *` as the default exit policy2020-06-13T14:32:51ZLunarHave `reject *` as the default exit policyQuoting arma in [a discussion on tor-relays](https://lists.torproject.org/pipermail/tor-relays/2013-November/003191.html):
> On Thu, Oct 31, 2013 at 06:12:47PM -0700, Andy Isaacson wrote:
> > That's correct, it takes a deliberate action...Quoting arma in [a discussion on tor-relays](https://lists.torproject.org/pipermail/tor-relays/2013-November/003191.html):
> On Thu, Oct 31, 2013 at 06:12:47PM -0700, Andy Isaacson wrote:
> > That's correct, it takes a deliberate action on the part of the
> > administrator to become a relay; and another deliberate action to become
> > an exit relay.
>
> Actually, that second part isn't true. Once you decide to become a relay,
> the default is to exit to most popular ports.
>
> The main reason for this choice is the number of people who've told us
> that they are only able to run exit relays because "it's what Tor does
> when you run a relay", and their institution wouldn't let them do it if
> it required a manual config change to become an exit.
>
> Then again, that was a long time ago, and maybe it's gotten harder to
> sustain exits these days?
I think the change is actually worth making as I have seen two users being surprised by the current default behaviour. People running an exit while not fully aware of what it means usually turn unhappy.
(In any cases, we can discuss and `wontfix` if the previous rationale still hold.)Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/11737Damage of cached hte_hash values for HTs leads to undefined behavior2020-06-13T14:36:01ZcypherpunksDamage of cached hte_hash values for HTs leads to undefined behaviorLow budget memory modules affected by [soft errors](https://en.wikipedia.org/wiki/Soft_error)
Broken hte_hash value indirectly but drastically changes logic of code. Tor should to fix damaged hte_hash values or assert on failure. Or to b...Low budget memory modules affected by [soft errors](https://en.wikipedia.org/wiki/Soft_error)
Broken hte_hash value indirectly but drastically changes logic of code. Tor should to fix damaged hte_hash values or assert on failure. Or to be ready for such damages so it wasn't reason of another looks alike random bugs.
For example usage of HT_NEXT(_RMV) for iterating over hash table with broken hash values leads to shortage or infinite loops.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/12194rend_client_note_connection_attempt_ended() gets called redundantly2020-06-13T14:36:38ZAndrea Shepardrend_client_note_connection_attempt_ended() gets called redundantlyWhen hidden service connection attempts fail, rend_client_note_connection_attempt_ended() can get called once from connection_mark_unattached_ap() and then again from rend_client_desc_trynow() after it returns. See the log snippet in #1...When hidden service connection attempts fail, rend_client_note_connection_attempt_ended() can get called once from connection_mark_unattached_ap() and then again from rend_client_desc_trynow() after it returns. See the log snippet in #10616 for an example.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/12442Bridges should put their "transport" lines in their main descriptor, not extr...2020-06-13T14:36:57ZRoger DingledineBridges should put their "transport" lines in their main descriptor, not extra-info descBridgedb finds it a real hassle to paw through all the extrainfo descs, and match them up and check signatures and so on, just to know what ports and capabilities a given bridge is advertising.
Here's an example transport line from an e...Bridgedb finds it a real hassle to paw through all the extrainfo descs, and match them up and check signatures and so on, just to know what ports and capabilities a given bridge is advertising.
Here's an example transport line from an extra-info desc:
transport obfs3 24.38.24.35:10872
Since the transport is a capability, rather than a statistic, I think it should go in the main descriptor, like where our or-address line goes.
Another benefit here is that clients will be able to learn what other transports their bridge supports, since they fetch and have its descriptor anyway.
The only drawback I see is that it's a bit less secret what your transports are. But I think the extrainfo descriptor is served to anybody who asks for it, so it's not a secret now anyway from people who can fetch your main descriptor.
Another option is to start putting the transport line in *both* places for a while, so people who parse these things (e.g. Karsten) have more time to transition. Seems better just to identify all the people who parse these things, get them to prepare for it, and then just move the transport lines.
Then in the distant future, places like bridgedb can stop needing the extrainfo descriptors too.https://gitlab.torproject.org/legacy/trac/-/issues/12862Refactor code to modify circ->n_chan only by circuit_set_circid_chan_helper2020-06-13T14:37:50ZcypherpunksRefactor code to modify circ->n_chan only by circuit_set_circid_chan_helperRight now code assigns circ->n_chan before actually keeps it in chan-circid map. Previous value of circ->n_chan used as old_chan by circuit_set_n_circid_chan() and circuit_set_circid_chan_helper()
For example:
```
if (old_chan) {
...Right now code assigns circ->n_chan before actually keeps it in chan-circid map. Previous value of circ->n_chan used as old_chan by circuit_set_n_circid_chan() and circuit_set_circid_chan_helper()
For example:
```
if (old_chan) {
/*
* If we're changing channels or ID and had an old channel and a non
* zero old ID and weren't marked for close (i.e., we should have been
* attached), detach the circuit. ID changes require this because
* circuitmux hashes on (channel_id, circuit_id).
*/
if (old_id != 0 && (old_chan != chan || old_id != id) &&
!(circ->marked_for_close)) {
tor_assert(old_chan->cmux);
circuitmux_detach_circuit(old_chan->cmux, circ);
}
/* we may need to remove it from the conn-circid map */
search.circ_id = old_id;
search.chan = old_chan;
found = HT_REMOVE(chan_circid_map, &chan_circid_map, &search);
if (found) {
tor_free(found);
if (direction == CELL_DIRECTION_OUT) {
/* One fewer circuits use old_chan as n_chan */
--(old_chan->num_n_circuits);
} else {
/* One fewer circuits use old_chan as p_chan */
--(old_chan->num_p_circuits);
}
}
}
```
It's useless to process such circ->n_chan as old_chanTor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13243Password hashing unit tests are too slow2020-06-13T14:39:06ZNick MathewsonPassword hashing unit tests are too slowThe scrypt and pbkdf2 and pwbox tests I added for #12981 seem to run a bit slow. Running slow is kind of the point of a password hashing scheme, but slow unit tests are anathema.
We could make these tests (or the slower versions of th...The scrypt and pbkdf2 and pwbox tests I added for #12981 seem to run a bit slow. Running slow is kind of the point of a password hashing scheme, but slow unit tests are anathema.
We could make these tests (or the slower versions of them) off-by-default using the TT_OFF_BY_DEFAULT flag, I guess. But is that wise?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/13718Reachability Tests aren't conducted if there are no exit nodes2020-06-13T14:43:20ZTom Rittertom@ritter.vgReachability Tests aren't conducted if there are no exit nodesContext:
* https://lists.torproject.org/pipermail/tor-dev/2014-October/007613.html
* https://lists.torproject.org/pipermail/tor-dev/2014-October/007654.html
On 22 October 2014 05:48, Roger Dingledine <arma@mit.edu> wrote:
>> What I had ...Context:
* https://lists.torproject.org/pipermail/tor-dev/2014-October/007613.html
* https://lists.torproject.org/pipermail/tor-dev/2014-October/007654.html
On 22 October 2014 05:48, Roger Dingledine <arma@mit.edu> wrote:
>> What I had to do was make one of my Directory Authorities an exit -
>> this let the other nodes start building circuits through the
>> authorities and upload descriptors.
>
> This part seems surprising to me -- directory authorities always publish
> their dirport whether they've found it reachable or not, and relays
> publish their descriptors directly to the dirport of each directory
> authority (not through the Tor network).
>
> So maybe there's a bug that you aren't describing, or maybe you are
> misunderstanding what you saw?
>
> See also https://trac.torproject.org/projects/tor/ticket/11973
>
>> Another problem I ran into was that nodes couldn't conduct
>> reachability tests when I had exits that were only using the Reduced
>> Exit Policy - because it doesn't list the ORPort/DirPort! (I was
>> using nonstandard ports actually, but indeed the reduced exit policy
>> does not include 9001 or 9030.) Looking at the current consensus,
>> there are 40 exits that exit to all ports, and 400-something exits
>> that use the ReducedExitPolicy. It seems like 9001 and 9030 should
>> probably be added to that for reachability tests?
>
> The reachability tests for the ORPort involve extending the circuit to
> the ORPort -- which doesn't use an exit stream. So your relays should
> have been able to find themselves reachable, and published a descriptor,
> even with no exit relays in the network.
Okay, so the behavior I saw, and reproduced, is that reachability tests didn't succeed (and therefore descriptors weren't uploaded) when there were no exits. I think I may have figured out why, but there are some internals I haven't completely figured out. I'm going to lay out what I think and then the parts I'm not completely sure about.
First off, you're (obviously) correct about me misunderstanding extending the circuit via an Exit stream, that's not necessary. But still, I think the lack of Exits stopped the reachability tests from succeeding.
## too long; didn't read
I don't think reachability tests happen when there are no Exit nodes because of a quirk in the bootstrapping process, where we never think we have a minimum of directory information.
## target function: consider_testing_reachability
A reachability test is conducted from `consider_testing_reachability` (I think it's only conducted from here? Although maybe there's other situations it could happen..?) `consider_testing_reachability` is called from `circuit_send_next_onion_skin`, `circuit_testing_opened`, `run_scheduled_events`, and `directory_info_has_arrived`.
## call site #1: directory_info_has_arrived
This is called very frequently on router startup. But `consider_testing_reachability` will not be called if `router_have_minimum_dir_info` returns false:
```
void directory_info_has_arrived(time_t now, int from_cache)
{ //...
if (!router_have_minimum_dir_info()) {
//...
return;
} else { /* ... */ }
if (server_mode(options) && !net_is_disabled() && !from_cache &&
(can_complete_circuit || !any_predicted_circuits(now)))
consider_testing_reachability(1, 1);
}
```
`router_have_minimum_dir_info` returns the static variable `have_min_dir_info`. This variable is only set to 1 in `update_router_have_minimum_dir_info` and then only if there are Exits! Specifically, we will trigger `paths < get_frac_paths_needed_for_circs(options,consensus)` because we have 0% of the Exit Bandwidth, as shown by this error message:
```
Nov 09 22:10:26.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more descriptors: we have 5/5, and can only build 0% of likely paths. (We have 100% of guards bw, 100% of midpoint bw, and 0% of exit bw.)
```
```
update_router_have_minimum_dir_info(void)
{ //...
char *status = NULL;
int num_present=0, num_usable=0;
double paths = compute_frac_paths_available(consensus, options, now,
&num_present, &num_usable,
&status);
if (paths < get_frac_paths_needed_for_circs(options,consensus)) {
tor_snprintf(dir_info_status, sizeof(dir_info_status),
"We need more %sdescriptors: we have %d/%d, and "
"can only build %d%% of likely paths. (We have %s.)",
using_md?"micro":"", num_present, num_usable,
(int)(paths*100), status);
//...
res = 0;
goto done;
}
res = 1;
}
done:
if (res && !have_min_dir_info) { /* ... */ }
if (!res && have_min_dir_info) {
int quiet = directory_too_idle_to_fetch_descriptors(options, now);
tor_log(quiet ? LOG_INFO : LOG_NOTICE, LD_DIR,
"Our directory information is no longer up-to-date "
"enough to build circuits: %s", dir_info_status);
/* a) make us log when we next complete a circuit, so we know when Tor
* is back up and usable, and b) disable some activities that Tor
* should only do while circuits are working, like reachability tests
* and fetching bridge descriptors only over circuits. */
can_complete_circuit = 0;
control_event_client_status(LOG_NOTICE, "NOT_ENOUGH_DIR_INFO");
}
have_min_dir_info = res;
}
```
(The exact source line is in `frac_nodes_with_descriptors`, called by `compute_frac_paths_available`:)
```
/** For all nodes in <b>sl</b>, return the fraction of those nodes, weighted
* by their weighted bandwidths with rule <b>rule</b>, for which we have
* descriptors. */
double
frac_nodes_with_descriptors(const smartlist_t *sl,
bandwidth_weight_rule_t rule)
{
//...
if (smartlist_len(sl) == 0)
return 0.0;
```
This prevents reachability from occurring from `directory_info_has_arrived`.
## call site #2: run_scheduled_events (and call site #3)
There's a litany of conditions to call `consider_testing_reachability` from `run_scheduled_events`. In particular, there's `can_complete_circuit`
```
if (time_to_check_descriptor < now && !options->DisableNetwork) {
//...
/* also, check religiously for reachability, if it's within the first
* 20 minutes of our uptime. */
if (is_server &&
(can_complete_circuit || !any_predicted_circuits(now)) &&
!we_are_hibernating()) {
if (stats_n_seconds_working < TIMEOUT_UNTIL_UNREACHABILITY_COMPLAINT) {
consider_testing_reachability(1, dirport_reachability_count==0);
```
`can_complete_circuit` is only set in `circuit_send_next_onion_skin`, but then only if a circuit is built and it is not `circ->build_state->onehop_tunnel`. I _think_ this means the circuit is a full circuit, complete with Exit. Right?
```
int circuit_send_next_onion_skin(origin_circuit_t *circ)
{ //...
if (circ->cpath->state == CPATH_STATE_CLOSED) {
// ...
} else {
//...
hop = onion_next_hop_in_cpath(circ->cpath);
if (!hop) {
//...
if (!can_complete_circuit && !circ->build_state->onehop_tunnel) {
can_complete_circuit=1;
/* FFFF Log a count of known routers here */
log_notice(LD_GENERAL,
"Tor has successfully opened a circuit. "
"Looks like client functionality is working.");
//...
if (server_mode(options) && !check_whether_orport_reachable()) {
inform_testing_reachability();
consider_testing_reachability(1, 1);
```
This is also the third place `consider_testing_reachability` is called - there is only one left:
## call site #4: circuit_testing_opened
```
/** A testing circuit has completed. Take whatever stats we want.
* Noticing reachability is taken care of in onionskin_answer(),
* so there's no need to record anything here. But if we still want
* to do the bandwidth test, and we now have enough testing circuits
* open, do it.
*/
static void
circuit_testing_opened(origin_circuit_t *circ)
{
if (have_performed_bandwidth_test ||
!check_whether_orport_reachable()) {
/* either we've already done everything we want with testing circuits,
* or this testing circuit became open due to a fluke, e.g. we picked
* a last hop where we already had the connection open due to an
* outgoing local circuit. */
circuit_mark_for_close(TO_CIRCUIT(circ), END_CIRC_AT_ORIGIN);
} else if (circuit_enough_testing_circs()) {
router_perform_bandwidth_test(NUM_PARALLEL_TESTING_CIRCS, time(NULL));
have_performed_bandwidth_test = 1;
} else
consider_testing_reachability(1, 0);
}
```
But... as far as I can tell - a testing circuit is only used for two things: conducting a reachability test and conducting a bandwidth self-test. The only place a bandwidth self-test is called is inside `circuit_testing_opened`. So this call of `consider_testing_reachability` is a chicken or the egg problem.Tor: 0.2.6.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/13790Refactor and add comments to new_route_len()2020-06-13T14:40:22ZDavid Gouletdgoulet@torproject.orgRefactor and add comments to new_route_len()(function in src/or/circuitbuild.c)
At the moment, this function is kind of scary and it should be refactored and heavily documented to avoid future confusion. (This ticket exists because two different developers at different time span ...(function in src/or/circuitbuild.c)
At the moment, this function is kind of scary and it should be refactored and heavily documented to avoid future confusion. (This ticket exists because two different developers at different time span over a week expressed concerns about the behavior of HS and this function).
Bit of info on `new_route_len()`, this function is called to possibly extend a circuit with an extra hop that matches specific purpose(s). Right now it's testing the given purpose if it is *not* ESTABLISH_INTRO and TESTING, it will extend it to 4 hops (with exit information).
However, there are other purposes that do NOT need 4 hops. Fortunately, it seems that there are no code paths that end up calling this function with exit info and a purpose that should not be extended (investigated by special, sysrqb, asn and me). But, we all agree that this is very fragile thus the purpose condition in this function should be applied on only purposes that need 4 hops.
Furthermore, add more comments to make sure no more confusion happens with that fairly important function.Tor: 0.3.1.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/13862No error message when fatally failing to open files in DataDirectory2020-06-13T14:40:46ZTracNo error message when fatally failing to open files in DataDirectoryDue to installing packages from conflicting sources, I ended up with a Tor installation where the tor daemon (with `User toranon`) could access the DataDirectory, but not open the files in it for lack of permissions.
In this situation, ...Due to installing packages from conflicting sources, I ended up with a Tor installation where the tor daemon (with `User toranon`) could access the DataDirectory, but not open the files in it for lack of permissions.
In this situation, tor exits quickly with only the following messages:
```
Nov 30 00:07:12.878 [notice] Tor v0.2.5.10 (git-42b42605f8d8eac2) running on Linux with Libevent 2.0.18-stable, OpenSSL 1.0.1e-fips and Zlib 1.2.7.
Nov 30 00:07:12.878 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Nov 30 00:07:12.878 [notice] Read configuration file "/usr/share/tor/defaults-torrc".
Nov 30 00:07:12.878 [notice] Read configuration file "/etc/tor/torrc".
Nov 30 00:07:12.881 [notice] Opening Socks listener on 127.0.0.1:9050
Nov 30 00:07:12.881 [notice] Opening Control listener on 127.0.0.1:9151
Nov 30 00:07:12.881 [notice] Caching new entry toranon for toranon
Nov 30 00:07:12.881 [notice] Caching new entry toranon for toranon
```
There are no explicit `Log` directives in torrc.
Except for exit status 1, there is no indication to the user that something has gone wrong, and what the problem could be. We should print a helpful error message.
**Trac**:
**Username**: sqrt2Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15006Improve error message "Connecting to a relay directory failed (no route to ho...2020-06-13T17:43:15ZTracImprove error message "Connecting to a relay directory failed (no route to host)."Instead of stating "Connecting to a relay directory failed (no route to host)." it'd be useful to give the error message "Connecting to a relay directory failed (no route to host [host])." so that the user can investigate.
experienced w...Instead of stating "Connecting to a relay directory failed (no route to host)." it'd be useful to give the error message "Connecting to a relay directory failed (no route to host [host])." so that the user can investigate.
experienced with Tor Browser 4.0.3
**Trac**:
**Username**: krichterTor: 0.2.6.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15033make check should ignore torrc2020-06-13T14:43:39ZTracmake check should ignore torrc`make check` should ignore the system wide torrc to avoid errors, especially when the torrc contains a `User` option and it is not being run as root. It probably also shouldn't interact with any already installed version of tor in genera...`make check` should ignore the system wide torrc to avoid errors, especially when the torrc contains a `User` option and it is not being run as root. It probably also shouldn't interact with any already installed version of tor in general.
**Trac**:
**Username**: reezerTor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15240Tor starts PTs before creating the extended_orport_auth_cookie file they need2020-06-13T14:44:14ZJens KubiezielTor starts PTs before creating the extended_orport_auth_cookie file they needI'm using 0.2.5.10-1~d70.wheezy+1 from Debian and obfs4proxy 0.0.4-1 to set up a some bridges. My torrc looks like:
```
Address 192.0.2.23
OutboundBindAddress 192.0.2.23
OutboundBindAddress 2001:db8::94de
ORPort 56527
ExtORPort 55009
ORL...I'm using 0.2.5.10-1~d70.wheezy+1 from Debian and obfs4proxy 0.0.4-1 to set up a some bridges. My torrc looks like:
```
Address 192.0.2.23
OutboundBindAddress 192.0.2.23
OutboundBindAddress 2001:db8::94de
ORPort 56527
ExtORPort 55009
ORListenAddress 192.0.2.23:56527
ORListenAddress [2001:db8::94de]:56527
DataDirectory /var/lib/tor
PidFile /var/run/tor/tor.pid
Log notice file /var/log/tor/notices.log
ServerTransportPlugin scramblesuit exec /usr/bin/obfsproxy managed
ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy -enableLogging -logLevel=INFO
ServerTransportListenAddr obfs3 192.0.2.23:33027
ServerTransportListenAddr obfs3 [2001:db8::94de]:33027
ServerTransportListenAddr obfs4 192.0.2.23:47131
ServerTransportListenAddr obfs4 [2001:db8::94de]:47131
ServerTransportListenAddr scramblesuit 192.0.2.23:16428
ServerTransportListenAddr scramblesuit [2001:db8::94de]:16428
ContactInfo me@example.org
User debian-tor
RunAsDaemon 1
NumCPUs 1
PublishServerDescriptor 1
SocksPort 0
BridgeRelay 1
Exitpolicy reject *:*
Exitpolicy reject6 *:*
BridgeRecordUsageByCountry 1
ConnDirectionStatistics 1
EntryStatistics 1
ExtraInfoStatistics 1
DynamicDHGroups 1
HardwareAccel 1
```
When I enter the bridge line in TBB 4.5a4, I can't get a connection. Looking at the obfs4proxy.log, I see the message:
> 2015/03/11 22:19:25 [ERROR]: obfs4([scrubbed]:58915) - failed to connect to ORPort: mismatch in server hash
When I comment out the `ExtORPort` line and restart Tor, I can connect to the bridge. If I set `ExtORPort auto` I can't get a connection. Later I'll provide a more detailed log.Tor: 0.2.6.x-finalGeorge KadianakisGeorge Kadianakis