Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:28:47Zhttps://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/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/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/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/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/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/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/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/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/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-final