A few scenarios that must be tested (should be done for both prop271 and the legacy guard algorithm):
Normal run
Prop271:
This bug occurs with default configuration-
tor_bug_occurred_(): Bug: src/or/entrynodes.c:1909: entry_guards_note_guard_success: Non-fatal assertion old_state == GUARD_CIRC_STATE_USABLE_IF_NO_BETTER_GUARD failed.Legacy:
Make iptables rule that simulates FascistFirewall, then try connecting with FascistFirewall. See if it works.
prop271 seems to work pretty well if you turn on FascistFirewall and join a fascist network:
iptables -A OUTPUT -p tcp --match multiport ! --dport 80,443 -j DROP
Make iptables rule that simulates FascistFirewall, then try connecting without FascistFirewall. Note differences between old and new algo.
prop271 will not work well in a fascist firewall environment, if FascistFirewall is not turned on. It will basically get stuck on the first primary guard for a long time.
First prop271 attempt took 7 minutes to bootstrap. Second attempt took 2.5 minutes. Third attempt took 2.5 minutes.
Need to check whether old code was behaving better.
Make iptables rule that disables outgoing connections. Make sure that the sampled guards set size limit works.
Max SAMPLED_GUARDS size limit restriction works fine. Not expanding the guard sample any further; just hit the maximum sample threshold of 627
Test hardcoded entry guards (EntryNodes)
prop271 will not work at all with very restricted EntryNodes sets. It will fill up the sampled guards list, and then fail to find the right node. That's #20826 (moved).
Test bridges support
Basic bridge test with 1 bridge seems to work fine. SIGHUP also works fine transitioning between bridges and non-bridges.
Test transition between modes using SIGHUP
Basic testing seems to work. Managed to switch from "default" to "bridge" to "restricted" just with SIGHUP without any visible problems or leaks.