Skip to content
Snippets Groups Projects

In a private network some relays advertise zero bandwidth-observed

    • Closed (moved) Issue created by Sebastian Hahn @sebastian

    A lot of relays have these lines:

    bandwidth 1073741824 1073741824 0

    even though at least some of them have handled actual traffic. The network is a private non-testing Tor network that is deployed in 10.0.0.0/8 space.

    I'm using the following options: ExtendAllowPrivateAddresses 1 EnforceDistinctSubnets 0 ClientRejectInternalAddresses 0 ClientDNSRejectInternalAddresses 0 CountPrivateBandwidth 1 ExitPolicyRejectPrivate 0

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Sebastian Hahn changed milestone to %Tor: unspecified

      changed milestone to %Tor: unspecified

    • Sebastian Hahn added 031-unreached-backport 032-unreached-backport 033-unreached-backport 034-removed-20180328 034-triage-20180328 component::core tor/tor milestone::Tor: unspecified parent::29005 points::1 priority::medium severity::normal status::new type::defect labels

      added 031-unreached-backport 032-unreached-backport 033-unreached-backport 034-removed-20180328 034-triage-20180328 component::core tor/tor milestone::Tor: unspecified parent::29005 points::1 priority::medium severity::normal status::new type::defect labels

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Trac:
      Summary: In a private network some relays advertise zero weight to In a private network some relays advertise zero bandwidth-observed

    • Nick Mathewson
      Nick Mathewson @nickm ·

      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.

      Trac:
      Milestone: Tor: 0.3.3.x-final to Tor: 0.3.4.x-final

    • S
      Sebastian Hahn @sebastian ·
      Author

      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=30000 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 dario@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 2018-02-05 14:30:28 10.100.9.212 3456 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 SigAuth igPqLqk6tj6x0HFvyxN/bKRc0jI jBeTyMIjpLu28TFm3onQFBPhQC0 2018-02-05 08:06:39 10.100.96.16 23 42
s Authority Fast 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=463 Unmeasured=1
p reject 1-65535
r HaseExit7 tOQH7J/J1mWuvykvkRqchatrv/c tiZS4nrMcwMhlUCCmJZAlQW9Kpc 2018-02-05 14:59:28 10.100.9.219 7890 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 reject 1-65535
r HaseExit6 wtU6Rrgd7rTaCWsziTedxHcJHds VjYNjNglrm0gQHND5vwCU30iL/Y 2018-02-05 14:59:28 10.100.9.212 6789 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 reject 1-65535
r darioTorRelay wxR0OsU7nNjq4Fng+zDpaBvBUdU nMHyATlIwcJF1M44VK5cJkWVAug 2018-02-05 07:46:35 10.100.64.72 4430 4431
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 seyanauth xCN3LSdZ4Hmk8T+LM4H5b329jAg 00geTkSDIZbSXqSsc7fKBsEqhNs 2018-02-05 09:55:15 10.100.64.64 9098 9099
s Authority 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=7252 Unmeasured=1
p reject 1-65535
r HaseExit8 06vAR+CGjZbC3GBIRSZjPrlzkOU xkmDfiaJG5dWohwKHL7BmQOX27M 2018-02-05 14:29:28 10.100.9.219 8901 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=0 Unmeasured=1
p reject 1-65535
r HaseExit9 5Q3ktH7IdOfT5vjBh/k6iQTMt4M gg54LR8z3u3HJu0zbDImagd9gYA 2018-02-05 14:31:28 10.100.9.219 9012 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=0 Unmeasured=1
p reject 1-65535
directory-footer
bandwidth-weights Wbd=4218 Wbe=0 Wbg=0 Wbm=10000 Wdb=10000 Web=10000 Wed=4323 Wee=10000 Weg=4323 Wem=10000 Wgb=10000 Wgd=1459 Wgg=10000 Wgm=10000 Wmb=10000 Wmd=4218 Wme=0 Wmg=0 Wmm=10000
directory-signature 38B5F41D4833F38FD05A5E3C278F39A64311F865 CC360137B6D0EB9E53AAFDE9741C9709A01D901C
-----BEGIN SIGNATURE-----
YUd8LBbPM8BXFP+mv6vobndy1sluJAIV7HNG4lcUWMQ8qmMzTH2TiOJx3yRLCiC2
EnBuYyIWhj9l0LIT7yUzDgp8Yaqo4YF1Vl9Yw3NENmm4792LGYylPoq7trDhJM4e
ERejbN73ItitZZljJfhmUBrCBn4Hori9pWnLQ+duzGulWKO0i3qRIfbBVoQtVQMs
Y9H4fI9BxP7E3ryrs6GzxnfGn4cGth5F8A+9pS4ADPyWL3ZrrX1y5f16JqXR+6JJ
CT+SpuaKk+UVe5QYOO48jaQABPNtnwFqUF/zuY1hCXRMVayoxJH1NJRPvVwgjmZ4
hBAIG0JxYV2/KsdPvZpxOw==
-----END SIGNATURE-----
directory-signature 7536E60AF3E79B3E87A42EBC7DB57D1A07DE92BE 284598AD8D1140CC58A49FF7D4AA7E78EB22F234
-----BEGIN SIGNATURE-----
UvSHYJm3GRajRCmq8DXIFlv4BFknW4x8voVcKRK9hHKDHR44gCdd3g9E1sWmMhz2
LpLwFgC5GR6YasVqYzZGdh6dWGB+9OtV1P0panLg6K6r2KIV3nNsGZAoTS7d7voK
2K2MyEL5oUfXfqaYfUeXA6Rslopg5Yq6npxP+kxtGaqJFEwZY1A4e+cTL5Ehsd+N
xRzz1cVbYUBDUmennUrnbw/6wwaXNmts1miD5TiteukUCq2QowBLQXNYRkSinvZN
IpsqFTWOpfGoUlHEVVBKRbXcJy7htKds6oFWPGKkQUHYrtKu3LXV0y4uqM/c5Og1
vJe7/QDcoFWupzsHqFg8Fw==
-----END SIGNATURE-----
directory-signature A34AD89CDD479256F85F4FF699655F437FA62996 4F4C0683DEED4EF78033069C0AD25B39436DBB34
-----BEGIN SIGNATURE-----
CBBaNEhe7IwG01CcpbNxOfi50V1hqqq/a5deQaexkFI+leHESnmigzcDUXv1lIZy
JG81e/dDZFymQk4XAITpdJm4/qftWjiYvrsrQBPrrtoiTOcghRFllBwzc3fShVli
jle7HvK+ye/zWVLgVrVGRK6JMYsx0LSi56GZYSEqMHJoQcXV3trzxRgqcycuv02h
mYLuGfimUS4UfICO3Oy8hSsfNGobHm9uy3jgfT/pnEEeTUUVwoW7OUfJqPJ5p0Te
17PhZyv6Scxp1DTy0svJ62q1RAYfqwAK2DjeWBfkvRrc6/f4tw6gfk84tYD/3pBG
9L3iwFyQFWnA95O33xhG4g==
-----END SIGNATURE-----
directory-signature E03B333CF62733AFAE65D5BE5AA62047D96C459C 9308D4FC6C96289E652B4EB2B614EAD441231B2C
-----BEGIN SIGNATURE-----
Qvgzw37Shlm7xxSDxLhSdk+aBOlnPfLQPrBS/gYd6W06u+JaxLCwosszyMObcsO1
lrwmfOLBOu/losLrqXN+vRqIjkTz0ZM9vDGrdcEwOsIlqUmEPb9BtREICR5t1HUV
/QiVAEdmobMueW4YHUmfCb3G7lcRbRIwenI/0EM9aNDYJJ/G8olALtqMQkMNoA8u
U/obkLtiN8X5xKZVDZoYOt4BZO5PZ53nET/lBwYhs3CoHgxFPTV+cUXc13NpZ0Qz
7N4kSLiB9KhxzAiEpb/uAPsOBqnp1FWwFD++StX2im9gsdYYYd2L1tRhNZlkKvPO
yPtOKSni7YEMwW02xsALEQ==
-----END SIGNATURE-----

      Following three descriptors are in cached-descriptors file:

      @uploaded-at 2018-02-05 02:31:27
@source "10.100.9.212"
router HaseExit8 10.100.9.219 8901 0 0
identity-ed25519
-----BEGIN ED25519 CERT-----
AQQABm+HAd+gwguyDkTLzFAK/9Z5OY22s7BiIgSkHPlwFUBe25+lAQAgBACBIi4L
TN4CHZflny7wUsZTf1a+VjE39fmA1rRBRKgKWx+Ap84IfboO5xpSSPlm2Eyv8fJR
1s9KLh/y14gON16R0rr9gET3iX3M3a3yAFjMfMXzF3z0mhLvGxsAl7f0wQQ=
-----END ED25519 CERT-----
master-key-ed25519 gSIuC0zeAh2X5Z8u8FLGU39WvlYxN/X5gNa0QUSoCls
platform Tor 0.3.2.9 on Linux
proto 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
published 2018-02-05 02:31:27
fingerprint D3AB C047 E086 8D96 C2DC 6048 4526 633E B973 90E5
uptime 1510814
bandwidth 1073741824 1073741824 53926
extra-info-digest EA30CB3DAFB0D31F9AEA44BD896866974A349D68 U7/9a8Pw3TRAKAruk67tthX++V31U3P0hlNr1uRahKc
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMdIJTaPwJl6yVKRq66Dp9Fg7MFY4cU5xhnXL7AHFCvag6xqsIZqwt+/
h5tPxGeF5jByRsiwiLrdOmEINqA4g3ET6SN9xxNmzFZHdt/QibBpqy3u209TIF5W
Gmfn2mZs2BSnRrLF2Pzd4HFyE9gdyHOI6jKasEDpzSfATEsuSgfdAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAO9H5CSnFJgeU/H6e8ElOfg26WYpDZmnbgfs9cs0zQ/z4vjEj48kW5UU
q88AjV1UL43hTmONdYbRC79FCZBdlX4DWXcmnv1ZI7bNUbDpqmvJZl1v3LWvdo1+
k2FoQVVgHRI3drqEyJE/s64ndH+iUgDJe8LXGT9bbTGLcmTFzhwHAgMBAAE=
-----END RSA PUBLIC KEY-----
onion-key-crosscert
-----BEGIN CROSSCERT-----
P6GHk8+KaG/MNn5PwWHrv6C3kL1Cwi4g56/OzvcGDR8q83kOeBxzy6QWHOSO28Pb
3LLmBLfEEGF6rZEYrypkqkptDNKIgLD3IcuFNnRBB83zSX2ObpI1iUH8tNlyObDA
uFHytKxyX47XDHae7gvFeA9/6388dFowFaxIuPOYJtE=
-----END CROSSCERT-----
ntor-onion-key-crosscert 1
-----BEGIN ED25519 CERT-----
AQoABnGLAYEiLgtM3gIdl+WfLvBSxlN/Vr5WMTf1+YDWtEFEqApbADRYyfF3F6JZ
fVWYA6AKHH9L6hMaJ8Gz1ALFCjxNoUZVqNjA0rojAp1TRwdm7tL4CUGaDza/D8cf
NT/DBO1vZQI=
-----END ED25519 CERT-----
hidden-service-dir
ntor-onion-key e53A6BlhIg4nH5gfbDPRifnlbrDdmCXyX2lboC2+rjc=
accept 10.0.0.0/8:*
reject *:*
tunnelled-dir-server
router-sig-ed25519 t0uV1xWY17dHPmhGDp2kmow8Gbbksh1tAxlaE3JRM9+hID+jSdf9v9tAntldpcOweWg4+Wr0cbL9atl0hFXpCw
router-signature
-----BEGIN SIGNATURE-----
4wOIrGaxeoen3aMa85hVi886UhCTMcTiAfJQYWxwuW7UVsXpoWXbwivbpp81xteq
UmDyuagIUl18dzpKLWT9deVNcd24bySUSeRXIrVKOo7j+FDJ2vNP26GkOq33PEmP
sMuFNlgR+k3gCWXTdMIWG1FJoPvN4xa4cp4EqeWhW0k=
-----END SIGNATURE-----
      @uploaded-at 2018-02-02 02:29:25
@source "10.100.9.212"
router HaseExit8 10.100.9.219 8901 0 0
identity-ed25519
-----BEGIN ED25519 CERT-----
AQQABm+HAd+gwguyDkTLzFAK/9Z5OY22s7BiIgSkHPlwFUBe25+lAQAgBACBIi4L
TN4CHZflny7wUsZTf1a+VjE39fmA1rRBRKgKWx+Ap84IfboO5xpSSPlm2Eyv8fJR
1s9KLh/y14gON16R0rr9gET3iX3M3a3yAFjMfMXzF3z0mhLvGxsAl7f0wQQ=
-----END ED25519 CERT-----
master-key-ed25519 gSIuC0zeAh2X5Z8u8FLGU39WvlYxN/X5gNa0QUSoCls
platform Tor 0.3.2.9 on Linux
proto 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
published 2018-02-02 02:29:25
fingerprint D3AB C047 E086 8D96 C2DC 6048 4526 633E B973 90E5
uptime 1251492
bandwidth 1073741824 1073741824 53926
extra-info-digest 1EC363B51D2FC78FA57DE27C58864D390FD975AC h4s+3EuHHvOB8jj5NjwSE2KdKxlIWP+4OIMd4Vpotuo
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMdIJTaPwJl6yVKRq66Dp9Fg7MFY4cU5xhnXL7AHFCvag6xqsIZqwt+/
h5tPxGeF5jByRsiwiLrdOmEINqA4g3ET6SN9xxNmzFZHdt/QibBpqy3u209TIF5W
Gmfn2mZs2BSnRrLF2Pzd4HFyE9gdyHOI6jKasEDpzSfATEsuSgfdAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAO9H5CSnFJgeU/H6e8ElOfg26WYpDZmnbgfs9cs0zQ/z4vjEj48kW5UU
q88AjV1UL43hTmONdYbRC79FCZBdlX4DWXcmnv1ZI7bNUbDpqmvJZl1v3LWvdo1+
k2FoQVVgHRI3drqEyJE/s64ndH+iUgDJe8LXGT9bbTGLcmTFzhwHAgMBAAE=
-----END RSA PUBLIC KEY-----
onion-key-crosscert
-----BEGIN CROSSCERT-----
P6GHk8+KaG/MNn5PwWHrv6C3kL1Cwi4g56/OzvcGDR8q83kOeBxzy6QWHOSO28Pb
3LLmBLfEEGF6rZEYrypkqkptDNKIgLD3IcuFNnRBB83zSX2ObpI1iUH8tNlyObDA
uFHytKxyX47XDHae7gvFeA9/6388dFowFaxIuPOYJtE=
-----END CROSSCERT-----
ntor-onion-key-crosscert 1
-----BEGIN ED25519 CERT-----
AQoABnFDAYEiLgtM3gIdl+WfLvBSxlN/Vr5WMTf1+YDWtEFEqApbAGcFdWc/7Wwv
R7ooehfHXBctalRVMjv8E+IK7dh1un4n+K8tDAkWDibeTfxp6/fUpGzHUTAhmmWD
jnkuvh5MfAg=
-----END ED25519 CERT-----
hidden-service-dir
ntor-onion-key e53A6BlhIg4nH5gfbDPRifnlbrDdmCXyX2lboC2+rjc=
accept 10.0.0.0/8:*
reject *:*
tunnelled-dir-server
router-sig-ed25519 oacd926d92OAoywx1Z1ULmm4KNNRAl/sp9zdYvGO7bICSL60YkAnV5Qr+yJLFiPxccpUeW1kyqJKeqgrQqTnDA
router-signature
-----BEGIN SIGNATURE-----
bTkW3GqXib1giRl1BkrCDcLGyrSMGWbSrPzRaIRMD0wLNVWV5iw9rLvQvIh0N+Gc
AOsXcXPYxngEK8mqLPgTl/Rn/fKeM1/3brPJ1yCOPlvB/k5Cj43OfyMW/tbzbJ+y
TfR2oUXVSfTr54ZczaQlW17WnL1tHSWiUF+ZVmBFG3E=
-----END SIGNATURE-----
      @uploaded-at 2018-02-05 14:29:28
@source "10.100.9.212"
router HaseExit8 10.100.9.219 8901 0 0
identity-ed25519
-----BEGIN ED25519 CERT-----
AQQABm+HAd+gwguyDkTLzFAK/9Z5OY22s7BiIgSkHPlwFUBe25+lAQAgBACBIi4L
TN4CHZflny7wUsZTf1a+VjE39fmA1rRBRKgKWx+Ap84IfboO5xpSSPlm2Eyv8fJR
1s9KLh/y14gON16R0rr9gET3iX3M3a3yAFjMfMXzF3z0mhLvGxsAl7f0wQQ=
-----END ED25519 CERT-----
master-key-ed25519 gSIuC0zeAh2X5Z8u8FLGU39WvlYxN/X5gNa0QUSoCls
platform Tor 0.3.2.9 on Linux
proto 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
published 2018-02-05 14:29:28
fingerprint D3AB C047 E086 8D96 C2DC 6048 4526 633E B973 90E5
uptime 1553895
bandwidth 1073741824 1073741824 840
extra-info-digest F9C7B5A01ECB09E54A4AD82C421E3A9DDE428213 ASyr1AwkfIx6W4wxdwd1lnm8gpF0c2vzaxnfkHpXlCk
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMdIJTaPwJl6yVKRq66Dp9Fg7MFY4cU5xhnXL7AHFCvag6xqsIZqwt+/
h5tPxGeF5jByRsiwiLrdOmEINqA4g3ET6SN9xxNmzFZHdt/QibBpqy3u209TIF5W
Gmfn2mZs2BSnRrLF2Pzd4HFyE9gdyHOI6jKasEDpzSfATEsuSgfdAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAO9H5CSnFJgeU/H6e8ElOfg26WYpDZmnbgfs9cs0zQ/z4vjEj48kW5UU
q88AjV1UL43hTmONdYbRC79FCZBdlX4DWXcmnv1ZI7bNUbDpqmvJZl1v3LWvdo1+
k2FoQVVgHRI3drqEyJE/s64ndH+iUgDJe8LXGT9bbTGLcmTFzhwHAgMBAAE=
-----END RSA PUBLIC KEY-----
onion-key-crosscert
-----BEGIN CROSSCERT-----
P6GHk8+KaG/MNn5PwWHrv6C3kL1Cwi4g56/OzvcGDR8q83kOeBxzy6QWHOSO28Pb
3LLmBLfEEGF6rZEYrypkqkptDNKIgLD3IcuFNnRBB83zSX2ObpI1iUH8tNlyObDA
uFHytKxyX47XDHae7gvFeA9/6388dFowFaxIuPOYJtE=
-----END CROSSCERT-----
ntor-onion-key-crosscert 1
-----BEGIN ED25519 CERT-----
AQoABnGXAYEiLgtM3gIdl+WfLvBSxlN/Vr5WMTf1+YDWtEFEqApbAIX/a5N531O8
VZc+X2iHoNcogxRnpTYtxhGNd+9cdTGDR3yC6TgUo78gcsDXFiKcM1DnunP/BhB1
wuZZLaz/Pg0=
-----END ED25519 CERT-----
hidden-service-dir
ntor-onion-key e53A6BlhIg4nH5gfbDPRifnlbrDdmCXyX2lboC2+rjc=
accept 10.0.0.0/8:*
reject *:*
tunnelled-dir-server
router-sig-ed25519 lOGfRZ1Y80iFTny4RXkqFglEpQLxDjtWzNhLiCEUavAVZs0jX6i8PCrvtp25osNa/Tqts37oBygLDVfFiBHtCg
router-signature
-----BEGIN SIGNATURE-----
P6L0l/koM48liH/Ybswie+TlvINoJg8ehFslg9H5c7/4J/IQuL2Noa/EauiQkQJJ
L4nAU8+qml2pMgZoQgwEIDrB9MKw11Phv0dLbdAspPBFk3ZPCD7Wm9Y+HJKJKI7v
+nMOhAYhXdK4/K3Goj26V2d/2OBWz3h6Vykda6BjagU=
-----END SIGNATURE-----
    • T
      teor @teor ·

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

    • S
      Sebastian Hahn @sebastian ·
      Author

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

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Trac:
      Keywords: N/A deleted, 034-triage-20180328 added

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Per our triage process, these tickets are pending removal from 0.3.4.

      Trac:
      Keywords: N/A deleted, 034-removed-20180328 added

    • Nick Mathewson
      Nick Mathewson @nickm ·

      These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

      Trac:
      Milestone: Tor: 0.3.4.x-final to Tor: unspecified

    • T
      teor @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.

      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.

      Trac:
      Keywords: N/A deleted, 031-backport, 029-backport, 032-backport, 033-backport added
      Points: N/A to 1

    • juga
      juga @juga ·

      Trac:
      Cc: N/A to juga

    • juga
      juga @juga ·

      Trac:
      Parent: N/A to 25925

    • juga
      juga @juga ·

      Trac:
      Parent: 25925 to #25925 (moved)

    • juga
      juga @juga ·

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

    • T
      teor @teor ·

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

      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

    • T
      teor @teor ·

      0.3.1 is end of life, there are no more backports. Tagging with 031-unreached-backport instead.

      Trac:
      Keywords: 031-backport deleted, 031-unreached-backport added

    • T
      teor @teor ·

      0.3.2 is end of life, so 032-backport is now 032-unreached-backport.

      Trac:
      Keywords: 032-backport deleted, 032-unreached-backport added

    • juga
      juga @juga ·

      Replying to 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.

    • T
      teor @teor ·

      Replying to juga:

      Replying to 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.

      Edit: typo

    • T
      teor @teor ·

      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?

      Trac:
      Parent: #25925 (moved) to #22453 (moved)

    • juga
      juga @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.

    • T
      teor @teor ·

      Replying to 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?

    • juga
      juga @juga ·

      I guess not.

    • T
      teor @teor ·

      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 (moved).

      Trac:
      Parent: #22453 (moved) to #29005 (moved)

    • T
      teor @teor ·

      These open, non-merge_ready tickets can not get backported to 0.3.3, because 0.3.3 is now unsupported.

      Trac:
      Keywords: 033-backport deleted, N/A added

    • T
      teor @teor ·

      Hmm, I guess they should still get 033-backport-unreached

      Trac:
      Keywords: N/A deleted, 033-backport-unreached added

    • T
      teor @teor ·

      Fix 033-unreached-backport spelling.

      Trac:
      Keywords: 033-backport-unreached deleted, 033-unreached-backport added

    • T
      teor @teor ·

      0.2.9 is no longer maintained as of 1 January 2020. Therefore, we won't be backporting anything to it.

      (None of these tickets are merge_ready, so we can just delete the backport tag.)

      Trac:
      Keywords: 029-backport deleted, N/A added

    • Trac changed time estimate to 8h

      changed time estimate to 8h

    • Trac mentioned in issue #29005 (moved)

      mentioned in issue #29005 (moved)

    • Trac moved to tpo/core/tor#24250 (closed)

      moved to tpo/core/tor#24250 (closed)

    Please register or sign in to reply