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

[Tor Bug Tracker & Wiki]

#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:  #29005   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #22453 => #29005


Comment:

 Just checking, do all your relays have `CountPrivateBandwidth 1`?
 I can't see any obvious bugs in that code, but I might find some while I'm
 doing #29005.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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:  #22453   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 I guess not.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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:  #22453   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:20 juga]:
 > I am.
 > However, just changing this function
 https://gitweb.torproject.org/tor.git/tree/src/or/rephist.c?h=maint-0.2.9#n1431
 to log when it would be 0 and return 1, it's an easy change. Maybe i
 create a child ticket for that?.

 Do we need to make this change to Tor before we deploy sbws?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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:  #22453   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 I am.
 However, just changing this function
 https://gitweb.torproject.org/tor.git/tree/src/or/rephist.c?h=maint-0.2.9#n1431
 to log when it would be 0 and return 1, it's an easy change. Maybe i
 create a child ticket for that?.

 The part remaining would be to check the bandwidth test is done before
 publishing the descriptor.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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:  #22453   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #25925 => #22453


Comment:

 This issue is related to bandwidth self-tests:
 https://trac.torproject.org/projects/tor/ticket/22453#comment:37

 We won't know if we need bandwidth self-tests until we deploy sbws.
 So we could defer this ticket until 0.4.1 or later.

 Juga, are you ok with deferring this ticket?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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 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.

 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.

 > 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?. Which would be the way to check that the
 bandwidth self test finished?.
 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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, 031-backport,  |  Actual Points:
  032-backport, 033-backport,|
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #25925   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I think you just answered your own question in #22453:

 > If i understand it correctly, the self measured bandwidth
 (bandwidthcapacity) is obtained by rep_hist_bandwidth_assess [2].
 > [2] ​https://gitweb.torproject.org/tor.git/tree/src/or/rephist.c#n1207

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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, 031-backport,  |  Actual Points:
  032-backport, 033-backport,|
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #25925   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 any hints which is the file or function that is doing the division?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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, 031-backport,  |  Actual Points:
  032-backport, 033-backport,|
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #25925   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * parent:  25925 => #25925


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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, 031-backport,  |  Actual Points:
  032-backport, 033-backport,|
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * cc: juga (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#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, 031-backport,  |  Actual Points:
  032-backport, 033-backport,|
  034-triage-20180328, 034-removed-20180328  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  034-triage-20180328, 034-removed-20180328 =>
 029-backport, 031-backport, 032-backport, 033-backport,
 034-triage-20180328, 034-removed-20180328
 * points:   => 1


Comment:

 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.

 Here's how I suggest we make progress on this issue:
 * fix the truncation bug by always rounding up: make N / 1024 become (N +
 1023)/1024 (we don't need to check for overflow in the addition if it's
 64-bit arithmetic)
 * if we are about to publish a descriptor with 0 bandwidth, work out why,
 and log a diagnostic, then publish a descriptor with 1 bandwidth - this
 fixes a bunch of torflow / tor bugs where they can't handle 0 bandwidths.

 Here are the different diagnostics I can think of:
   * just started up, don't have 24 hours of bandwidth history - info level
   * a tor relay should always be using some bandwidth, so if we end up
 with zero otherwise, we should log a BUG with our uptime, inbound and
 outbound bandwidths, and the length of our bandwidth history

 We should backport the "always publish 1 or greater" fix to 0.2.9 and
 later. Maybe we should backport the diagnostic logging if it's not too
 big.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#24250: In a private network some relays advertise zero bandwidth-observed
--+
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Sebastian):

 There is no entry for HaseExit8 in the cached-descriptors.new file

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#24250: In a private network some relays advertise zero bandwidth-observed
--+
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 We might need cached-descriptors.new, if the issue occurs for newly
 restarted relays, that's where they'll be.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#24250: In a private network some relays advertise zero bandwidth-observed
--+
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Sebastian):

 It still happens on some relays for me, here's a complete consensus:

 {{{
 network-status-version 3
 vote-status consensus
 consensus-method 26
 valid-after 2018-02-06 01:00:00
 fresh-until 2018-02-06 02:00:00
 valid-until 2018-02-06 04:00:00
 voting-delay 300 300
 client-versions
 server-versions
 known-flags Authority Exit Fast Guard HSDir NoEdConsensus Running Stable
 V2Dir Valid
 recommended-client-protocols Cons=1-2 Desc=1-2 DirCache=1 HSDir=1
 HSIntro=3 HSRend=1 Link=4 LinkAuth=1 Microdesc=1-2 Relay=2
 recommended-relay-protocols Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSIntro=3
 HSRend=1 Link=4 LinkAuth=1 Microdesc=1-2 Relay=2
 required-client-protocols Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSIntro=3
 HSRend=1 Link=4 LinkAuth=1 Microdesc=1-2 Relay=2
 required-relay-protocols Cons=1 Desc=1 DirCache=1 HSDir=1 HSIntro=3
 HSRend=1 Link=3-4 LinkAuth=1 Microdesc=1 Relay=1-2
 params CircuitPriorityHalflifeMsec=3 NumDirectoryGuards=3
 NumEntryGuards=1 NumNTorsPerTAP=100 Support022HiddenServices=0
 UseNTorHandshake=1 UseOptimisticData=1 bwauthpid=1 cbttestfreq=10
 pb_disablepct=0 usecreatefast=0
 shared-rand-previous-value 4 CDABpBnzINVZVIfXfRO+K3oQZZOibsiTKT1AjdMaUN8=
 shared-rand-current-value 4 AbanQl+QQVUeQDnAf8sYRkEieTntYHhh9BZDnyJ4DpQ=
 dir-source seyanauth 38B5F41D4833F38FD05A5E3C278F39A64311F865 10.100.64.64
 10.100.64.64 9099 9098
 contact seyan
 vote-digest 79EE31128721A9806DA2BD1E565B23EF9109CDC0
 dir-source SigAuth 7536E60AF3E79B3E87A42EBC7DB57D1A07DE92BE 10.100.96.16
 10.100.96.16 42 23
 contact HonestSiccegge
 vote-digest 78556EA7B50DDD85D134768FBF2DAE0ED87DD473
 dir-source HaseAuth A34AD89CDD479256F85F4FF699655F437FA62996 10.100.9.212
 10.100.9.212 80 443
 contact Hase
 vote-digest FE7ABEEE7362E6CE878FEE302118FBAC01FF8043
 dir-source fauiwgDNAuth E03B333CF62733AFAE65D5BE5AA62047D96C459C
 10.100.4.22 10.100.4.22 4431 4430
 contact da...@fauiwg.de
 vote-digest B4C9B5E143AF2C3673B8B09E479DF6CA3B3C6950
 r HaseExit1 AfptXLsFWMiVQm5D+QTiroWRcMg JVIl8ETE1+WvYJXWZqDud0Cy6kY
 2018-02-05 14:59:28 10.100.9.212 1234 0
 s Exit Fast Guard HSDir Running Stable V2Dir Valid
 v Tor 0.3.2.9
 pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-4 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 w Bandwidth=7215 Unmeasured=1
 p accept 1-65535
 r HaseExit5 CxLr1q7BPYcQHefTYRJ8tYgigmY Y2xtorI0C0B/0NapCxoEKLJHmnI
 2018-02-05 14:59:28 10.100.9.212 5678 0
 s Exit Fast Guard HSDir Running Stable V2Dir Valid
 v Tor 0.3.2.9
 pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-4 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 w Bandwidth=7214 Unmeasured=1
 p reject 1-65535
 r HaseExit2 GtFo71nBP0wBdO88fHU/L1RZ1NY nfZYsypuj/Q9lMXvUj92ReKPd8U
 2018-02-05 14:59:28 10.100.9.212 2345 0
 s Exit Fast Guard HSDir Running Stable V2Dir Valid
 v Tor 0.3.2.9
 pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-4 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 w Bandwidth=7214 Unmeasured=1
 p accept 1-65535
 r fauiwgDNAuth IkbSMeNEKaPJMMsb5Wx6M424WWU K2jsxv0IVQkBJohtbP9LlFV8Hkc
 2018-02-05 22:39:18 10.100.4.22 4430 4431
 s Authority Running Stable V2Dir Valid
 v Tor 0.3.2.8-rc
 pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-4 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 w Bandwidth=69 Unmeasured=1
 p reject 1-65535
 r seyanon K8tBLf+7O6Z1GNM6JAAyslLU1P4 VPXAAmK2gkOJaSp7kErYftRxrGc
 2018-02-05 23:56:16 10.100.64.64 9091 0
 s Exit Fast Guard HSDir Running Stable V2Dir Valid
 v Tor 0.3.1.9
 pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-4 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 w Bandwidth=7215 Unmeasured=1
 p reject 1-65535
 r HaseExit4 NkdLUh3rtWI4kvp4H9ffPD0Orwo vxqCTsePaRmIDdl38QsSPkmsj0M
 2018-02-05 14:32:28 10.100.9.212 4567 0
 s Exit Running Stable V2Dir Valid
 v Tor 0.3.2.9
 pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-4 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 w Bandwidth=1 Unmeasured=1
 p reject 1-65535
 r HaseAuth X0fydwXA9D5s3kBOR+30/S3i2KY haPhm8l614XYe7BqV7a9lq9Jw5o
 2018-02-05 21:55:29 10.100.9.212 443 80
 s Authority Fast Guard HSDir Running Stable V2Dir Valid
 v Tor 0.3.2.9
 pr Cons=1-2 Desc=1-2 DirCache=1-2 HSDir=1-2 HSIntro=3-4 HSRend=1-2
 Link=1-4 LinkAuth=1,3 Microdesc=1-2 Relay=1-2
 w Bandwidth=7215 Unmeasured=1
 p reject 1-65535
 r HaseExit3 f2HJfe8QMqa6h0+l6Qqenb3v/hM I1a1N/1LD9CLe3AIHCROXnBY5Vw
 

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

[Tor Bug Tracker & Wiki]

#24250: In a private network some relays advertise zero bandwidth-observed
--+
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 Hm.  Does this have any correlation with the uptime for those relays?

 I'm thinking that, looking at the way that the commit_max() code in
 rephist.c interacts with rep_hist_bandwidth_assess(), we might not
 actually have any useful data here before we've been running for
 NUM_SECS_BW_SUM_INTERVAL (24 hours).  That could be a bug.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#24250: In a private network some relays advertise zero bandwidth-observed
--+
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs