Skip to content
Snippets Groups Projects
  1. Mar 28, 2023
  2. Mar 21, 2023
  3. Mar 20, 2023
  4. May 20, 2022
  5. Oct 01, 2021
  6. Aug 23, 2021
  7. Aug 10, 2021
  8. Jul 22, 2021
  9. Jul 13, 2021
  10. Jul 06, 2021
  11. Jan 07, 2021
  12. Jan 04, 2021
    • Philipp Winter's avatar
      Fix deadlock caused by accumulating events. · d7395247
      Philipp Winter authored
      So far, bridgestrap would only consume Tor's controller events from
      c.eventChan as long as the main execution flow was in TestBridgeLines.
      Outside of that function, controller events would keep on coming but not
      be consumed.  That worked fine for a while because c.eventChan has a
      buffer of 100 events but occasionally it would result in the buffer
      filling up, which would cause a deadlock because bulb, our controller
      library, would block on sending bridgestrap its events.
      
      This patch fixes the issue by also consuming events outside of
      TestBridgeLines.  The patch further adds a new Prometheus time series
      called pending_events, which captures the number of pending events.  The
      time series will help us monitor if this patch got the job done.
      d7395247
  13. Jan 03, 2021
    • Philipp Winter's avatar
      Use mutex in FracFunctional to protect map access. · d30ebe0f
      Philipp Winter authored
      This should fix a race condition that we ran into in deployment:
      
          fatal error: concurrent map iteration and map write
      
          goroutine 98984 [running]:
          runtime.throw(0x95bb18, 0x26)
                  /home/phw/sw/go/src/runtime/panic.go:1116 +0x72 fp=0xc0001735a8 sp=0xc000173578 pc=0x437e32
          runtime.mapiternext(0xc000173650)
                  /home/phw/sw/go/src/runtime/map.go:853 +0x554 fp=0xc000173628 sp=0xc0001735a8 pc=0x412534
          main.(*TestCache).FracFunctional(0xc00016e960, 0xc00014a990)
                  /home/phw/rcs/bridgestrap/cache.go:64 +0xbb fp=0xc0001736c0 sp=0xc000173628 pc=0x8610db
          main.(*TestCache).AddEntry(0xc00016e960, 0xc00031caa0, 0x98, 0x9dab00, 0xc00002e060, 0x13d5c8c, 0xed78148dc, 0x0)
                  /home/phw/rcs/bridgestrap/cache.go:161 +0x17c fp=0xc000173730 sp=0xc0001736c0 pc=0x861c5c
          main.testBridgeLines(0xc00000f500, 0x1c)
      d30ebe0f
  14. Dec 18, 2020
    • Philipp Winter's avatar
      Fix bug where test cache timeout was ignored. · 5a0e7d48
      Philipp Winter authored
      When bridgestrap read its cache from disk, it wouldn't only read the
      cache entries but also the cache timeout, overriding whatever we
      provided over the command line.  In other words, if bridgestrap saved a
      cache whose timeout was set to 24h, and we later restart bridgestrap
      with a given cache timeout of 18h, it would use 24h because that's what
      it read from disk.
      
      This patch fixes this bug in two ways: 1) we no longer write the cache
      timeout to disk and 2) we set the cache timeout after reading the cached
      entries from disk.
      5a0e7d48
    • Philipp Winter's avatar
      Collect Tor's event types. · c93fde23
      Philipp Winter authored
      This patch is a follow-up commit to tpo/anti-censorship/bridgestrap#10.
      c93fde23
    • Philipp Winter's avatar
      Reduce default cache timeout to 18 hours. · 0db35d80
      Philipp Winter authored
      It's important that bridgestrap's cache timeout is less than or equal to
      rdsys's pluggable transport expiry time.  If bridgestrap expires cache
      entries after 24 hours and rdsys wants to re-test bridges after 18
      hours, then there's a worst case of a 6 hour window within which
      bridgestrap will refuse to re-test rdsys's bridges because they're still
      in the cache.  Rdsys will keep bothering bridgestrap because it wants a
      more recent test result.
      
      This patch reduces bridgestrap's default cache timeout to 18 hours,
      which is the number of hours after which bridges should re-upload their
      descriptors to the bridge authority:
      https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt?id=c2a584144330239d6aa032b0acfb8b5ba26719fb#n369
      0db35d80
    • Philipp Winter's avatar
      Add more extensive logging. · 5683956c
      Philipp Winter authored
      This patch 1) makes obfs4proxy log its output to file and 2) adds a log
      message that prints the error message (if any) after sending a "SIGNAL
      ACTIVE" tor tor.
      5683956c
  15. Dec 14, 2020
  16. Dec 11, 2020
    • Philipp Winter's avatar
      Try waking up tor before giving it new bridges. · 88d8f0a8
      Philipp Winter authored
      By default, tor goes to sleep after 24 hours of no user activity.
      Bridgestrap's control port interaction does not count as user activity,
      which means that tor effectively stops working after 24 hours.  To work
      around this, we're sending tor a SIGNAL ACTIVE, which wakes up tor in
      case it went to sleep.  This is a cheap thing to do, so we might as well
      do it before each SETCONF.
      
      This patch fixes tpo/anti-censorship/bridgestrap#12.
      88d8f0a8
  17. Dec 07, 2020
  18. Dec 03, 2020
  19. Dec 01, 2020
    • Philipp Winter's avatar
      Make metrics more idiomatic to Prometheus. · e3135a66
      Philipp Winter authored
      Our metrics aren't implemented in the way Prometheus recommends.  This
      patch makes use of labels and renames our metrics to change that.  For
      example, instead of having two metrics called cache_hits and
      cache_misses, we now have a single metric called cache_total and it
      accepts a "type" label that can take on the values "hit" or "miss".
      
      This patch fixes tpo/anti-censorship/bridgestrap#10.
      e3135a66
  20. Nov 30, 2020
  21. Nov 26, 2020
  22. Nov 25, 2020
  23. Nov 23, 2020
  24. Nov 21, 2020
  25. Nov 20, 2020
Loading