Re: [tor-bugs] #24250 [Core Tor/Tor]: In a private network some relays advertise zero bandwidth-observed

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#24250: In a private network some relays advertise zero bandwidth-observed
-------------------------------------------------+-------------------------
 Reporter:  Sebastian                            |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  029-backport, 033-backport,          |  Actual Points:
  034-triage-20180328, 034-removed-20180328,     |
  031-unreached-backport, 032-unreached-         |
  backport                                       |
Parent ID:  #25925                               |         Points:  1
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:17 juga]:
 >
 > Replying to [comment:9 teor]:
 > > Here's one source of this bug:
 > > * the relay measures its own bandwidth rate in bytes per seconds, then
 divides by 1024 to get kilobytes per second. When the bytes per second
 figure is less than 1024, the result is zero.
 >
 > descriptors publish bandwidth in bytes, i checked that there is not
 division by 1024 (nor 1000) in rephist.c affecting the write_array or the
 read_array. There are other divisions in the read/write arrays, but
 running chutney and logging them i didn't get values are not being 0.

 Ok.

 > as nickm commented:
 > {{{
 > b->next_period = start + NUM_SECS_BW_SUM_INTERVAL
 > }}}
 > set from the begining the `next_period` to 1 day, so `commit_max`
 doesn't happen until then. What i'm not sure is at what time it should be
 set and how it depends on the status of the bandwidth self test.

 In the current tor code, the bandwidth reporting interval does not depend
 on the bandwidth self-test.

 > > Here are the different diagnostics I can think of:
 > >   * just started up, don't have 24 hours of bandwidth history - info
 level
 >
 > This actually happen in chutney. It also happens that the descriptor is
 published before the bandwidth test is performed. Is possible that this
 also happen without chutney?.

 Yes.

 > Which would be the way to check that the bandwidth self test finished?.

 have_performed_bandwidth_test Is set when the test starts:

 https://github.com/torproject/tor/blob/b058f64cc002b44e6dd48616ca3163a01c3f3e14/src/core/or/circuituse.c#L1584

 There is no way to tell when the test finishes, because the cells are
 queued, and the function returns.

 We could make have_performed_bandwidth_test into a timestamp. Then we can
 wait 3*NUM_SECS_ROLLING_MEASURE after the test starts, and then upload the
 descriptor.

 Should we upload the descriptor if the bandwidth test doesn't happen
 within 20 minutes of starting the relay?

 > The bandwidth self test is call after checking reachability of the or
 port, and the descriptor is published when it's known that the or port is
 reachable, but there's no check on whether the bandwidth self test
 finished.

 Yes, you're right.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs