#28703: bootstrapping very slow with filtered network --------------------------+------------------------------ Reporter: weasel | Owner: (none) Type: defect | Status: new Priority: Medium | Milestone: Component: Core Tor/Tor | Version: Tor: 0.3.4.9 Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: --------------------------+------------------------------ Description changed by weasel:
Old description: > Hi! > > Tor 0.3.4.9, on Debian stretch (thus linked against libssl > 1.1.0f-3+deb9u2) bootstraps very slowly if network access is limited. > > Network access is filtered, to only allow outgoing TCP connections to > ports 80 and 443. All other network connections are DROPped, i.e. from > an application point of few, connection attempts will just time out. Tor > is not told about this network restriction (i.e., no FirewallFirwall > configuration). > > The times in the following samples are times (in seconds) from process > launch (with a non-existing data directory) until PROGRESS=100 is > reported in a getinfo status/bootstrap-phase: > > ''>>150, 12, 135, 137, 131, 143, >>250, >>250, >>250, >>250, 12, 133, > 153, 135, >>250, 132, 153, 192, >>250, 134, 12, 133, 137, >>250, 135, > 142, >>250, 135, 9, >>250, >>250, 135, 134, 135, 132, 136, 133, 7, 133, > 134, >>250, 131, 136, 133, 135, 8, 133, >>250, 133, >>250, >>250, 12, > >>250, 6, >>250, >>250, 144, 132, 133, 139, 134, >>250, 12, >>250, 135, > >>250, 135, 133, 133, 134, 11, 133, 133, >>250, >>250 > > (>>x indicates that the bootstrap process was not finished after x > seconds and the test has been aborted.) > > The chances of bootstrapping in under two minutes (which is for instance > the timeout that onionbalance uses) are not very good. > > It'd be nice if Tor had a way to deal with this better. New description: Hi! Tor 0.3.4.9, on Debian stretch (thus linked against libssl 1.1.0f-3+deb9u2), bootstraps very slowly if network access is limited. Network access is filtered, to only allow outgoing TCP connections to ports 80 and 443. All other network connections are DROPped, i.e. from an application point of few, connection attempts will just time out. Tor is not told about this network restriction (i.e., no FirewallFirwall configuration). The times in the following samples are times (in seconds) from process launch (with a non-existing data directory) until PROGRESS=100 is reported in a getinfo status/bootstrap-phase: ''>>150, 12, 135, 137, 131, 143, >>250, >>250, >>250, >>250, 12, 133, 153, 135, >>250, 132, 153, 192, >>250, 134, 12, 133, 137, >>250, 135, 142, >>250, 135, 9, >>250, >>250, 135, 134, 135, 132, 136, 133, 7, 133, 134, >>250, 131, 136, 133, 135, 8, 133, >>250, 133, >>250, >>250, 12, >>250, 6, >>250, >>250, 144, 132, 133, 139, 134, >>250, 12, >>250, 135, >>250, 135, 133, 133, 134, 11, 133, 133, >>250, >>250 (>>x indicates that the bootstrap process was not finished after x seconds and the test has been aborted.) The chances of bootstrapping in under two minutes (which is for instance the timeout that onionbalance uses) are not very good. It'd be nice if Tor had a way to deal with this better. -- -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28703#comment:3> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs