Opened 4 years ago

Closed 4 years ago

Last modified 10 months ago

#13658 closed defect (fixed)

Onionoo reports Bridge "advertised_bandwidth" as zero when "Bandwidth" is non-zero

Reported by: eli Owned by: karsten
Priority: Medium Milestone:
Component: Metrics/Onionoo Version:
Severity: Keywords:
Cc: eliaz@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Onionoo gives for my bridge:
["Fast","Running","Stable","Valid"],"last_restarted":"2014-10-16 19:14:12","advertised_bandwidth":0,"platform":"Tor 0.2.5.8-rc on Windows 7","pool_assignment":"email ip=4 flag=stable port=443"}

@type bridge-network-status 1.0 gives:
s Fast Running Stable Valid
w Bandwidth=40

Shouldn't the BWs both be 0 for a bridge in an email pool?

@type bridge-pool-assignment 1.0 gives the correct assignment:
f432cdb3dac5e87cf85fbecfe9475e4b7779d960 email ip=4 flag=stable port=443

Shouldn't this also give the trasports? (the bridge is configured as obfs3).

Child Tickets

Change History (7)

comment:1 Changed 4 years ago by karsten

Component: BridgeDBOnionoo
Owner: changed from isis to karsten
Status: newassigned

Here are the most recent descriptors published by this bridge:

@type bridge-server-descriptor 1.0
router obfsmaus 10.36.254.48 443 0 0
platform Tor 0.2.5.8-rc on Windows 7
protocols Link 1 2 Circuit 1
published 2014-11-04 08:39:10
fingerprint F432 CDB3 DAC5 E87C F85F BECF E947 5E4B 7779 D960
uptime 141449
bandwidth 98304 196608 40654
extra-info-digest 9B50572E8FC739BC8396D8586409E2B154419863
hidden-service-dir
contact somebody
ntor-onion-key QMmY/ZlRbfyVud+GKM3je9W2bklv6qnQXwRxR2+ZBHg=
reject *:*
router-digest B358C69B4ED2934CB3DB61D92C18391BCA6F8BFF

@type bridge-extra-info 1.2
extra-info obfsmaus F432CDB3DAC5E87CF85FBECFE9475E4B7779D960
published 2014-11-04 08:39:10
write-history 2014-11-04 08:24:54 (900 s) 111616,23552,7168,6144,9216,9216,46080,68608,8192,11264,3072,7168,15360,154624,10240,11264,8192,6144,16384,22528,119808,6144,9216,44032,16384,10240,69632,7168,38912,9216,14336,142336,8192,9216,14336,6144,132096,14336,4096,8192,48128,10240,644096,25600,18432,11264,5120,7168,109568,57344,8192,60416,11264,14336,23552,123904,11264,7168,7168,6144,49152,12288,7168,9216,43008,102400,22528,12288,6144,34816,11264,30720,23552,86016,10240,13312,9216,5120,73728,39936,9216,7168,62464,8192,16384,3072,40960,630784,22528,9216,45056,114688,35840,17408,9216,7168
read-history 2014-11-04 08:24:54 (900 s) 1215488,32768,10240,5120,11264,12288,622592,930816,9216,12288,2048,9216,15360,2455552,13312,15360,7168,8192,13312,525312,1378304,5120,9216,643072,15360,11264,940032,9216,93184,11264,11264,2251776,8192,9216,20480,6144,1373184,15360,4096,11264,664576,11264,1558528,25600,30720,11264,6144,10240,1280000,685056,7168,669696,11264,19456,21504,1333248,21504,9216,5120,9216,653312,14336,10240,12288,626688,1221632,18432,16384,6144,610304,11264,608256,22528,1132544,8192,16384,8192,7168,917504,620544,10240,6144,865280,10240,15360,2048,615424,1499136,18432,11264,612352,1649664,139264,44032,6144,10240
dirreq-write-history 2014-11-02 13:39:54 (900 s) 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2048,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2048,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1328128,0,0,0,0,569344,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,75776
dirreq-read-history 2014-11-02 13:39:54 (900 s) 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,123904,0,0,0,0,1024,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,10240
geoip-db-digest 9EF0A1874377BFB6413ED3F9EB5504B1DB17BE13
geoip6-db-digest 542D349827A88738A04332DAFF2516A384BCC8FF
bridge-stats-end 2014-11-03 17:21:41 (86400 s)
bridge-ips 
bridge-ip-versions v4=0,v6=0
bridge-ip-transports 
router-digest 9B50572E8FC739BC8396D8586409E2B154419863

So, it seems Onionoo is wrong about "advertised_bandwidth":0. (Can you explain why you think this number should be zero for a bridge in an email pool?)

Regarding obfs3, it seems the bridge doesn't include that transport in its router descriptor. There would be a line "transport obfs3". Can you check the logs for anything unusual?

Moving this ticket to component Onionoo, because I think it's unrelated to BridgeDB.

comment:2 Changed 4 years ago by eli

Can you explain why you think this number should be zero for a bridge in an email pool?

Previous implementations of the bridge (last September or so, ~55 days uptime, under the name maushaus, running as a vanilla bridge in a https pool, had a nonzero advertized bandwidth which increased (though very slowly) with time. When looking at onionoo & the DB for this current implementation (assigned to the email pool) I just assumedthat the 0 BW would change in time. So far (after 16 or so days uptime) it hasn't.

Regarding obfs3, it seems the bridge doesn't include that transport in its
routerdescriptor. There would be a line "transport obfs3". Can you check the logs for
anything unusual?

The only Warning I get in the log ia "Rejecting SOCKS request for anonymous connection to private address [scrubbed]. [3 similar message(s) suppressed in last 300 seconds" which from a old discussion in tor-talk is unimportant. The only line in the bridge torrc relating to transports is


ClientTransportPlugin obfs3 exec Tor\PluggableTransports\obfsproxy managed

I have no line "transport obfs3" - I didn't find anything relating to this (at least for bridges running on windows - in tor-manual.html.en or anywhere else. I'll try adding it and see what happens.

comment:3 Changed 4 years ago by eli

Oops, I misread your routerdescriptor to mean torrc. Of course there shouldn't be a line "transport obfs3" in torrc. I've removed it. Are you referring to logs other than Vidalia's message log?

comment:4 in reply to:  1 Changed 4 years ago by isis

Replying to karsten:

Regarding obfs3, it seems the bridge doesn't include that transport in its router descriptor. There would be a line "transport obfs3".


The "transport obfs3" line would actually be in the bridge's extra-info descriptor.

Last edited 4 years ago by isis (previous) (diff)

comment:5 in reply to:  description Changed 4 years ago by isis

Summary: discrepancy in Onionoo and bridge DBOnionoo reports Bridge "advertised_bandwidth" as zero when "Bandwidth" is non-zero

Replying to eli:

Onionoo gives for my bridge:
["Fast","Running","Stable","Valid"],"last_restarted":"2014-10-16 19:14:12","advertised_bandwidth":0,"platform":"Tor 0.2.5.8-rc on Windows 7","pool_assignment":"email ip=4 flag=stable port=443"}

@type bridge-network-status 1.0 gives:
s Fast Running Stable Valid
w Bandwidth=40

Shouldn't the BWs both be 0 for a bridge in an email pool?


I don't know what processing goes into the creation of Onionoo's JSON. Karsten would probably be better able to answer that question. However, with respect to the w Bandwidth=40 line, from the end of §3.4.2 of torspec.git/dir-spec.txt:

   The bandwidth in a "w" line should be taken as the best estimate
   of the router's actual capacity that the authority has.  For now,
   this should be the lesser of the observed bandwidth and bandwidth
   rate limit from the router descriptor.  It is given in kilobytes
   per second, and capped at some arbitrary value (currently 10 MB/s).


So, looking at your bandwidth line from the @type bridge-server-descriptor:

bandwidth 98304 196608 40654


From §2.1.1 in dir-spec.txt:

    "bandwidth" bandwidth-avg bandwidth-burst bandwidth-observed NL

       [Exactly once]

       Estimated bandwidth for this router, in bytes per second.  The
       "average" bandwidth is the volume per second that the OR is willing to
       sustain over long periods; the "burst" bandwidth is the volume that
       the OR is willing to sustain in very short intervals.  The "observed"
       value is an estimate of the capacity this relay can handle.  The
       relay remembers the max bandwidth sustained output over any ten
       second period in the past day, and another sustained input.  The
       "observed" value is the lesser of these two numbers.


It isn't exactly clear, when §3.4.2 says "...bandwidth rate limit", whether it is referring to the bandwidth-avg or the bandwidth-burst (note: torspec might need clarification). But, fortunately, in this case it doesn't matter, because the bandwidth-observed (40654) is less than the others. So, this answers where the rather random w Bandwidth=40 line comes from. :)

comment:6 in reply to:  1 Changed 4 years ago by karsten

Replying to karsten:

So, it seems Onionoo is wrong about "advertised_bandwidth":0.

Turns out Onionoo was indeed wrong. This bridge had an advertised bandwidth of zero in its very first descriptor, and Onionoo ignored all subsequent descriptors and never updated that number. I just wrote and deployed a fix. As soon as this bridge publishes a new descriptor, Onionoo should update the advertised bandwidth value from that. (If it doesn't do that within 24 hours, please let me know!)

Are there any remaining issues on this ticket? If you have questions about configuring obfs3 on your bridge, the help desk at help@… may have better answers for you.

If no issues remain, let's close this ticket.

comment:7 Changed 4 years ago by eli

Resolution: fixed
Status: assignedclosed

I've but no further issues on this ticket. Thanks to all for the discussion, it's been helpful to know how the DB works. Closed. - eliaz

Last edited 4 years ago by eli (previous) (diff)
Note: See TracTickets for help on using tickets.