Commit Graph

10 Commits

Author SHA1 Message Date
Isis Lovecruft
c2c5b13e5d
test: Add testing module and some unittests for bridges.c.
This roughly doubles our test coverage of the bridges.c module.

 * ADD new testing module, .../src/test/test_bridges.c.
 * CHANGE a few function declarations from `static` to `STATIC`.
 * CHANGE one function in transports.c, transport_get_by_name(), to be
   mockable.
 * CLOSES #25425: https://bugs.torproject.org/25425
2018-04-09 19:32:46 +00:00
teor
690f646bf8
Stop checking cached bridge descriptors for usable bridges
Stop checking for bridge descriptors when we actually want to know if
any bridges are usable. This avoids potential bootstrapping issues.
Fixes bug 24367; bugfix on 0.2.0.3-alpha.

Stop stalling when bridges are changed at runtime. Stop stalling when
old bridge descriptors are cached, but they are not in use.
Fixes bug 24367; bugfix on 23347 in 0.3.2.1-alpha.
2017-11-22 02:00:34 +11:00
Nick Mathewson
c1deabd3b0 Run our #else/#endif annotator on our source code. 2017-09-15 16:24:44 -04:00
teor
93a8ed3b83 Make clients wait to refresh bridges when they have a recent descriptor
But when clients are just starting, make them try each bridge a few times
before giving up on it.

These changes make the bridge download schedules more explicit: before
17750, they relied on undocumented behaviour and specific schedule
entries. (And between 17750 and this fix, they were broken.)

Fixes 23347, not in any released version of tor.
2017-09-12 10:38:25 -04:00
Nick Mathewson
7505f452c8 Run the copyright update script. 2017-03-15 16:13:17 -04:00
Nick Mathewson
1582adabbb Change approach to preventing duplicate guards.
Previously I'd made a bad assumption in the implementation of
prop271 in 0.3.0.1-alpha: I'd assumed that there couldn't be two
guards with the same identity.  That's true for non-bridges, but in
the bridge case, we allow two bridges to have the same ID if they
have different addr:port combinations -- in order to have the same
bridge ID running multiple PTs.

Fortunately, this assumption wasn't deeply ingrained: we stop
enforcing the "one guard per ID" rule in the bridge case, and
instead enforce "one guard per <id,addr,port>".

We also needed to tweak our implementation of
get_bridge_info_for_guard, since it made the same incorrect
assumption.

Fixes bug 21027; bugfix on 0.3.0.1-alpha.
2017-02-28 08:16:33 -05:00
Nick Mathewson
2cee38f76a Merge branch 'prop271_030_v1_squashed' 2016-12-16 11:20:59 -05:00
Nick Mathewson
53f248f6c9 Add some needed accessors/inspectors for bridge/guard convergence 2016-12-16 11:06:18 -05:00
Nick Mathewson
1d52ac4d3f Lay down some infrastructure for bridges in the New Guard Order.
This includes:
  * making bridge_info_t exposed but opaque
  * allowing guards where we don't know an identity
  * making it possible to learn the identity of a guard
  * creating a guard that lacks a node_t
  * remembering a guard's address and port.
  * Looking up a guard by address and port.
  * Only enforcing the rule that we need a live consensus to update
    the "listed" status for guards when we are not using bridges.
2016-12-16 11:06:18 -05:00
Nick Mathewson
8da24c99bd Split bridge functions into a new module.
This patch is just:
   * Code movement
   * Adding headers here and there as needed
   * Adding a bridges_free_all() with a call to it.

It breaks compilation, since the bridge code needed to make exactly
2 calls into entrynodes.c internals.  I'll fix those in the next
commit.
2016-11-30 14:42:52 -05:00