Re: [tor-relays] IPv6 reachability tests fail on CenturyLink IPv6 6rd - reachability broken?
Neel Chauhan wrote Thu, 26 Aug 2021 21:16:20 -0700: > Aug 26 18:47:01.000 [notice] Auto-discovered IPv6 address > [REDACTED]:143 has not been found reachable. However, IPv4 address is > reachable. Publishing server descriptor without IPv6 address. > Aug 26 19:47:01.000 [notice] Auto-discovered IPv6 address > [REDACTED]:143 has not been found reachable. However, IPv4 address is > reachable. Publishing server descriptor without IPv6 address. [2 > similar message(s) suppressed in last 2400 seconds] What IPv6 address(es) are your relays using? You can grep for 'Open.* OR listener' in the log files to figure out what tor tries and succeeds with. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Fallback directory mirror DFRI7 is dead
Hi teor, Fallback directory mirror DFRI7 [0] is down, due to multiple disk krashes, since about 30h and will not come alive with the same key. [0] 171.25.193.131:80 orport=443 id=79861CF8522FC637EF046F7688F5289E49D94576 A new DFRI7 will appear on the same address and port within a couple of days. Should I simply update fallback_dirs.inc? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bwauth in testing
Tom Ritter wrote Wed, 16 Aug 2017 15:06:55 -0500: > The good news is that my bwauth measured you at 75600, which is a bit > below the other two measurements, but in line with them. So once > maatuska starts voting on this data you'll be popped back up. maatuska is now voting on bandwidth measurement data from Tom's bwauth. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Please enable IPv6 on your relay!
nusenu wrote Sat, 16 May 2015 08:26:19 +: | Since clients are not able to bootstrap over IPv6 yet: | | https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6 : | > Directory authorities on IPv6 | > | > Clients and relays talk to directory authorities. The work with | > making directory authorities reachable over IPv6 has not been | > started. | > | > This work will be tracked in #6027. [1] | | | Does that mean that IPv6 non-exits are not very useful yet? They're useful for clients configuring them as bridges (guards). ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Drop in relay count
nusenu wrote Sun, 03 May 2015 19:06:39 +: | > Looking at the graphs showing the total relay bandwidth of the | > network it seems like the advertised bandwidth has increased with | > about 25 Mbps (+23%). | | I doubt that 25 Mpbs is 23% of the tor network capacity, I guess it | should say GBit/s. Indeed. | You probably also know about the 0.2.3.x relays: | https://metrics.torproject.org/versions.html I didn't. Thanks. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Drop in relay count
"Steve Snyder" wrote Sun, 3 May 2015 10:40:59 -0400 (EDT): | My uninformed guess would be that the higher minimum bandwidth requirements in v0.2.6.x forced out the marginal relays. Interesting. I'll see if I can find out when a majority of directory authorities upgraded to 0.2.6.x. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Drop in relay count
Hi, Looking at the graphs showing the number of relays in the network it seems like we've lost about 500 (-7%) relays since the beginning of this year. https://metrics.torproject.org/networksize.html?graph=networksize&start=2015-01-01&end=2015-05-03 https://metrics.torproject.org/networksize.html?graph=networksize&start=2012-01-01&end=2015-05-03 Looking at the graphs showing the total relay bandwidth of the network it seems like the advertised bandwidth has increased with about 25 Mbps (+23%). https://metrics.torproject.org/bandwidth.html?graph=bandwidth&start=2015-01-01&end=2015-05-03 https://metrics.torproject.org/bandwidth.html?graph=bandwidth&start=2012-01-01&end=2015-05-03 Seems a bit contradictory at first sight. A guess would be that a lower number of fast relays have replaced a higher number of slow ones but I haven't looked into it more. Anyone who's looked into this? And can back up their theory with some numbers. Thanks, Linus ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Legal situation of tor in Europe
Moritz Bartl wrote Thu, 12 Mar 2015 09:58:00 +0100: | >>> I mean the only reason, why there is more Tor-Exit-IPs | in the abuse log than any other single unique IP is that there is tens | of thousand of users using each Tor-Exit. | >> If this claim could be substantiated by some numbers it'd certainly help. | > I fully agree to that, it would be helpful to get some more analytic | > data like this. Not necessarily on my exit, but some general numbers, | > some facts. | > I just assumed that number above, but actually have no idea. | | Nobody does. We don't have figures from other ISPs or larger carries to | compare with either. Just from conversations with ISPs and VPN | providers, we don't see more abuse than they do. Also, it fully depends | on your definition of abuse (complaints). | | This is (still) a nice research question, and I'm happy to help with a | nice database of complaints. I'm sure other torservers.net operators | would help as well. Obviously one can't simply count the number of | complaints, as you need to take (at least) throughput and exit policy | into account. DFRI would be interested in taking part in such research and should be able to contribute a couple of years worth of data on complaints from running 100-500 Mbps of exit traffic. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Keeping your obfsproxy up to date
Peter Palfrader wrote Thu, 12 Mar 2015 10:19:51 +0100: | There is an obfs4proxy package for Debian and Debian-based systems | deb http://deb.torproject.org/torproject.org obfs4proxy main Oh! obfs4proxy does obfs2 and obfs3 too: https://lists.torproject.org/pipermail/tor-relays/2014-September/005372.html I've been living under a rock for some time, obviously. Thanks! ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Keeping your obfsproxy up to date
Hi list, I just found out that my obfsproxy relays didn't obfsproxy any more. I was apparently running a pretty old version, installed from source. How do you people keep your obfsproxies (and pyptlib) up to date? Are there packages? Is there a list or some other channel where new versions are announced that I'm not paying attention to? Thanks, Linus ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Consensus weight dropped
Karsten Loesing wrote Wed, 21 Jan 2015 13:22:25 +0100: | But here's another graph, specifically for your relay schokomilch: | | https://people.torproject.org/~karsten/volatile/schokomilch-cw-2015-01-21.png | | 14C1 is tor26, 4901 is maatuska, and D586 is moria1. It looks like | maatuska stopped measuring your relay between December 29 and January | 5, which is a general problem with maatuska's scanner, not specific to | your relay, AFAIK. I am the operator of the bandwidth authority reporting to maatuska. This bandwidth authority has had multiple issues since late December but is now making progress towards serving maatuska with measurement data again. This should not have been a big deal, but since two other bw auths apparently have (had) trouble measuring some relays it hurt more than anticipated. Thanks for your patience and time put into digging into this. Thanks for running relays! ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] You relay isn't getting indexed by Authorities?
Dedalo wrote Mon, 12 Jan 2015 16:31:59 -0500: | Some months ago I started running another tor relay (middle relay) and | something happened, My relay wasn't getting indexed by any authority, | neither wasn on atlas. A friend recommended me to make some tests, the | problem was the ISP had blacklisted 6 Authorities, but to figure out | this I had to make some tests... I made a very simple script which tests | if your isp has blacklisted any authority or if you have a problem with | your DNS... What ISP is this? What does a traceroute have to say? Which of the directory authorities did it block? Is it still doing it? | https://github.com/Dedal0/TorAuthoritiesScript | | Just run the script in the vps before you setup a relay to avoid | indexing problems... The script makes a simple test but is efficient in | most of authority cases. Not all networks allow ICMP. Trying to set up a TCP connection to the directory authority dirport would test something that is a bit closer to what is needed for submitting a server descriptor. Thanks for the script and for running a relay. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] eventdns: Address mismatch on received DNS packet.
Jeremy Olexa wrote Sun, 11 Jan 2015 12:00:16 -0600: | Can anyone clarify what the problem may be? Or is it no problem at all? My theory is that this is the result of spurious DNS traffic possibly unrelated to Tor. DNS is a popular DoS-tool these days, for example. See https://trac.torproject.org/projects/tor/ticket/3056 for an abandoned ticket about this. IIUC, libevent is trying to help users (in our case Tor operators) to realise that they've misconfigured their /etc/resolv.conf but I have to admit that I don't understand the case where this logging detects that. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] IPv6 - status
Marcin Gondek wrote
Thu, 11 Sep 2014 16:58:49 +:
| Hi,
|
| What is the current state of IPv6?
|
| ==cut==
| Relays to relays
|
| Relays talk to other relays. The work with relays talking to other
| relays over IPv6 has not been started.
| ==cut==
|
| Is there any plans to start? How I can help?
No plans that I'm aware of. If you know C you can prepare a patch, run
it in a Chutney test network and post it on #4565 [0].
| ==cut==
| Directory authorities on IPv6
|
| Clients and relays talk to directory authorities. The work with making
| directory authorities reachable over IPv6 has not been started.
|
| This work will be tracked in #6027.
| ==cut==
|
| Same as above?
Seems like Nick has a patch, see the ticket.
| Clue is when it will be possible to run pure IPv6 relay/guard.
We need "a substantial amount" of relays being able to make outgoing
IPv6 connections and successfully publishing an IPv6 ORPort before we
can allow relays to publish _only_ an IPv6 ORPort.
For guards, a client connecting over IPv6 needs a large enough set of
guards to choose from. Today that number is 127 [1] (about 8%). What a
large enough set is I don't know, but I'd say we're not there yet.
For middle relays, the anonymity set is limited to the number of guards
with IPv6 connectivity -- only these can connect to IPv6-only middle
relays. This figure is harder to estimate.
For exit relays, the reasoning is similar to the one for middle relays.
[0] https://trac.torproject.org/projects/tor/ticket/4565
[1] cat cached-consensus | awk '/^r /{r=$0; a=""}/^a /{a=$0}/^s .*Guard/{if (a)
print r, a}' | wc -l
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Confirm IPv6 Setup as Exit Node
Adam Brenner wrote Wed, 21 May 2014 22:51:49 -0700: |ORPort 9001 |ORPort [2606:2e00:0:19::4]:9050 |# first line works with IPv4 while second line is supposed to be IPv6 | |IPv6Exit 1 |ExitPolicy accept6 *:*# Allow all IPv6 Requests Very permissive. Thanks! Be aware of an unfortunate effect of how directory authorities vote for relay with an IPv6 ORPort -- if you lose IPv6 connectivity (i.e. a majority of the directory authorities supporting IPv6 can't reach you over IPv6), your relay will be missing from the consensus regardless of your IPv4 status. | I did not specify anything for DirPort as I believe this is not | working under IPv6? Is this correct? That's correct. Thanks for running an IPv6 relay! ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Please need urgent help with the DNS resolver of a fast exit relay
"s...@sky-ip.org" wrote Thu, 24 Apr 2014 19:20:37 +0300: | I get this in the log very often: | Apr 24 15:14:07.000 [notice] Circuit handshake stats since last time: | 91633/91636 TAP, 15962/15962 NTor. | Apr 24 17:40:45.000 [warn] eventdns: All nameservers have failed | Apr 24 17:40:45.000 [notice] eventdns: Nameserver :53 is back up | | Both nameservers fail and come back after 1 second, or less. Are you running this relay on a BSD system, perchance? I see this on lots of relays on FreeBSD and think that it's related to libevent on certain platforms. I also think that it's benign. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 404: /tor/keys/fp-sk/print-print not found
Mateusz Błaszczyk wrote
Sun, 12 Jan 2014 11:11:58 +:
| Jan 12 11:06:42 GMT Tor[36615]: Received http status code 404 ("Not
| found") from server 'xxx:80' while fetching
|
"/tor/keys/fp-sk/E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58-9732F95C0620648332899FD91C6463F827983B17".
Thanks for reporting.
This is dizum with a new signing key as of 2014-01-12 10:18:26 (UTC).
See my previous post in this thread for more information.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 404: /tor/keys/fp-sk/print-print not found
nano wrote
Sun, 12 Jan 2014 13:57:20 +1100:
| I haven't looked into this at all yet, thought I would share it here
| first. Both my exit relays [0] received these repeated warnings around
| the same time yesterday:
|
| timestamp [warn] Received http status code 404 ("Not found") from
| server 'server1IP:port' while fetching
|
"/tor/keys/fp-sk/A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0-A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0".
| timestamp [warn] Received http status code 404 ("Not found") from
| server 'server2IP:port' while fetching
|
"/tor/keys/fp-sk/A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0-A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0".
| timestamp [warn] Received http status code 404 ("Not found") from
| server 'server3IP:port' while fetching
|
"/tor/keys/fp-sk/A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0-A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0".
| timestamp [warn] Received http status code 404 ("Not found") from
| server 'server4IP:port' while fetching
|
"/tor/keys/fp-sk/A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0-A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0".
|
| Only one timestamp and serverIP was consistent on both relays. All
| fingerprints, however, were consistent on both. Hasn't appeared before
| or since. Anything to worry about? Thanks.
Thanks for reporting. This happens when directory authorities switch
signing keys and you shouldn't worry.
My guess is that your fingerprints read
ED03BB616EB2F60BEC80151114BB25CEF515B226-B59F6E99C575113650C99F1C425BA7B20A8C071D
which would be gabelmoo with a new signing key since 2014-01-11 16:26:31
(UTC).
It's actually a bit misleading that you replaced both fingerprints with
the same string. If they are indeed identical, there's something to
worry about.
You will see more of these in the near future as all directory
authorities are switching signing keys before schedule in order to
increase the key size. See
https://people.torproject.org/~linus/sign2048.html for the progress on
this. We hope to have moved all authority signing keys to 2048 bits
within a couple of weeks.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Advice on dealing with ISP's response to DMCAtakedownnotice.
Hi, Sounds like you risk ending up with a censorship tool controlled by those who control the list of attack signatures. I'd prefer if we educate service providers about this dangerous place called the internet with the goal of making them turn down the volume on their sirens a notch. t...@t-3.net wrote Wed, 30 Oct 2013 07:56:28 -0400: | What he said. | | No DMCA so far but, one thing I keep getting is complaints about "SQL | injection attacks". Apparently snort or other IDS picks this stuff up | and emails the abuse box. Some but not all of the complaints are | automated. | | It would be nice if something could detect these attack signatures on | the internet-bound packets from our exit node and drop them. With | trends as they are, we'd see zero abuse complaints, if there were a | good way to do that. | | | | | On Wednesday 30/10/2013 at 6:41 am, Moritz Bartl wrote: | > On 25.10.2013 19:13, krishna e bera wrote: | >> | >>> | >>> ExitPolicy accept *:1723 # PPTP | >> How are you getting PPTP to work over Tor? The ISP-supplied modems | >> i've | >> seen won't pass IP protocol 47 (GRE) packets without putting the | >> target | >> machine in a DMZ. | > | > https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy> contains it. | > | > It's more of a "catch all" exit policy, but gets rid of most DMCA | > complaints. | > ___ | > tor-relays mailing list | > tor-relays@lists.torproject.org | > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays | | ___ | tor-relays mailing list | tor-relays@lists.torproject.org | https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Public Munin Graphs: Security Risk?
Moritz Bartl wrote Tue, 29 Jan 2013 16:54:58 +0100: | I finally deployed Munin across our exit nodes. The graphs are currently | public, and I don't see an obvious reason for not doing that. Any | objections? | | https://www.torservers.net/munin/ Thanks, that's interesting data. FWIW, DFRI publish 5 minute average stats per site, for sites where we have exit relays [0][1]. There is a one hour delay in publishing the data. We might switch to per-relay data when our sites with Tor in them push more than 0.1% non Tor traffic or so. On a side note, comparing our graphs with Torservers.net's made us wonder why our relays don't max out at the same time while Torserver.net's apparently do that. Or are we reading the graphs in the wrong way? It looks like the 10 graphs in https://www.torservers.net/munin/torservers.net/aggregates/index.html follow each other very closely while the DFRI graphs show, f.ex., max traffic yesterday in sto0 between 19:00 and 21:30 (CET) but 12:30 to 22:30 (CET) in sto2. It might of course be the case that one or more of our relays have trouble keeping up with the pace. Some of them do complain about not keeping up and others about both failing DNS servers and "Address mismatch on received DNS packet" (eventdns). Log printouts don't seem to correlate with changes in the graphs though so I doubt that this is the reason. [0] https://dfri.se/__trafstats__/em1.100.html [1] https://dfri.se/__trafstats__/em1.3021.html ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Can I enable IPv6?
cmeclax wrote Fri, 25 Jan 2013 00:36:30 -0500: | I just upgraded to version 0.2.3.25 from the latest pkgsrc quarterly, and I | have an IPv6 address. Can I tell other relays that they can connect to me on | IPv6? The port number will be different, as I'm forwarding one port on the | router to a different port on the Tor box. No. The IPv6 support for relays on IPv6 in the 0.2.3 series is limited to bridges. Also, relay to relay over IPv6 is not implemented yet. 0.2.4.8-alpha and later would give you client to relay over IPv6 and exit to IPv6. See https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6 for the details. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] DFRI is running two sponsored exits
Andreas Krey wrote Mon, 26 Nov 2012 17:16:16 +0100: | > We could technically run bridges too but we would have to discuss this | > internally some more first. Do we really want to take money for running | > entry _and_ exit relays? Isn't that exactly how you'd attack Tor users | > if you had the power, by controlling entry and exit? | | You'd be doing so by running entries and exits, and not telling the world | about it, like by putting in the family list. So, I don't see a point in | a single entity not running entries & exits as long as they are declared. The sponsor wants bridges. You're not supposed to set MyFamily for bridges. Supposedly because they'd show up in the descriptors of the other family members. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] DFRI is running two sponsored exits
Hi Moritz, DFRI [1] is running two relays, DFRI0 and DFRI3, which should qualify as fast relays as defined by sponsor j. (They were just recently bumped From 10 MB to 12.5 MB. They both have an exit policy allowing the ports explicitly required on https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorJ.) We'd love to be able to get some funds for this which would make it possible for us to run more exit traffic. We only have one /24 network to run exit traffic from atm though so this is all we can do for now without breaking the stated diversity rules. (Anybody sitting on an IPv4 /24 PI that we can borrow for a year or so? We'd handle it with care!) We could technically run bridges too but we would have to discuss this internally some more first. Do we really want to take money for running entry _and_ exit relays? Isn't that exactly how you'd attack Tor users if you had the power, by controlling entry and exit? If we've missed some public discussion on this topic, please point us at it. [1] https://dfri.se/index.en/ Thanks, Linus, DFRI pgpdDuvvdf87Q.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Need advice on IPv6 bridge config
You're right. Brackets are not significant. The 'NoAdvertise' is the other piece of bad advice I've been giving. You will have to remove that flag and really run your bridge on the IPv4 address as well as the IPv6 for now. Or filter it off in a local firewall or something like that outside of Tor. -- Linus Steve Snyder wrote Mon, 17 Sep 2012 11:16:12 -0400: | No difference with the brackets removed from the IPv4 ORPort. | | More generally, Tor v0.2.3.22 seems to have no problem with an IPv4 | address in brackets. That is, having "ORPort [aa.bb.cc.dd]:443" as | the only ORPort statement works with "[aa.bb.cc.dd]:443" used as the | bridge address in Vidalia. | | | On 09/17/2012 11:00 AM, Linus Nordberg wrote: | > Steve Snyder wrote | > Mon, 17 Sep 2012 07:25:30 -0400: | > | > | Address aa.bb.cc.dd | > | OutboundBindAddress aa.bb.cc.dd | > | ORPort [2a00:1d70:ed15:37:235:53:64:0]:443 | > | OrPort [aa.bb.cc.dd]:80 NoAdvertise | > | > That will probably be treated as an IPv6 address. Can you please remove | > the square brackets and try again? | > ___ | > tor-relays mailing list | > tor-relays@lists.torproject.org | > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays> | ___ | tor-relays mailing list | tor-relays@lists.torproject.org | https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Need advice on IPv6 bridge config
Steve Snyder wrote Mon, 17 Sep 2012 07:25:30 -0400: | Address aa.bb.cc.dd | OutboundBindAddress aa.bb.cc.dd | ORPort [2a00:1d70:ed15:37:235:53:64:0]:443 | OrPort [aa.bb.cc.dd]:80 NoAdvertise That will probably be treated as an IPv6 address. Can you please remove the square brackets and try again? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Need advice on IPv6 bridge config
Steve Snyder wrote Sat, 15 Sep 2012 13:40:39 -0400: | The bridge config looks like this in part (local IPv4 address hidden): | | Address aa.bb.cc.dd | OutboundBindAddress aa.bb.cc.dd | ORPort [2a00:1d70:ed15:37:235:53:64:0]:443 You need an IPv4 ORPort as well (this is bug #4847). If you don't want to advertise the IPv4 port, use the "NoAdvertise" flag. Thanks for testing! ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Current state of v0.2.3.x IPv6 bridges?
"Steve Snyder" wrote Fri, 31 Aug 2012 14:38:46 -0400 (EDT): | I'm wondering about the benefit of running abridge on an IPv6 address. | | Since the big announcement last December that v0.2.3.9 supports IPv6 addresses for bridges, I've read a few comments to the affect that BridgDB doesn't understand IPv6 addresses. | | So... what is the state of publishing IPv6 bridge addresses? Will clients requesting a bridge address ever be given an IPv6 address? Can a client specifically request an IPv6 address (or IPv4 address, for that matter)? There are two parts to this. One, the bridge authority has to handle IPv6 OR ports correctly, for example test them for reachability. Two, the bridge authority needs to communicate the bridge addresses to BridgeDB which has to do something clever with them. What's lacking at the moment is deployment of the first part, i.e. upgrading the bridge authority to a (not yet released) version of Tor that can handle IPv6 OR ports in server descriptors. This will happen during the next couple of weeks. The benefit of running a bridge on an IPv6 address will then rise significantly. (The benefit of it up until now has been helping out with testing of the code and being able to hand out an IPv6 bridge address to users who need it.) Regarding clients requesting bridge addresses, that's not exactly how it (is supposed to) work(s)*. The human being running the client gets hold of bridge addresses somehow and types them into a Vidalia window or her Tor configuration file. The way she does this vary. The bridges page [1] lists both IPv4 and IPv6 addresses to choose from. (*) A client _can_ actually get an OR port from the bridge authority by asking for it using a hash of its identity (or was it descriptor?) but we're moving away from that IIUC. [1] https://bridges.torproject.org/ -- Linus ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-assistants] Call for discussion: turning funding into more exit relays
Martin Algö wrote Tue, 14 Aug 2012 11:39:07 +0200: | It's funny that you mention dfri.se, because they e-mailed me (and all | swedish relay operators i believe) yesterday and I'm lurking in their IRC | channel (and #tor) as I write this. [...] Yes, DFRI emailed some 85 Swedish relay operators in an effort to make contact with more people experienced in running Tor relays in Sweden. We'd like to collect knowledge about what kind of trouble you might run into and let other people know. Our hypothesis is that it's easy to run a relay in Sweden. | 2012/8/14 Roger Dingledine [...] | > Good idea. Do you know about dfri.se? They are running some fast exit | > relays in Sweden in an organized way. I bet they could help with the | > legal side. I agree that it would be great to have some equivalent of the | > Tor Legal FAQ written with Sweden in mind. I'm cc'ing Linus (from dfri) | > in case he has any thoughts here. Our goal is definitely to be able to help out with legal issues related to running a Tor relay. We're not there yet though -- we simply lack the legal expertise and the contacts needed. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
