[tor-bugs] #16255 [Tor]: Guardfraction on dirauths screws up bandwidth weights

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Jun 2 14:57:05 UTC 2015


#16255: Guardfraction on dirauths screws up bandwidth weights
------------------------+-----------------------------------
     Reporter:  asn     |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-dirauth tor-guard
Actual Points:          |  Parent ID:
       Points:          |
------------------------+-----------------------------------

Comment (by asn):

 OK, I found a silly bug that might be causing this problem.

 When we were calculating the total weights (T, G, M, E, D), while we were
 considering guardfraction information on the D/E weights and G/M weights,
 we didn't increase the total weight T by the right amount.

 So for example, if a router with bandwidth 1000 is 75% guard, it means it
 has 750 bandwidth as a guard (should be assigned to G), and 250 bandwidth
 as a non-guard (should be assigned to M). The issue is that we only
 incremented T by 750, whereas we should increment it by 750 + 250.

 This lead to T being much smaller than the sum G + M + E + D, which
 shouldn't happen IIUC.
 This is probably why we ended up with negative weights in the end.

 ---

 The above is an easy issue to fix. A harder issue to fix is that clients
 with disabled guardfraction, will try to validate the total weights in
 `networkstatus_verify_bw_weights()`. Since they don't understand
 guardfraction they will end up with different values than the authorities
 and then they will complain with stuff like:
 {{{
 Jun 02 17:47:59.000 [warn] Bw Weight Failure for Case 3b: Etotal
 10050.492000 != Mtotal 9436.164000. G=12930 M=0 E=0 D=21480 T=34410.
 Wgg=1.000000 Wgd=0.092800 Wmg=0.000000 Wme=0.000000 Wmd=0.439300
 Wee=1.000000 Wed=0.467900
 }}}
 Also, because of #13297 the authorities themselves will also complain
 after parsing their own consensus.

 Need to think more how to correctly deploy this.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16255#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list