1. 04 Jan, 2019 6 commits
  2. 03 Jan, 2019 3 commits
  3. 21 Dec, 2018 1 commit
    • David Goulet's avatar
      mainloop: Reactivate the linked connection event with a non empty list · 2420e84b
      David Goulet authored
      Linked connections aren't woken up by libevent due to I/O but rather
      artificially so we can, by chunks, empty the spooled object(s).
      
      Commit 5719dfb4 (in 0.3.4.1-alpha) made it
      that the schedule_active_linked_connections_event would be only called once at
      startup but this is wrong because then we would never go through again the
      active linked connections.
      
      Fortunately, everytime a new linked connection is created, the event is
      activated and thus we would go through the active list again. On a busy relay,
      this issue is mitigated by that but on a slower relays or bridge, a connection
      could get stuck for a while until a new directory information request would
      show up.
      
      Fixes #28717, #28912
      2420e84b
  4. 11 Dec, 2018 5 commits
  5. 10 Dec, 2018 1 commit
    • teor's avatar
      Fallbacks: Update the hard-coded fallback list in December 2018 · 4991b293
      teor authored
      Merge Phoul's two lists into teor's list.
      
      Replace the 150 fallbacks originally introduced in Tor 0.3.3.1-alpha in
      January 2018 (of which ~115 were still functional), with a list of
      157 fallbacks (92 new, 65 existing, 85 removed) generated in
      December 2018.
      
      Closes ticket 24803.
      4991b293
  6. 07 Dec, 2018 1 commit
    • teor's avatar
      Fallbacks: Update the hard-coded fallback list in December 2018 · 78e177d6
      teor authored
      Replace the 150 fallbacks originally introduced in Tor 0.3.3.1-alpha in
      January 2018 (of which ~115 were still functional), with a list of
      148 fallbacks (89 new, 59 existing, 91 removed) generated in
      December 2018.
      
      Closes ticket 24803.
      78e177d6
  7. 06 Dec, 2018 2 commits
  8. 05 Dec, 2018 1 commit
  9. 01 Dec, 2018 1 commit
  10. 27 Nov, 2018 1 commit
  11. 26 Nov, 2018 1 commit
  12. 22 Nov, 2018 1 commit
  13. 20 Nov, 2018 1 commit
  14. 15 Nov, 2018 14 commits
  15. 14 Nov, 2018 1 commit
    • David Goulet's avatar
      conn: Close the read side of a closing connection when write limit is reached · c99f220f
      David Goulet authored and Nick Mathewson's avatar Nick Mathewson committed
      
      
      In conn_close_if_marked(), we can decide to keep a connection open that still
      has data to flush on the wire if it is being rate limited on the write side.
      
      However, in this process, we were also looking at the read() side which can
      still have token in its bucket and thus not stop the reading. This lead to a
      BUG() introduced in 0.3.4.1-alpha that was expecting the read side to be
      closed due to the rate limit but which only applies on the write side.
      
      This commit removes any bandwidth check on the read side and simply stop the
      read side on the connection regardless of the bucket state. If we keep the
      connection open to flush it out before close, we should not read anything.
      
      Fixes #27750
      
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      c99f220f