Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:55:56Zhttps://gitlab.torproject.org/legacy/trac/-/issues/244please detect your Tor server's IP address through NAT too2020-06-13T13:55:56Zweasel (Peter Palfrader)please detect your Tor server's IP address through NAT tooA user wrote:
One request is the ability of tor to
discover by himself the public IP when natted without me edit the torrc or
the /etc/hosts...maybe some functions that run every once that check and
maybe change the address...this is us...A user wrote:
One request is the ability of tor to
discover by himself the public IP when natted without me edit the torrc or
the /etc/hosts...maybe some functions that run every once that check and
maybe change the address...this is useful if you have the server running all
day but the connection is not so reliable.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/328Valid flags should only apply for naming authorities?2020-06-13T13:56:36ZRoger DingledineValid flags should only apply for naming authorities?Right now authorities mark servers as valid unless they manually decide not to.
Part of the goal of the 'naming' flag for authorities is to specify whether they
want to futz with their configuration and express opinions, or just leave i...Right now authorities mark servers as valid unless they manually decide not to.
Part of the goal of the 'naming' flag for authorities is to specify whether they
want to futz with their configuration and express opinions, or just leave it to
run.
I think we should make clients decide whether a server is valid based on a majority
of naming authorities, rather than a majority of all authorities.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/395TorExample.py parameters do not work as advertised2020-06-13T13:57:31ZSteven MurdochTorExample.py parameters do not work as advertisedThe documentation for TorExample.py (in https://tor-svn.freehaven.net/svn/torctl/trunk/python) includes the help text:
"TorExample.py <parameters> <command list>" but it actually expects "TorExample.py <command>", where each command
is o...The documentation for TorExample.py (in https://tor-svn.freehaven.net/svn/torctl/trunk/python) includes the help text:
"TorExample.py <parameters> <command list>" but it actually expects "TorExample.py <command>", where each command
is of the form <command name> <global parameters> <command parameters>".
For example:
$ python TorExample.py --host=localhost:9051 listen INFO
Unrecognized command: __host=localhost:9051
...
$ python TorExample.py listen --host localhost:9051 INFO
INFO circuit_predict_and_launch_new(): Have 5 clean circs (2 internal), need another exit circ.
...
Either the code should be made consistent with the document or vice versa.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/401up-to-date check on dirinfo doesn't consider networkstatus freshness2020-06-13T13:57:36ZNick Mathewsonup-to-date check on dirinfo doesn't consider networkstatus freshnessDeferred from 0.1.2.x:
? - Bug: combination of things:
When we've been idle a long time, we stop fetching server
descriptors. When we then get a socks request, we build circuits
immediately using whatever descriptors we have...Deferred from 0.1.2.x:
? - Bug: combination of things:
When we've been idle a long time, we stop fetching server
descriptors. When we then get a socks request, we build circuits
immediately using whatever descriptors we have, rather than waiting
until we've fetched correct ones.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/448We discard old guards before getting new networkstatuses2020-06-13T13:58:18ZRoger DingledineWe discard old guards before getting new networkstatuses Jun 09 01:23:05.146 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "moria1" at 128.31.0.34:9031 (published 2007-05-09 06:
29:03)
Jun 09 01:23:05.174 [info] networkstatus_list_update_recent(): Netw... Jun 09 01:23:05.146 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "moria1" at 128.31.0.34:9031 (published 2007-05-09 06:
29:03)
Jun 09 01:23:05.174 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "moria1" at 128.31.0.34:9031 (published 2007-05-09 06:29:03)
is now "recent"
Jun 09 01:23:05.189 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "tor26" at 86.59.21.38:80 (published 2007-05-09 06:26:
56)
Jun 09 01:23:05.217 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "tor26" at 86.59.21.38:80 (published 2007-05-09 06:26:56) is
now "recent"
Jun 09 01:23:05.232 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "dizum" at 194.109.206.212:80 (published 2007-05-09 06
:27:03)
Jun 09 01:23:05.261 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "dizum" at 194.109.206.212:80 (published 2007-05-09 06:27:03)
is now "recent"
Jun 09 01:23:05.276 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "moria2" at 128.31.0.34:9032 (published 2007-05-09 06:
27:13)
Jun 09 01:23:05.304 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "moria2" at 128.31.0.34:9032 (published 2007-05-09 06:27:13)
is now "recent"
Jun 09 01:23:05.304 [info] networkstatus_list_update_recent(): Networkstatus fro
m directory server "tor26" at 86.59.21.38:80 (published 2007-05-09 06:26:56) is
no longer "recent"
Jun 09 01:23:05.319 [info] router_set_networkstatus(): Setting networkstatus cac
hed from directory server "lefkada" at 140.247.60.64:80 (published 2007-05-09 06
:27:01)
Jun 09 01:23:05.348 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/847B1F850344D7876491A54892F904934E4EB85D
Jun 09 01:23:05.348 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/FFCB46DB1339DA84674C70D7CB586434C4370441
Jun 09 01:23:05.349 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/719BE45DE224B607C53707D0E2143E2D423E74CF
Jun 09 01:23:05.349 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/7EA6EAD6FD83083C538F44038BBFA077587DD755
Jun 09 01:23:05.349 [info] networkstatus_list_clean(): Removing too-old networks
tatus in moria5/cached-status/38D4F5FCF7B1023228B895EA56EDE7D5CCDCAF32
Jun 09 01:23:05.350 [info] routerstatus_list_update_from_networkstatus(): Not en
ough statuses to update router status list. (0/5)
Jun 09 01:23:05.350 [info] entry_guards_compute_status(): Summary: Entry 'h76066
2' is reachable, unusable and not live.
Jun 09 01:23:05.350 [info] remove_dead_entries(): Entry guard 'h760662' (554EC78
2556A47590FB5B4DEFF56A5B52DB9CD59) has been down or unlisted since 2007-05-08 05
:39:00 local time; removing.
The problem is that routers_update_all_from_networkstatus() calls
entry_guards_compute_status() even if there aren't enough statuses
around yet.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/451Bug: main.c:367: connection_stop_writing: Assertion conn->write_event failed;...2020-06-13T13:58:24Zweasel (Peter Palfrader)Bug: main.c:367: connection_stop_writing: Assertion conn->write_event failed; abortingOn tor26, after running for about 2 weeks, I get:
[err] Bug: main.c:367: connection_stop_writing: Assertion conn->write_event failed; aborting.
tor26 is:
* r10579
-O0
../../patch-debian-rules-DDEBUG_ROUTERLIST+INSTRUMENTDOWNLOADS...On tor26, after running for about 2 weeks, I get:
[err] Bug: main.c:367: connection_stop_writing: Assertion conn->write_event failed; aborting.
tor26 is:
* r10579
-O0
../../patch-debian-rules-DDEBUG_ROUTERLIST+INSTRUMENTDOWNLOADS
../../patch-tor-docs
../../patch-routerlist--two-asserts # just assert pointers added to the rl->routers list are even (%2==0)
../../patch-routerlist--shouldrebuildstore # rebuild store iff stats->journal_len > (5000)
../../patch-routerlist--writeoutforeach # in routerlist_assert_ok write out the first instance of the SMARTLIST_FOREACH makro
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d04885 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d06002 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x080a0c0f in connection_stop_writing (conn=0xed58948) at main.c:367
#4 0x0807b8f4 in connection_or_finished_flushing (conn=0xed58948) at connection_or.c:283
#5 0x08071afe in connection_finished_flushing (conn=0xed58948) at connection.c:2601
#6 0x08070ad1 in connection_handle_write (conn=0xed58948, force=0) at connection.c:2144
#7 0x080a14a5 in conn_write_callback (fd=241, events=4, _conn=0xed58948) at main.c:525
(gdb) p *conn
$1 = {magic = 2100428547, type = 4 '\004', state = 5 '\005', purpose = 0 '\0',
read_blocked_on_bw = 0, write_blocked_on_bw = 0,
hold_open_until_flushed = 0, inbuf_reached_eof = 0, edge_has_sent_end = 0,
edge_blocked_on_circ = 0, or_is_obsolete = 0, chosen_exit_optional = 0,
s = -1, conn_array_index = 561, read_event = 0x0, write_event = 0x0,
inbuf = 0xae38088, outbuf = 0xa0ee8a0, outbuf_flushlen = 0,
timestamp_lastread = 1182903016, timestamp_lastwritten = 1182903023,
timestamp_created = 1182869105, socket_family = 2, addr = 2331677697,
port = 41178, marked_for_close = 2087,
marked_for_close_file = 0x80fb026 "connection.c",
address = 0x8c44208 "138.250.148.1", linked_conn = 0x0, linked = 0,
reading_from_linked_conn = 0, writing_to_linked_conn = 0,
active_on_link = 0, dns_server_port = 0x0}
Let me know if there's any more info you might want to have.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/456sometimes dir mirrors answer 503 busy when they should say 4042020-06-13T13:58:27ZRoger Dingledinesometimes dir mirrors answer 503 busy when they should say 404In dirserv_estimate_data_size() we estimate the size assuming we have a descriptor
for every server we're asked about. This results in cases like
Jul 12 20:03:56.471 [info] connection_dir_client_reached_eof(): Received http status code ...In dirserv_estimate_data_size() we estimate the size assuming we have a descriptor
for every server we're asked about. This results in cases like
Jul 12 20:03:56.471 [info] connection_dir_client_reached_eof(): Received http status code 404 ("Servers unavailable") from server '161.53.160.104:9091' while fetching "/tor/server/d/15EB28E14A7983129CD78FC6DEA20FD21098A7EF+161342319749ADD4116CE0427DB328F5C4BE1629+165BAFDA7253DFEC1DE0A3C548F21DDEAEF52F9E+1692BCEEC6431120B7AEC3A1685C8FD0EEC5F5A9+16D6BEE79128246B32EE1C565B2C2DBCB9AB41D3+16E162BE70678D6BFD5CF63F86B9188FE771B31F+16E567D955496CA338D3432B097F157DF35DE8BC+1715CD5D98964C7E31B36B66C52E14DDA7816EA9+1723E44E2245391BEC1B483126B5FAA870444B7C+1731772EE54F2A51E6749F25F9EE6BFB65FB6858+1759016C497AC642B5A50130AFCCF1BB6B643A02+17AEAC0A87BB35E4F2EA041FDA24F5DBC3A792AB+17B881474EA0A2F64F989263A7AD30A0DCE6377D+183528CAC37D3FA3EF18281C948DD213CF08D087+184C7E375ACB1CC1AF908DD957A180C93AA4227E+1869C3BA669EF6264614A3888D5E9B43C5FE3884+1874E43C98993E8285DBC3752920D02C6C951663+18965516ED4CF01866788451421C9EDF1E6BD1AA+190A1DF5C543AC6BB9AB72FE8C4C7CDCAE86D2B0+197F9E91C8D2FED74C36FBD4DA00C5D632144468+19A126F8CC87F339F2B16A273F1CD0A247F2FA4A+19C704F44ECB6BF79170E09C634790B98C8D8544+19E487A6A3A272A04EF882FB07A2EE90895090CE+1A720FCD4A2849C83A2701CDD0D39D8FFD2E314D+1AA750EE5B7FED285F368B6FEB4428DF92C2BB31+1AB2DABF6007241131C5E443CDC60394761816AC+1AF2B7488D10BFDCFE6CA79D56FB83656F4ADC8D+1AF69AAD27DFB6AA63D1072FA5AED92B468540DE+1B6D306CA8E0C693FAD3FFAAFC59F653DEFB1491+1BA661163B8A14B9AFB98AA9D12B18A24CBE562A+1BC0D0980C5EB734AAD02B9E70CCFCC898CB315A+1BDDBDA5C4E6DB9B3443D979352A7BC9A9576FE1+1BE953E3BB58CE9B6EE261BF441C7F9B3BDA752D+1C0E414654093BA94EE84764C711449B0ED5704F+1C11365A76C3A583E708C040E6A3307F9043D02F+1C1CC7E04750FB2A0CADD6B2C70FFF50CC31C632+1C34CC4FEA875DBDDCF419DEB6A9DB48DDA652F9+1C7DFC2A6F38DC9EB1B3FCB6C2F865EBA6D19F74+1CB80E88CBE0573EE7E856797E0A7B32ECE7B4B7+1CF9F520154EA3C12A3AA42AE79C75F1DE4B6309+1D2BC778F1CEC8A37C33A6EE2897C7597B7CD526+1D878DC7566F10B8303138B36971023038F6F36C+1DB1A4D87A94E8CC2838C8E83F411A8CF5FBA0AC+1DC7FE119A441AFBD18E821B56CAB844278F8AF3+1DED6B4805370219D52E1C14C52092789C7EB8D7+1E33A33694596F3D6121C92FDA8882E2EC3A76C4+1E67F16C391DAFBD830049A379DD691EBC22E6B1+1ED62D8D7DA9F76501B7F95D9D7DD7E002F93640+1F35B4C9F94020AE9893C7358D9FA6D15A0B6807+1FCCEC0102ABE5A8BA18B4D34CBA3F3300FDE5AE+1FDE4FBC452C5D2BECEAF0B3CB15F644380D2A75+1FF2733FC1812FBAD51FEBBDE259B06BE0921A59+204697B4DF76664425ADB9F3F8D0B1A3591CA695+209F6EFEE6FDE553FEE8748FA5A7BA70964965F9+20AC0F4CFC447C4C9C18F42356104CABDFBD0D20+21036C9FF860815C8C043597B39BC80AE40A3560+212474B60CC275F91F716F89C5751E4BB7A78B5F+213E8B394E0590A9EC9360BB415867E00A1978E7+214AE65A8196F9C6EFC4765F0488A3CE7FBC433A+2172560E8EE391D29C5218446A242F822F1E1AE1+21743952EB0C848BE0D513926C989AA79EEAA0AC+21976CED8984D0099810A17793F49585C2BE5DD0+21A3E413C450399FD8AE5A7CEE3624DF7953DF54+21CE269692672D3FED7435B6F1F5D7BC22D334BC.z". I'll try again soon.
Jul 12 20:03:58.430 [info] connection_dir_client_reached_eof(): Received server info (size 0) from server '213.239.207.67:9032'
Jul 12 20:03:58.430 [info] connection_dir_client_reached_eof(): Received http status code 404 ("Servers unavailable") from server '213.239.207.67:9032' while fetching "/tor/server/d/9CE4717E88E096DF81C1C4FF04F9ECBEC7CD3A5B+9CF6B523BEDDAF0BB9E0365F235A30FE9B773481+9D1A6720FBD2A10956C0EC3F9906DB05F73BD0D4+9D6755D980C8A0FDE344C8D9DC075EFB55C1E65A+9D9674E83A649A5DB589467AE1BFC5D8C788344F+9DFE225679B7D8D1695E2F86EB9D5E25D8EBAB34+9E1B301AD61B971FE4014F90834D86167DB010CF+9E3C0B1343829809EEF2232B8F8A147DF40EB489+9E7D917BFA42EFA9A2FD520905662700FF39B6A9+9EFD73CEE0CF4DC558813599D6192FD493543894+9F0C194B70D97C3CDFFD8567054434BC58D241F4+9F37436BFE30729AE1C0F950F33BFC9111EA1C73+9F3E0FB041996920B40459961F195B5CD6399DC6+9FFCA011607CA2D04E5203DB9D0E81895F44C3F3+A0069CAD4ECA76DCB8A65665320DA7E17FFC93AD+A0133D0C1179A17FAC6C330012EAACE88CC611B9+A06385CA613FB0FCA712B7A5A2D2C5295AEBABAF+A09C82BE0551B262534A5E86343641B4D6773F85+A0AB774DE5543FBF9F9E79D6EA1EA7CF661E4461+A0AE08580B0169C82DB5D7D10FDC943BF8EEA7D3+A0C9E180FEAC7560B0560FAB88BF501C4714661A+A11B9D281FEA020597B0446248768F87D49EFE7A+A1841B8634E7766CD45119C907BF277C81C94FDB+A229B8C784C10932F5DD54F015E25D04730253EE+A23AB6FA0D08881A364E0E2CB881D7E3B805440F+A28055279C866549A1A0F51640D664D4A6FB3B41+A2BD80D6BD0E0805AEB05DF56178F0C158935A5C+A2C78532A2681EC56FCBE7E45C02353769BC1D95+A2D1067D7018B5EC457FFBF300F8829CB75031D2+A2E18660748CD4E2889655C13C515D2DDBC41256+A310436DD2C0BB21D0F1D821F25CF306C0BB8C37+A3329045F8D856CE1FC53318AF5078A36AD2012D+A3B99B3F0FD34C724249BD96D22B19402F3D028C+A419E8229A5DA157D2A08B76D29812B20E4F4433+A42CDE78731DB4732D4081737159F04945FE1AF2+A62B099009D02859F8B6CEAC9EC7593565B39E2A+A647325F16245859ABE97A91589550580719BEA1+A64CB0CF7D84039AC62B94727BF652204EC6816A+A695737A181822C144918FF5F4E9442EBB1A1249+A6CFCF877338AEF9423682989BE59A47910C9AFB+A6D5D4F300AEC3D2547A8087BECB2DC4BB7C3522+A705D5C1A04E02FEC2B9C65268B6066C53A95F3C+A723F2CCA05D6DBD26AD94C3A944E32BFDC78CDD+A72E0D5CA9E9EA457DA4FE59E94D0A9196F2C1E3+A74F5A31716382AA22CDBE96B5802527B5E4060E+A79F558B7A04CDCC76F3B9D7F57B12A49CEDC1E7+A7A114CFB2FD516205398920C8FC736305D8FE45+A828AB492F31A601136DD88EA4FAF313CB6B1A8A+A86240001CFD23E8501EB2CEE9B7E4FB0BE975DE+A8659A991509E1C2F26CB365184A106862A5060B+A878DCD037042319797E8017710138E835BE13BE+A886F2F8922803AD86242E20BDF17DA28A176791+A8DA069ABD97A98F4B842657D712E294648B6255+A8E6040879A14E6201D07DB10EE7AEBF1AC594C9+A9A306117B642E064D6065682325FAB355808904+A9B2472A36D800F37D31C7FCFDBA9625168CC6E1+AAEC2FDD441EC9AB9BF7C9F61B8E1C187A0643D7+AB03995964674450EC79D4A88E79898639780404+AB05341E510E4915874FF2C8A678B3FD0BE0EA7A+AB29C2B963427F98B18D4D8CA8927B671990AFDC+AB40DAFA0B6E91C114DBD9A6DEC69DF9A10C4D4A+ABBBE14C5B168675FE13B129B8B3076A0E1DFB59.z". I'll try again soon.
Jul 12 20:03:59.267 [info] connection_dir_client_reached_eof(): Received http status code 503 ("Directory busy, try again later") from server '70.84.114.153:9030'. I'll try again soon.
where the client is inefficient at realizing that it's asking for descriptors
that aren't available anywhere. If we estimated a bit better (by checking if we
have an answer at all), we could help clients react quicker. This would require
figuring out what descriptors we're being asked about, which means doing more
work before we decide whether to 503.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/475version comparison2020-06-13T13:58:37Zweasel (Peter Palfrader)version comparisonchanged recommendedversions on tor26 to only recommend 0.1.2.16 and 0.2.0.4:
Fri 00:06:31 <weasel> it made tor's notice message change too:
Fri 00:06:41 <weasel> from: Aug 02 07:08:58.368 [notice] This version of Tor (0.2.0.3-alpha-dev)...changed recommendedversions on tor26 to only recommend 0.1.2.16 and 0.2.0.4:
Fri 00:06:31 <weasel> it made tor's notice message change too:
Fri 00:06:41 <weasel> from: Aug 02 07:08:58.368 [notice] This version of Tor (0.2.0.3-alpha-dev) is newer than any recommended version, according to
3/3 version-listing network statuses. Versions recommended by more than 1 authority are: 0.1.1.26, 0.1.2.13, 0.1.2.14, 0.1.2.15,
0.2.0.2-alpha, 0.2.0.3-alpha
Fri 00:07:00 <weasel> to Aug 02 19:41:32.354 [warn] Please upgrade! This version of Tor (0.2.0.3-alpha-dev) is not recommended, according to 3/3
version-listing network statuses. Versions recommended by at least 1 authority are: 0.1.1.26, 0.1.2.13, 0.1.2.14, 0.1.2.15,
0.2.0.2-alpha, 0.2.0.3-alpha
Fri 00:07:22 <weasel> which was kinda funny. please upgrade: here is a list of older versions that are recommended
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/481Tor server complains about too less directory information, even if we are a s...2020-06-13T13:58:37ZTracTor server complains about too less directory information, even if we are a serverTor server complains about too less directory information to build a circuit, even if we are a server.
It is possible that you over read real problems because of this.
[Automatically added by flyspray2trac: Operating System: All]
**Tra...Tor server complains about too less directory information to build a circuit, even if we are a server.
It is possible that you over read real problems because of this.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Athaba0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/516read-history/write-history show non-relayed traffic too2020-06-13T14:28:47ZRoger Dingledineread-history/write-history show non-relayed traffic tooIn connection_buckets_decrement(), we report to rep_hist_note_bytes_read/written
whether the traffic was relayed traffic or our own traffic. If the user sets
RelayBandwidthRate and the relayed traffic constantly hits that level, then
any...In connection_buckets_decrement(), we report to rep_hist_note_bytes_read/written
whether the traffic was relayed traffic or our own traffic. If the user sets
RelayBandwidthRate and the relayed traffic constantly hits that level, then
any numbers higher than that in the read-history/write-history lines will be
due to locally initiated traffic.
The easy fix would be to only count bytes that were sent on relayed connections --
so locally initiated directory connections, and all circuits on connections that
recently carried traffic for an origin circuit, would be ignored:
Index: connection.c
===================================================================
--- connection.c (revision 11723)
+++ connection.c (working copy)
@@ -1546,12 +1546,12 @@
if (!connection_is_rate_limited(conn))
return; /* local IPs are free */
- if (num_read > 0)
- rep_hist_note_bytes_read(num_read, now);
- if (num_written > 0)
- rep_hist_note_bytes_written(num_written, now);
+ if (connection_counts_as_relayed_traffic(conn, now)) {
+ if (num_read > 0)
+ rep_hist_note_bytes_read(num_read, now);
+ if (num_written > 0)
+ rep_hist_note_bytes_written(num_written, now);
- if (connection_counts_as_relayed_traffic(conn, now)) {
global_relayed_read_bucket -= num_read;
global_relayed_write_bucket -= num_written;
}
Then I realized that this has the mirror-image problem: if the server
has uniform enough usage around its BandwidthRate, then just as we
were looking at spikes before and knowing they came from non-relayed
traffic, now we look at dips and conclude the same thing.
Hm.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/542looking for fallback-consensus in funny place2020-06-13T13:58:53ZRoger Dingledinelooking for fallback-consensus in funny placeNov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/c
ached-certs": No such file or directory
Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/c
ached-consensus": No such file or d...Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/c
ached-certs": No such file or directory
Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/c
ached-consensus": No such file or directory
Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "/home/arma/.tor/u
nverified-consensus": No such file or directory
Nov 03 21:15:07.749 [info] read_file_to_str(): Could not open "${prefix}/share/t
or/fallback-consensus": No such file or directory
My orconfig.h even says
/* Default location for platform-independent read-only data. */
#define SHARE_DATADIR "${prefix}/share"
Are we defining this wrong in the autoconf?
(Linux Debian Etch, I did an svn checkout and then ./autogen && ./configure &&
make && src/or/tor)
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/571dir mirrors not fetching unexpected certs2020-06-13T13:59:05ZRoger Dingledinedir mirrors not fetching unexpected certsif you run 0.2.0.13-alpha, and you use
a bridge relay that doesn't think lefkada is a v3 auth
(say, running 0.2.0.12-alpha),
then you'll constantly ask it for lefkada's cert, and it'll never have it.
aren't mirrors supposed to fetch cer...if you run 0.2.0.13-alpha, and you use
a bridge relay that doesn't think lefkada is a v3 auth
(say, running 0.2.0.12-alpha),
then you'll constantly ask it for lefkada's cert, and it'll never have it.
aren't mirrors supposed to fetch certs for keys that sign the consensus,
even if they didn't expect them?
<nickm> I thought so.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/574bridge or_conns aren't always setting identity map2020-06-13T13:59:08ZRoger Dingledinebridge or_conns aren't always setting identity mapDec 21 05:45:37.909 [warn] connection_or_remove_from_identity_map(): Bug: Didn't
find connection '$BD1A1566356ECC9FBF2BB8DE2CEE8C3F39BE61C9' on identity map whe
n trying to remove it.
Dec 21 05:45:37.909 [warn] connection_or_remove_from...Dec 21 05:45:37.909 [warn] connection_or_remove_from_identity_map(): Bug: Didn't
find connection '$BD1A1566356ECC9FBF2BB8DE2CEE8C3F39BE61C9' on identity map whe
n trying to remove it.
Dec 21 05:45:37.909 [warn] connection_or_remove_from_identity_map(): Bug: Didn't
find connection '$BD1A1566356ECC9FBF2BB8DE2CEE8C3F39BE61C9' on identity map whe
n trying to remove it.
Dec 21 05:45:37.910 [warn] _connection_free(): Bug: called on OR conn with non-z
eroed identity_digest
I usually get this when I kill my bridge while the bridge user's connection to it
is still open.
I used to think it was due to the "unkeyed bridge" concept, where we don't specify
a digest and leave the or_conn with a digest of 000..000 for a while at the start.
But now I'm not so sure; I think I've seen this in cases where we specify the
digest when configuring the bridge too.
This bug has been around since 0.2.0.7-alpha or so. It appears harmless, but still
worth fixing sometime.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/583should load fallback consensus before fetching certs2020-06-13T13:59:10ZRoger Dingledineshould load fallback consensus before fetching certsCurrently we notice we're missing certs for our hardcoded authorities, and
launch directory requests to an authority for them. *Then* we load the
fallback consensus.
Should we load the fallback consensus earlier, and that way we ask dir...Currently we notice we're missing certs for our hardcoded authorities, and
launch directory requests to an authority for them. *Then* we load the
fallback consensus.
Should we load the fallback consensus earlier, and that way we ask directory
mirrors for the certs?
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/600circuitlist.c:1165 crashing bug2020-06-13T13:59:16Zshamrockcircuitlist.c:1165 crashing bugThe Tonga tor server crashed with:
Feb 04 10:20:36.880 [err] Bug: circuitlist.c:1165: assert_circuit_ok: Assertion !c->onionskin failed; aborting.
OS:
Debian Etch
2.6.18-5-amd64
[Automatically added by flyspray2trac: Operating System: ...The Tonga tor server crashed with:
Feb 04 10:20:36.880 [err] Bug: circuitlist.c:1165: assert_circuit_ok: Assertion !c->onionskin failed; aborting.
OS:
Debian Etch
2.6.18-5-amd64
[Automatically added by flyspray2trac: Operating System: Other]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/601tor ignores ExitNodes even when StrictExitNodes is set2020-06-13T13:59:17ZTractor ignores ExitNodes even when StrictExitNodes is setwin xp sp2, vidalia bundle 0.0.16, tor v0.1.2.19
log shows chosen exits not from the ExitNodes list
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: iarwin xp sp2, vidalia bundle 0.0.16, tor v0.1.2.19
log shows chosen exits not from the ExitNodes list
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: iar0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/607INFO logging is a bit noisy.2020-06-13T13:59:21ZNick MathewsonINFO logging is a bit noisy.Tor logs certain messages a lot more than others. Here are the top ten offenders on peacetime:
1099 info] update_consensus_router_descriptor_downloads(): %d router descriptors downloadable. %d delayed; %d present (%d of those were i...Tor logs certain messages a lot more than others. Here are the top ten offenders on peacetime:
1099 info] update_consensus_router_descriptor_downloads(): %d router descriptors downloadable. %d delayed; %d present (%d of those were in old_routers); %d would_reject; %d wouldnt_use, %d in progress.
1102 info] routerlist_remove_old_routers(): We have %d live routers and %d old router descriptors. At most %d must be retained because of networkstatuses.
1318 info] update_extrainfo_downloads(): Extrainfo download status: %d router with no ei, %d with present ei, %d delaying, %d pending, %d downloadable.
1691 info] connection_close_immediate(): fd %d, type %s, state %s, %d bytes on outbuf.
1787 info] run_connection_housekeeping(): Expiring non-used OR connection to fd %d (%s:%d) [Not in clique mode].
2103 info] directory_handle_command_get(): Client asked for network status lists, but we've been writing too many bytes lately. Sending 503 Dir busy.
5037 info] entry_guards_compute_status(): Summary: Entry '%s' is %s, %s%s, and %s.
10352 info] directory_handle_command_get(): Client asked for server descriptors, but we've been writing too many bytes lately. Sending 503 Dir busy.
12993 info] circuit_extend(): Next router (%s:%d) not connected. Connecting.
15849 info] connection_read_to_buf(): tls error [%s]. breaking (nickname %s, address %s).
This is out of around 60k messages of severity INFO or higher; the top 4 account for 3/4 of all log messages.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/612tor needs to perform a dir request whenever starting as a server?2020-06-13T13:59:23ZRobert Hogantor needs to perform a dir request whenever starting as a server?[11:54] <mwenge> tor can no longer guess my ip address, so it never builds a desc_routerinfo - which causes all kinds of havoc
[11:56] <mwenge> i'm using trunk
[12:01] <mwenge> it's failing to guess mine completely: tries to figure it ou...[11:54] <mwenge> tor can no longer guess my ip address, so it never builds a desc_routerinfo - which causes all kinds of havoc
[11:56] <mwenge> i'm using trunk
[12:01] <mwenge> it's failing to guess mine completely: tries to figure it out from hostname, then finds the internal address, then says neither of those will do and gives up
[12:02] <mwenge> because it gets nothing from router_pick_published_address it doesn't get past go in router_rebuild_descriptor
[12:02] <mwenge> this results in it failing to assign desc_routerinfo
[12:02] <mwenge> so if i then do a getinfo dir/server/fp/ on my own server fingerprint - I get a segfault
[12:03] <mwenge> because desc_routerinfo doesn't exist and tor's assuming one exists
[12:03] <mwenge> this solves the segfault: http://pastebin.ca/914977
[12:04] <mwenge> but the real problem is failing to guess the ip
[12:05] <mwenge> it can only have been introduced recently because i generally use trunk
[12:10] <mwenge> the real problem is probably in router_guess_address_from_dir_headers somewhere
[12:16] <karsten> mwenge: sry, looking at the commit statements did not reveal (to me) which one changed that behavior.
[12:17] <mwenge> karsten: same here. i think i see the problem. if tor starts and has relatively fresh server info cached it doesn't get an ip from the dir servers until the next time it requests something
[12:17] <mwenge> so last_guessed_ip remains 0. and if you run a server your address remains undetermined
[12:20] <mwenge> so it looks as if tor needs to perform a dir request when starting at all times
[12:20] <mwenge> or else cache x-your-address on file - which seems a bad idea
[12:22] <mwenge> yup. rm -rf cache- and restarting tor gets last_guessed_ip populated again
[12:22] <mwenge> just restarting tor with clearing the cache results it in remaining 0
sorry for the straight paste - i'm lazy
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/619exit-policy-reject-star relays should refuse dns?2020-06-13T13:59:25ZRoger Dingledineexit-policy-reject-star relays should refuse dns?lodger points out that non-exit relays could reject dns and reverse dns
attempts. (Currently clients try not to ask them any questions, but the
relays don't enforce it. Non-exit relays might be surprised at the dns
requests they are forc...lodger points out that non-exit relays could reject dns and reverse dns
attempts. (Currently clients try not to ask them any questions, but the
relays don't enforce it. Non-exit relays might be surprised at the dns
requests they are forced to do. "also permit reverse resolve for private
addresses, which could lead to leaks of names, in normal circumstances,
only available locally."
Here's his patch:
--- dns.c Tue Feb 26 19:56:28 2008
+++ dns.c Sat Mar 8 12:11:34 2008
@@ -550,7 +550,12 @@
char *hostname = NULL;
is_resolve = exitconn->_base.purpose == EXIT_PURPOSE_RESOLVE;
- r = dns_resolve_impl(exitconn, is_resolve, oncirc, &hostname);
+ routerinfo_t *me = router_get_my_routerinfo();
+ if (is_resolve && me &&
+ policy_is_reject_star(me->exit_policy)) /* non-exit */
+ r = -1;
+ else
+ r = dns_resolve_impl(exitconn, is_resolve, oncirc, &hostname);
switch (r) {
case 1:
/* We got an answer without a lookup -- either the answer was
@@ -659,9 +664,12 @@
* .in-addr.arpa address but this isn't a resolve request, kill the
* connection.
*/
- if ((r = parse_inaddr_arpa_address(exitconn->_base.address, NULL)) != 0) {
- if (r == 1)
+ if ((r = parse_inaddr_arpa_address(exitconn->_base.address, &in)) != 0) {
+ if (r == 1) {
is_reverse = 1;
+ if (is_internal_IP(ntohl(in.s_addr), 0)) /* internal address */
+ return -1;
+ }
if (!is_reverse || !is_resolve) {
if (!is_reverse)
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/622Tor 0.2.1.0-alpha-dev (r13924): 100% CPU usage: conn_read_callback(): socket ...2020-06-13T13:59:27ZTracTor 0.2.1.0-alpha-dev (r13924): 100% CPU usage: conn_read_callback(): socket 340 wants to read.I run 0.2.1.0-alpha-dev (r13924) with Linux 2.6.24.3 x86_64, libevent-1.3d + epoll, openssl latest cvs.
I have not noticed this problem with v0.1.* tor.
I noticed 100% CPU usage (for one CPU out of two :) ) and enabled debug:
[debug] co...I run 0.2.1.0-alpha-dev (r13924) with Linux 2.6.24.3 x86_64, libevent-1.3d + epoll, openssl latest cvs.
I have not noticed this problem with v0.1.* tor.
I noticed 100% CPU usage (for one CPU out of two :) ) and enabled debug:
[debug] conn_read_callback(): socket 34 wants to read.
Around 21000 of these per second.
This lasted for several minutes.
Tor started hahaving OK all by itself before I had time to do much, except for oprofile,
but this would probably be obvious also from the debug line.
CPU: P4 / Xeon, speed 2797.2 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 240000
Counted MACHINE_CLEAR events (cycles with entire machine pipeline cleared) with a unit mask of 0x01 (count a portion of cycles the machine is cleared for any cause) count 12000
Counted FSB_DATA_ACTIVITY events (DRDY or DBSY events on the front side bus) with a unit mask of 0x03 (multiple flags) count 60000
Counted RETIRED_BRANCH_TYPE events (retired branches, selected by type) with a unit mask of 0x1f (multiple flags) count 180000
Counted RETIRED_MISPRED_BRANCH_TYPE events (retired mispredicted branched, selected by type) with a unit mask of 0x1f (multiple flags) count 6000
samples % samples % samples % samples % samples % image name symbol name
18142 10.9848 194 11.7150 40 2.1882 3891 11.3477 4608 24.4158 tor-0.2.1.0-r13924 connection_handle_read
18020 10.9109 164 9.9034 26 1.4223 4022 11.7297 3166 16.7753 tor-0.2.1.0-r13924 conn_read_callback
17185 10.4053 180 10.8696 38 2.0788 6272 18.2916 123 0.6517 tor-0.2.1.0-r13924 assert_connection_ok
12498 7.5674 95 5.7367 9 0.4923 1734 5.0570 72 0.3815 tor-0.2.1.0-r13924 tor_tls_get_error
11508 6.9680 94 5.6763 48 2.6258 3249 9.4753 46 0.2437 tor-0.2.1.0-r13924 assert_buf_ok
10444 6.3237 106 6.4010 23 1.2582 2296 6.6960 551 2.9195 tor-0.2.1.0-r13924 _openssl_locking_cb
9895 5.9913 83 5.0121 11 0.6018 1535 4.4767 38 0.2013 tor-0.2.1.0-r13924 connection_bucket_round_robin
9292 5.6262 89 5.3744 3 0.1641 1694 4.9404 3047 16.1448 tor-0.2.1.0-r13924 tor_tls_renegotiate
8628 5.2242 99 5.9783 17 0.9300 879 2.5635 166 0.8796 [vdso] (tgid:19150 range:0x7fffe7ffe000-0x7fffe8000000) (no symbols)
6003 3.6347 60 3.6232 16 0.8753 184 0.5366 6 0.0318 tor-0.2.1.0-r13924 buf_datalen
4633 2.8052 64 3.8647 751 41.0832 330 0.9624 27 0.1431 tor-0.2.1.0-r13924 router_get_by_nickname
4375 2.6490 41 2.4758 3 0.1641 775 2.2602 8 0.0424 tor-0.2.1.0-r13924 tor_mutex_acquire
4128 2.4995 39 2.3551 3 0.1641 267 0.7787 8 0.0424 tor-0.2.1.0-r13924 tor_mutex_release
4103 2.4843 40 2.4155 0 0 771 2.2485 4500 23.8436 tor-0.2.1.0-r13924 connection_tls_continue_handshake
2698 1.6336 33 1.9928 8 0.4376 511 1.4903 11 0.0583 tor-0.2.1.0-r13924 connection_process_inbuf
2303 1.3944 38 2.2947 7 0.3829 1113 3.2459 15 0.0795 tor-0.2.1.0-r13924 tor_addr_is_internal
2068 1.2521 18 1.0870 4 0.2188 484 1.4115 12 0.0636 tor-0.2.1.0-r13924 connection_is_listener
1699 1.0287 16 0.9662 48 2.6258 102 0.2975 65 0.3444 tor-0.2.1.0-r13924 rijndaelEncrypt
1618 0.9797 14 0.8454 8 0.4376 598 1.7440 6 0.0318 tor-0.2.1.0-r13924 connection_counts_as_relayed_traffic
1615 0.9779 15 0.9058 5 0.2735 151 0.4404 82 0.4345 tor-0.2.1.0-r13924 logv
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: Safari0.2.0.x-final