why my exit is not being used?
Hello I ran sorrentini [1] as a relay for a month or two and everything was fine. then 2-3 weeks ago i decided to allow exit, the traffic went down significantly, is that expected? it has recovered a bit but i feel the node is underutilized, is it stational? I've attached node's munin graphs [1] https://atlas.torproject.org/#details/5E762A58B1F7FF92E791A1EA4F18695CAC6677... here is my torrc # general Nickname sorrentini Log notice syslog ControlPort 9051 HashedControlPassword XXXXXXXXX AccountingStart month 01 00:00 AccountingRule sum AccountingMax 1024GB ContactInfo 0x44BB1BA79F6C6333 <tor-admin AT zumbi dot com dot ar> MyFamily 82C92FBAF2196EC346670D12BB9650FE9FF55741,EFD2EEB91E5C5D8CB999B1EC68D89E51F8776AC7 SocksPort 0 SocksPolicy reject * ## IPv4 ORPort 128.199.76.145:443 DirPort 128.199.76.145:80 Address 128.199.76.145 OutboundBindAddress 128.199.76.145 ##IPv6 IPv6Exit 1 ORPort [2400:6180:0:d0::18a7:d001]:443 OutboundBindAddress [2400:6180:0:d0::18a7:d001] # Exit DirPortFrontPage /etc/tor/tor-exit-notice.html CellStatistics 1 DirReqStatistics 1 EntryStatistics 1 ExitPortStatistics 1 ExtraInfoStatistics 1 HiddenServiceStatistics 1 ExitRelay 1 ExitPolicy accept *:53 # DNS ExitPolicy accept *:80 # HTTP ExitPolicy accept *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:873 # rsync ExitPolicy accept *:989-990 # FTPS ExitPolicy accept *:991 # NAS Usenet ExitPolicy accept *:992 # TELNETS ExitPolicy accept *:993 # IMAPS ExitPolicy accept *:995 # POP3S ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1293 # IPSec ExitPolicy accept *:3690 # SVN Subversion ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:5222-5223 # XMPP, XMPP SSL ExitPolicy accept *:5228 # Android Market ExitPolicy accept *:9418 # git ExitPolicy accept *:11371 # OpenPGP hkp ExitPolicy accept *:64738 # Mumble ExitPolicy reject *:* # nothing else is allowed -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: https://keybase.io/gfa
Hi, Please send us your actual torrc: * your torrc has a DirPort, but your relay on atlas does not (this might be because you have a bandwidth limit set) * your torrc says IPv6Exit, but your relay on atlas does not exit to IPv6 Since you have AccountingMax set, please send us any bandwidth-related log entries. Any more warning or notice log entries would also help, particularly those related to reachability. Most likely, your relay has simply used 1024GB this month. Tim
T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On Mon, Jan 30, 2017 at 12:03:40PM +1100, teor wrote:
Hi,
Please send us your actual torrc:
that's my actual torrc, I've only edited HashedControlPassword
Port is open, tor is listening. no fw rules for IPv6 $ telnet 2400:6180:0:d0::18a7:d001 443 (from a different computer) Trying 2400:6180:0:d0::18a7:d001... Connected to 2400:6180:0:d0::18a7:d001. Escape character is '^]'. ^] telnet> quit Connection closed. # ss -putan |grep 443 |grep LISTEN tcp LISTEN 0 20480 128.199.76.145:443 *:* users:(("tor",pid=10809,fd=7)) tcp LISTEN 0 20480 2400:6180:0:d0::18a7:d001:443 :::* users:(("tor",pid=10809,fd=8))
Since you have AccountingMax set, please send us any bandwidth-related log entries.
arm says i've used 106+107 GB After increasing the loglevel to info and reloading I got this on the log Heartbeat: Accounting enabled. Sent: 104.75 GB, Received: 104.44 GB, Used: 209.22 GB / 1024.00 GB, Rule: sum. The current accounting interval ends on 2017-02-01 00:00:00, in 2 days 2:30 hours.
Any more warning or notice log entries would also help, particularly those related to reachability.
Jan 21 03:29:33 tor-exit1-1480471271410-512mb-sgp1-01 Tor[10809]: Now checking whether ORPort 128.199.76.145:443 and DirPort 128.199.76.145:80 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Jan 21 03:29:34 tor-exit1-1480471271410-512mb-sgp1-01 Tor[10809]: Self-testing indicates your DirPort is reachable from the outside. Excellent. Jan 21 03:29:37 tor-exit1-1480471271410-512mb-sgp1-01 Tor[10809]: Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. After increase loglevel to info, I found this in the logs, it looks harmless but I'm not sure Tor[10809]: connection_dir_client_reached_eof(): Received http status code 404 ("Not found") from server '128.31.0.34:9131' while fetching "/tor/server/d/0BD4536404AA42D4892848293B002A64459940BA+120D89A44DA007434669F18A89C170E4A31A07C3.z". I'll try again soon. Tor[10809]: connection_dir_client_reached_eof(): Received server info (size 0) from server '128.31.0.34:9131'
Most likely, your relay has simply used 1024GB this month.
top iptables rule Chain INPUT (policy ACCEPT 314K packets, 267M bytes) pkts bytes target prot opt in out source destination 339M 289G sshguard all -- * * 0.0.0.0/0 0.0.0.0/0 I don't check daily, but when I check, tor never has more than 300 open connections I've increased the loglevel to info, hopefully it will catch more info in the coming month Any other check I can run? thanks :)
-- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: https://keybase.io/gfa
Then please reload your torrc so that your tor process is using it.
That's the ORPort, an entry port. You say you have IPv6Exit and an ExitPolicy set in the torrc. But your relay does not exit to IPv6, both atlas (IPv6 Exit Policy Summary) and your relay's descriptor (ipv6-policy) show that it does not allow any IPv6 ports: https://atlas.torproject.org/#details/5E762A58B1F7FF92E791A1EA4F18695CAC6677... (large file) https://collector.torproject.org/recent/relay-descriptors/server-descriptors... Either that, or there is a bug in Tor relating to IPv6 Exit policies. But I can't see anywhere in the code that makes the IPv6 exit policy dependent on anything except ExitPolicy and IPv6Exit. Are there any log entries relating to IPv6 or exit policies?
OK, so the accounting limits are not the issue.
And the IPv4 entry address works. ...
I don't check daily, but when I check, tor never has more than 300 open connections ...
Does your kernel, config, VPS, or provider place a limit on the number of connections? (Search the list archives for detailed troubleshooting steps for this.) Your relay also does not seem capable of handling much tor traffic, so tor clients are being told not to use it: (large page) https://consensus-health.torproject.org/consensus-health-2017-01-30-02-00.ht... T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On Mon, 30 Jan 2017 15:12:46 +1100 teor <teor2345@gmail.com> wrote:
Your relay also does not seem capable of handling much tor traffic, so tor clients are being told not to use it:
That's the usual problem of relays in Asia (Singapore in this case), with all the bandwidth measuring authority servers being too far away from there. -- With respect, Roman
On Mon, Jan 30, 2017 at 10:12:01AM +0500, Roman Mamedov wrote:
Would make sense then to run another tor instance in the same server? a non-exit relay. To make a better use of the allocated bandwidth
-- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: https://keybase.io/gfa
On Mon, 30 Jan 2017 23:46:31 +0800 "gustavo panizzo (gfa)" <gfa@zumbi.com.ar> wrote:
Would make sense then to run another tor instance in the same server?
It nearly always does (unless on just a single very slow CPU core), so yes. Although you might start running out of RAM if you run that on a 512 MB droplet.
a non-exit relay.
Doesn't matter, if the first one is exit, the 2nd one can be an exit too. -- With respect, Roman
On Mon, Jan 30, 2017 at 03:12:46PM +1100, teor wrote:
What I meant to say is that I edited HashedControlPassword on the email
You are right, tor wasn't listening on the DirPort on IPv6. I've fixed that a few hours ago.
You say you have IPv6Exit and an ExitPolicy set in the torrc.
I have exit rules for both, same rules apply to both protocols. An tor knows it Tor[22587]: tor_addr_parse_mask_ports(): '*:6881-6999' expands into rules which apply to all IPv4 and IPv6 addresses. (Use accept/reject *4:* for IPv4 or accept[6]/reject[6] *6:* for IPv6.) Tor[22587]: tor_addr_parse_mask_ports(): '*:*' expands into rules which apply to all IPv4 and IPv6 addresses. (Use accept/reject *4:* for IPv4 or accept[6]/reject[6] *6:* for IPv6.)
See above [...snip...]
Does your kernel, config, VPS, or provider place a limit on the number of connections?
Yes, when the relay was a non-exit relay it used to have more connections I'll play with sysctl to see if I can get the number to go up
I will read it and try to make sense out of it, I'm a sysadmin but I only have a few months of running tor experience. thanks for your responses, I'll check the links you provided now that IPv6 DirPort is working, although it shouldn't make much difference as most of the world is still using IPv4 -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: https://keybase.io/gfa
What I need to know is whether the torrc you provided is actually the one being used by tor.
No tor version or role uses the IPv6 DirPort, and it's a pain to configure.
But if your ExitPolicy starts by rejecting IPv6 (as it does when IPv6Exit is not set), none of these rules will ever be used.
Your relay still does not exit to IPv6. This looks like it might be a tor bug, we're looking into it. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On Tue, Jan 31, 2017 at 09:27:42AM +1100, teor wrote:
yes, the file provided is the one being used by tor
is this useless then? DirPort [2400:6180:0:d0::18a7:d001]:80 NoAdvertise
# grep -i exit /etc/tor/torrc IPv6Exit 1 ExitPortStatistics 1 ExitRelay 1 ExitPolicy accept *:53 # DNS ExitPolicy accept *:80 # HTTP ExitPolicy accept *:110 # POP3 [snip] ExitPolicy reject *:* # nothing else is allowed
IPv6Exit is set -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: https://keybase.io/gfa
tldr: would you send me your torrc if you aim to route IPv6 exit traffic and are in the list at the bottom with the third colmn set to NULL? teor:
moritz@torservers.net did sent me (unfortunately off-list) the torrc file for https://atlas.torproject.org/#details/FDAED15C98CFE7A416E5676F614254F7840610... according to his torrc it is allowing IPv6 exit traffic but not according to its descriptor. Do exits do any outbound IPv6 reachability test before they create their descriptor? (with the ipv6-policy entry) In total there are currently 57 exits with an IPv6 ORPort but no IPv6 exit policy. That on its own doesn't mean anything because they might not set IPv6Exit to 1 but the big picture looks a bit odd. Here is a (truncated) list of exits which have IPv6 connectivity (ORPort) and their respective v6 exit policy (the last column) since the v6 policy changes between none (NULL) to non-NULL even within the same operator this seems strange. Usually an operator uses highly identical torrc files across all their relays. If you are on the this list with a NULL value in the v6_policy column and your torrc contains IPv6Exit 1 we'd be interested to see your complete torrc files (do not forget to _remove_ any sensitive lines like HashedControlPassword). I also had a look at the tor_version column but there was no correlation there. That said there _is_ a correlation with as_name, so maybe this not a bug but operators only enabling IPv6 exiting on specific hosters (which seems strange because I only list IPv6 enabled relays). For example Frenn vun der Enn has no IPv6 exit policy only with the relays in the BENESTRA AS. +----------+------------------------------------------+-----------+ | nick | contact | v6_policy | +----------+------------------------------------------+-----------+ | ori | 0x02225522 Frenn vun der Enn (FVDE) <inf | NULL | | tollana | 0x02225522 Frenn vun der Enn (FVDE) <inf | NULL | | kree | 0x02225522 Frenn vun der Enn (FVDE) <inf | NULL | | orion | 0x02225522 Frenn vun der Enn (FVDE) <inf | {u'reject | | aurora | 0x02225522 Frenn vun der Enn (FVDE) <inf | {u'reject | | destiny | 0x02225522 Frenn vun der Enn (FVDE) <inf | {u'reject | | chulak | 0x02225522 Frenn vun der Enn (FVDE) <inf | {u'reject | | rejozeng | 0x21DBEFD4 Rejo Zenger <rejo@zenger.nl> | NULL | | torinitl | 0x36AC3365 Ludost TOR <tor AT ludost DOT | {u'reject | | Unnamed | 0x3C68C8DBCBA783EF Joel R. Voss <jvoss a | NULL | | sorrenti | 0x44BB1BA79F6C6333 <tor-admin AT zumbi d | NULL | | torpinkb | 0x60C0742D1F357D42 Sergey Popov <admin+t | NULL | | partyvan | 0x989971B2A6B7AF4B WubTheCaptain <wub@pa | {u'accept | | marylou2 | 0x9F29C15D42A8B6F3 Nos oignons <adminsys | NULL | | ekumen | 0x9F29C15D42A8B6F3 Nos oignons <adminsys | NULL | | marylou1 | 0x9F29C15D42A8B6F3 Nos oignons <adminsys | NULL | | armbrust | 0xBA61EB09 Michael Armbruster <tor@armbr | NULL | | AlphaCen | 0xD3364A0B Spydar007 <tor.abuse@spydar00 | NULL | | Unzane | 0xFDB8716D Gerald Turner <gturner@unzane | NULL | | NormalCi | 1HDWeYX59Ayp3x8dAUWcpyUeTXEDwrh7vD | {u'accept | | modio | < spider AT modio dot SE> | {u'accept | | thisisat | <abuse .AT. uk .DOT. aql . DOT . com > | {u'accept | | thirdexi | <demfloro AT demfloro dot ru> - 1Jowqcwd | NULL | | dredis | <demfloro AT demfloro dot ru> - 1Jowqcwd | NULL | | bsdexit | <demfloro AT demfloro dot ru> - 1Jowqcwd | {u'accept | | modio1 | <take AT modio dot se> | NULL | | thisisat | Abuse <abuse .AT. uk .DOT. aql . DOT . c | NULL | | xshells | Admin <admin AT xshells DOT net> | NULL | | AquaRayT | Aqua Ray Tor Operators <tor-operators-fr | {u'accept | | BabylonN | Babylon Network | noc <AT> babylon <DOT> | NULL | | BabylonN | Babylon Network | noc <AT> babylon <DOT> | NULL | | BabylonN | Babylon Network | noc <AT> babylon <DOT> | NULL | | BabylonN | Babylon Network | noc <AT> babylon <DOT> | NULL | | blackpea | BlackPearl <tor-op(at)wach-it-solutions. | {u'accept | | CrashM | CrashM <crash AT crashm d0t co DoT uk> | NULL | | digineo3 | Digineo GmbH <tor AT digineo dot de> | {u'accept | | Sentries | echo gbeznfgre1609@fragevrf.bet | rot13 | NULL | | Sentries | echo gbeznfgre1609@fragevrf.bet | rot13 | NULL | | TastyStr | Fabian Bakkum <fabianbakkum@hotmail.com> | NULL | | liskov0 | gmail is teor2345 | http://tor-relays.ne | {u'accept | | kramse | Henrik Kramshoej <hlk AT zencurity dot d | NULL | | w000000h | http://torexitnodev6.dynv6.net | NULL | | critical | https://www.torservers.net/donate.html < | NULL | | zwiebelf | https://www.torservers.net/donate.html < | NULL | | zwiebelf | https://www.torservers.net/donate.html < | NULL | | dorrisde | https://www.torservers.net/donate.html < | NULL | | russellt | https://www.torservers.net/donate.html < | NULL | | zwiebelf | https://www.torservers.net/donate.html < | NULL | | amazonas | https://www.torservers.net/donate.html < | {u'reject | | UnivOfPA | Jacob Henner <tor-exit at lists (dot) se | {u'accept | | yuicat2 | Jordan <jordan@yui.cat> | {u'accept | | NeelTorE | Neel Chauhan <neel AT neelc DOT org> | B | NULL | | NeelTorE | Neel Chauhan <neel AT neelc DOT org> | B | NULL | | NeelTorE | Neel Chauhan <neel AT neelc DOT org> | B | {u'accept | | lupine | Nick Thomas <tor@ur.gs> | NULL | | Unnamed | Random Person <tor0102.10.swsnyder AT sp | NULL | | Unnamed | Random Person <tor0102.10.swsnyder AT sp | NULL | | Unnamed | Random Person <tor0102.10.swsnyder AT sp | {u'accept | | Unnamed | Random Person <tor0102.10.swsnyder AT sp | {u'accept | | Unnamed | Random Person <tor0102.10.swsnyder AT sp | {u'accept | | zwiebelt | replace k with c : kontakt @ zwiebeltora | NULL | | artikel5 | see https://www.artikel5ev.de/torcontact | NULL | | artikel5 | see https://www.artikel5ev.de/torcontact | NULL | | artikel5 | see https://www.artikel5ev.de/torcontact | NULL | | artikel5 | see https://www.artikel5ev.de/torcontact | NULL | | Universi | System Administrators <sysadmin@galileo. | NULL | | corewars | TOR Administrator <tor AT corewars dot n | NULL | | cowcat | tor-relays@coldhak.ca | NULL | | chaucer | tor-relays@coldhak.ca | NULL | | manipogo | tor-relays@coldhak.ca | NULL | | starfish | tor-relays@coldhak.ca | NULL | | snowfall | tor-relays@coldhak.ca | NULL | | prawksi | tor-relays@coldhak.ca | NULL | | ogopogo | tor-relays@coldhak.ca | NULL | | tordiene | tor@die.net | NULL | | PrivacyE | tor@lite.litedsl.nl | NULL | | torwedos | Viktor <vnikolov AT vnikolov dot cz> | NULL | | torwedos | Viktor <vnikolov AT vnikolov dot cz> | NULL | +----------+------------------------------------------+-----------+
nusenu:
tldr: would you send me your torrc if you aim to route IPv6 exit traffic and are in the list at the bottom with the third colmn set to NULL?
Since I'm getting off-list replies with torrc files now: Please let me know whether you are OK with me pasting your entire torrc into a trac ticket (aka publishing it). Also: Please confirm that you are able to do outbound IPv6 connections from your relay. thanks!
Here are the log entries I'd like to see: Any bug warnings warnings: Exit policy '%s' and all following policies are redundant Weird family when summarizing address policy policy_dump_to_string ran out of room info: Unrecognized policy summary keyword Impossibly long policy summary Found bad entry in policy summary Found no port-range entries in summary debug: Adding new entry Ignored policy Adding a reject ExitPolicy Removing exit policy
No, there is no IPv6 reachability testing in Tor for anything, except for authorities checking IPv6 ORPorts. But tor does automatically reject configured ports and addresses. (In 0.2.7 and 0.2.8, it does this with local interface addresses, in 0.2.9, it only does this with local interfaces if ExitPolicyRejectLocalInterfaces is set. In all versions, it does this with private addresses and configured ports by default.) So one thing that operators could do is try to disable the IPv6 ORPort and the OutboundBindAddress, and see if that helps. Operators could also tweak ExitPolicyRejectLocalInterfaces and ExitPolicyRejectPrivate. Turning off ExitPolicyRejectPrivate can make an exit insecure, so it should be done after blocking all traffic from the exit on private addresses using a firewall.
Some providers may require certain port configurations, which could cause the issue.
...
T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
teor:
Here are the log entries I'd like to see:
Does tor log any warning if IPv6Exit is set to 1 and the resulting descriptor will not contain any ipv6-policy line? If that is not the case then this might makes sense to add such a log entry because it would help the operator to understand that his intention (IPv6Exit 1) is not achieved - for whatever reason. If this is indeed a bug then you might get some reports with such a warning message in the logfile (at least from operators looking at their logs).
Ok, so there are no requirements beyond ExitPolicy + IPv6Exit. So a relay without IPv6 connectivity could also get an ipv6-policy line into his descriptor to test this.
Do you mean physical port configuration? Since they have an IPv6 ORPort their IPv6 (inbound) connectivity should be working I guess.
https://trac.torproject.org/projects/tor/ticket/21355
Yes, Exits can lie about having connectivity, and they will (eventually) get the BadExit flag when they refuse too many connections by our scanners. But I don't know whether we check IPv6.
Not quite, I mean IP addresses listed in the torrc, and addresses on the local machine's interfaces. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
If there is a bug, this is a potential list of victims (exits with ORPort on IPv6 and no ipv6-policy): https://gist.githubusercontent.com/nusenu/1534d210049fcb04919ae5a4529ea894/r... Three of them have IPv6Exit set to 1 (see end of the line).
nusenu:
tldr: would you send me your torrc if you aim to route IPv6 exit traffic and are in the list at the bottom with the third colmn set to NULL?
instead of sending it to me you can add it to the trac entry: (no account needed) https://trac.torproject.org/projects/tor/ticket/21357
We think we have fixed this bug in master. You can help us get it backported to 0.3.0 and 0.2.9 by testing tor master (or tor nightlies if your packager build them) on your IPv6 Exit. Please let us know if it works! Also, please look for any "bug" warnings in your logs. Thanks! (I originally posted this message to tor-dev by mistake.)
T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On Thu, Feb 02, 2017 at 11:05:23AM +1100, teor wrote:
works for me https://atlas.torproject.org/#details/5E762A58B1F7FF92E791A1EA4F18695CAC6677... i'm using tor 0.3.0.2-alpha-dev-20170201T205811Z-1~d80.jessie+1 thanks -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 keybase: https://keybase.io/gfa
Hi, I added a few IPv6 related stats to OrNetStats one of them gives you a list of exits that have an IPv6 ORPort but do not allow IPv6 exiting, lets make this list shorter ;) https://github.com/ornetstats/stats#ipv6-relay-stats https://github.com/ornetstats/stats/blob/master/o/non-IPv6_Exits_with_IPv6_O... If you are on this list: Make sure you run tor version >=0.2.9.10/>=0.3.0.3-alpha and have 'IPv6Exit 1' in your torrc. thanks for running (IPv6) exits! nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_ nusenu:
On 2017-04-05 at 01:00, nusenu wrote:
Hi, I was on this list and thought I definitely would not find me there :D Updated Tor to 0.2.9.10 now (had some problems unfortunately due to some changes with the latest systemd and how it seems to handle capabilities now, the Arch Linux packages does not work anymore out of the box, I have to manually comment out the "User=tor" line in the systemd service file and instead use the "User" directive in the torrc file, but ok). I hope this works now. "IPv6Exit 1" is set and hopefully, everything works (at least in an hour after the next consensus is published). Feel free to shoot me a message again if that's not the case. I used the opportunity to change my contact details to a longer PGP key id to not rely on those unsecure 32-bit ids anymore. Best, Michael
On Tue, 4 Apr 2017, nusenu wrote:
I am on this list. I just updated from 0.2.9.9 to 0.2.9.10 and already had "IPv6Exit 1" in my torrc. -- Aaron
Aaron Hopkins:
Hi Aaron, thanks for looking into this, unfortunately you IPv6 exit summary is still empty, what does your exit policy look like? https://atlas.torproject.org/#details/CB2BEB364E07CF431819F6C5349555425C60C6...
participants (7)
-
Aaron Hopkins -
gustavo panizzo -
gustavo panizzo (gfa)
-
Michael Armbruster -
nusenu -
Roman Mamedov -
teor