Opened 12 years ago

Last modified 7 years ago

#419 closed defect (Duplicate)

begin_dir broken on 0.1.2.13?

Reported by: arma Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.1.2.12-rc
Severity: Keywords:
Cc: arma, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I finally got tunneled connections working correctly for clients.

It works great when connecting to 0.2.0.x servers.
But when connecting to 0.1.2.13, it fetches a lot of directory
info over the TLS connection, but it gets an EOF early:

Apr 27 06:28:38.980 [debug] fetch_from_buf_http(): headerlen 141, bodylen 151383
.
Apr 27 06:28:38.981 [debug] connection_dir_client_reached_eof(): Received respon
se from directory server '86.59.21.38:443': 200 "OK"
Apr 27 06:28:38.981 [debug] connection_dir_client_reached_eof(): Time on receive
d directory is within tolerance; we are -9 seconds skewed. (That's okay.)
Apr 27 06:28:38.997 [info] tor_gzip_uncompress(): possible truncated or corrupt
zlib data
Apr 27 06:28:38.997 [info] connection_dir_client_reached_eof(): Unable to decomp
ress HTTP body (server '86.59.21.38:443').
Apr 27 06:28:38.998 [debug] conn_close_if_marked(): Cleaning up connection (fd -
1).
Apr 27 06:28:38.998 [info] connection_dir_request_failed(): Giving up on directo
ry server at '86.59.21.38'; retrying

Whereas on moria, it works:

Apr 27 06:29:36.305 [debug] fetch_from_buf_http(): headerlen 141, bodylen 471545
.
Apr 27 06:29:36.306 [debug] connection_dir_client_reached_eof(): Received respon
se from directory server '18.244.0.114:443': 200 "OK"
Apr 27 06:29:36.306 [debug] connection_dir_client_reached_eof(): Time on receive
d directory is within tolerance; we are -9 seconds skewed. (That's okay.)
Apr 27 06:29:36.352 [info] connection_dir_client_reached_eof(): Received network
status objects (size 1063662) from server '18.244.0.114:443'
Apr 27 06:29:36.417 [debug] check_directory_signature(): Signed directory hash s
tarts F2FF957E

Is this a bug with 0.2.0's linked connections? Or a bug with 0.1.2.13's handling
of begin_dir?

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (8)

comment:1 Changed 12 years ago by nickm

Looks more like an 0.1.2.13 bug to me. We set inbuf_reached_eof very carefully in the linked connection case;
it may be that we're doing it wrong on the socketpair case or something.

comment:2 Changed 12 years ago by nickm

Have we seen any more of this at all?

comment:3 Changed 12 years ago by nickm

16:52 < nickm> Should we do anythign about it? Like, never pick an 0.1.2.x

server for a begin_dir request?

16:53 < arma> as for 419... we could indeed patch it by declaring the 0.1.2.x

isn't meant to answer begindir requests.

16:53 < arma> this is fine with me.

comment:4 Changed 12 years ago by nickm

I'm going to take a stab at fixing the crash instance of it (406) and otherwise have clients require
directories running 0.2.0.x for begindir requests.

comment:5 Changed 12 years ago by nickm

Oops. Turns out that clients _do_ (starting 0.1.2.19) require 0.2.0.x for begindir.

comment:6 Changed 11 years ago by nickm

Closing, as the remaining instance of this is a duplicate of 406.

comment:7 Changed 11 years ago by nickm

flyspray2trac: bug closed.
Duplicate of 419.

comment:8 Changed 7 years ago by nickm

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