- tor-relays - lists.torproject.org

Re: [tor-relays] bwadv vs bwhist + implications
by torhoste＠tor.host-ed.me 19 Sep '12

19 Sep '12

> hello there! > very interesting information you shared here, thank you. > while i dont have any further information to rely on, > i would still like to share a few simple thoughts. > You're welcome. > lets assume for a second that there are no errors in the code and that Tor > is not using a significantly less than optimal network topology. > > i would argue against adjusting the traffic limit as you suggested, for > the > following reasons: > -pending more data, this ratio might arbitrarily change at any point in > time, > causing either under utilization of the network. which is what you have > set > out to prevent. > or over utilization which will cause troubles to the relay admins, > like throttling by providers. > I clearly see where you're coming from. While I *certainly* do not propose a large-scale adjustment in relay configurations (that isn't my incentive actually), I still seriously think about doing the adjustments - certainly with some offset to the observed figures to address potential over-utilization - for our very own relays. We're looking forward to receive some sponsored VPS(s) that we would like to dedicate/contribute to the Tor network and I'm somehow concerned, i.e. think it's unfortunate, that - expectedly - 1/3 of our monthly traffic limit(s) wouldn't be used after all. That said, please have a brief look at https://metrics.torproject.org/bandwidth.png?start=2010-09-19&dpi=72&end=20… - i.e. a two-year bwadv vs bwhist sample of the whole Tor network. It actually shows a rather significant trend of the "1/3 bwadv vs bwhist discrepancy" I observed previously. > -its important to have more capacity then needed, this allows better > stability and is helpful with dealing with sudden increases in Tor use, a > somewhat common event, > Same here. I wouldn't want to argue against your assumptions as they - from a general/common-sense perspective - make perfect sense. Still, looking at the two-year sample graph, I cannot really see such a network behavior, i.e. sub-samples where the gap between bwadv vs bwhist would be significantly lower at times. > of course, this is not to take away anything from your observation and > initiative. > who knows, you might have found a serious problem with the network. > I don't think there's a serious problem with the network. I just would like to ask the list for the actual reasoning of the, from my perspective rather *large*, discrepancy. You named three (actually two) things: 1. under-/over-utilization: the trend seems to be pretty constant and with some offset calculated in, I would look forward to avoid over-utilization (just for our own initiative certainly) and thus potential throttling by providers for our very own contribution to the network. 2. adjustments to peak traffic: While I totally understand the argument, I just can't see that happening (at least) within the last two years looking at the sample graph. thanks a lot for your feedback! Please don't get me wrong counter-arguing. I'm just considering opportunities for our own initiative and clearly see the general validity of your argumentation. Also I wouldn't want to exclude the possibility that I'm missing something important here and would like to ask everyone concerned to tell me where my (potential) misconception actually is ;-) Cheers, Thomas > thanks >

1 0

bwadv vs bwhist + implications
by torhoste＠tor.host-ed.me 19 Sep '12

19 Sep '12

Hi, we're currently looking forward to expand our contribution to the Tor network and as a mathematically fascinated person, I'm pretty much into statistical data from https://metrics.torproject.org/network.html at the moment and implication on Accounting/Bandwidthrate configuration opportunities for our Tor relays to utilize them at maximum efficiency, i.e. I'd like to start a discussion with other relay operators. That said, I noticed that the BW advertised into the network (bwadv) vs the BW actually put through the network (bwhist) is at a 1.544945508 ratio throughout the whole Tor network. I.e. a relay configured to provide 500 GiB of traffic/mo would put through (respectively actually is putting through right now) "just" 323.63601 GiB traffic/mo on average. Now, my questions (respectively thoughts for discussion) would be: 1. What would you assume to be the reason for it? I mean this is a calculated average through 3117 relays and thus I'd say rather meaningful, i.e. the largest possible "sample" (i.e. it isn't just a few relays behaving like so). Also, looking at one of our own two test relays that is *definitely* running 24/7 - vks24949, it pretty much shows the same figures. Vnstat estimates 342.23 GiB traffic/mo for September 12 and the relay actually is configured to provide 500 GiB traffic/mo with daily accounting set up (1.461005756 ratio vs 1.544945508 ratio calculated from *.csv provided at https://metrics.torproject.org/network.html for the whole Tor network). 2. As a result of all that, I currently come to the conclusion that it could be a good practice to actually configure 1.544945508 times the traffic for both the daily accountingmax + the actual relaybandwidthrate in KiB/s to *really* utilize the BW provided by sponsors (in our very case) to the full potential. I'm looking forward to your input on this. Thanks in advance, Thomas

1 0

Need advice on IPv6 bridge config
by Steve Snyder 18 Sep '12

18 Sep '12

I'm getting my feet wet with IPv6 bridges, so far without success. I set up a test bridge (0.2.3.22-rc) on one network and plugged the address:port into Vidalia (TBB x86_64-2.2.39-1) on another. 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 At run time the final Tor log entries are: [notice] Tor has successfully opened a circuit. Looks like client functionality is working. [notice] Bootstrapped 100%: Done. In Vidalia the message log entries are: [Notice] Learned fingerprint 24432B99CA2533BC95ABF66C7AFE835F96DD2B2D for bridge 2a00:1d70:ed15:37:235:53:64:0:443 [Notice] no known bridge descriptors running yet; stalling That last line is repeated periodically forever. So I have enough connectivity to correctly determine the fingerprint, bit not enough to get bridge descriptors. What am I doing wrong? Thanks.

2 7

Goodbye list
by Dude 18 Sep '12

18 Sep '12

thanks

1 0

Bad exit
by grarpamp 17 Sep '12

17 Sep '12

Exit (one of these two I think, no guarantees): 109C56AC68DB55D16E79F832E19313E6C3E47363 67FD1D03F922975269F94EC7E4FD38C6D0E5E900 - torservers? It's not occurring now via them, but whatever exit it was generated these... Error: mail.google.com uses an invalid security certificate. The certificate is only valid for the following names: *.mywebdav.de , mywebdav.de (Error code: ssl_error_bad_cert_domain) Erroneous public key presented: aa 94 04 12 c4 32 2b c9 62 48 00 88 16 6f cd 8a 21 22 fe 6d 9d 51 63 6f 85 62 db 9c b5 3f e6 bf 1d 45 ca 51 57 3d 5f 83 97 73 b6 dd 99 86 d8 27 e5 07 71 94 cf d5 a4 92 a6 25 f8 06 fd 50 6c ad 70 2c 71 ca 66 38 1d 35 93 f1 c3 ff 52 6a 90 3d 54 fd 6f 69 34 9f 59 29 aa 05 59 91 95 33 53 8b e6 b6 cf 65 dc 02 1a 31 57 d8 f4 11 70 f5 68 46 13 af c1 dc f0 b0 ce 43 b3 13 61 8a 18 00 84 32 2b 9a 9c aa 49 f3 fc b6 a1 d2 a9 d9 bd b4 53 a0 60 46 e7 e9 22 9d 23 08 5c 91 32 89 e7 85 4e ec 18 b7 d0 b3 6b 74 fa b4 f3 08 11 1f 1b e1 55 e9 7b 90 f4 64 93 08 a2 58 70 e0 c6 41 f9 f9 d0 9c b1 3d e9 b6 ae b3 73 ac 11 d3 f6 91 9e 79 f2 b4 d7 7d 96 8a 83 30 b1 bf 40 6f 18 24 42 43 b7 b1 65 7e 3d 1f d2 47 e9 fb 2e 10 21 7c ce 20 a8 c3 35 f3 d8 91 d1 a6 a1 87 52 4b de 39 1e ec b9 4d

4 3

Exit on Brasil
by guerra＠riseup.net 17 Sep '12

17 Sep '12

It has come to my attention this information on lorea's group at n-1.cc: n-1.cc/mod/threaded_forums/topicposts.php?topic=1396718&group_guid=489432 I am sorry if I am double posting, I just wanted to know how much bandwidth it is needed for this project to make sure I am able to contribute.

1 0

Massive ongoing google groups spamming
by tor-admin 13 Sep '12

13 Sep '12

Hi all, there is a massive spamming of google groups ongoing. I received several complains as below. From the domain list it seems that all major Tor exit nodes are affected. Running an Exit without custom WHOIS, all abuse message are received by my ISP and forwarded. So I have to temporarily ban google groups. How do other operators deal with this? Regards, Torland "This is some voluminous, off-topic flooding and harassment on the ba.broadcast Usenet newsgroup. It is being reported to abuse reporting mailboxes based on the contents of the NNTP-Posting-Host: and X-Complaints-To: headers, and lookup of the originating IP address via WHOIS and the Network Abuse Clearinghouse. They are sometimes also crossposted to unrelated newsgroups such as rec.arts.tv, soc.culture.new-zealand, and several other newsgroups in the nz.* hierarchy. It is disruptive, and completely off-topic, as well as causing disruptive, cascaded flame wars among those unrelated newsgroups. This user has also been posting from other sources, including 100tb.com, 51.net, 62.net, all.de, bahnhof.se, bayern.de, boingboing.net, broadviewnet.net, ccc.de, formlessnetworking.net, hessmo.com, noisetor.net, oceanic.net, plebia.org, privacyrepublic.org, riseup.net, ru.is, sbcglobal.net, servers.com, snydernet.net, solidonetworks.com, stanford.edu, stargrave.org, torland.me, torservers.net, dmzglobal.com, telstraclear.net, xtra.co.nz, clear.net.nz, orcon.net.nz, netgate.net.nz, freeparking.co.nz, powerusenet.com, giganews.com, thundernews.com, altopia.com, comcast.net, groups.google.com, and tigerusenet.com. It appears that you are merely the latest of his victims. The charter of ba.broadcast is as follows: "This group is here for discussions, comments and program reminders about broadcast media in the San Francisco Bay Area, both radio and television. It also includes cable systems and TVRO/BCRO in the SF Bay Area. It does not include scanner, ham radio or other action here in the SF Bay Area; these may be addressed in another newsgroup at another time. Issues of national interest should be posted to one of the groups in rec.arts.tv or rec.radio." (see: http://groups.google.com/group/ba.broadcast/browse_thread/thread/ddfbd8175e…) The charter does not include sexual innuendo and libel, abusive threats, bigotry and minority bashing, or any off-topic discussion of subjects not reasonably related to broadcasting in the Bay Area, which now consitute the overwhelming majority of current message traffic on ba.broadcast, to the detriment and exclusion of on-topic participation by others. Please take appropriate action to put a stop this this misbehavior originating from your site that is disrupting ba.broadcast. [... Offending article removed ...]

3 2

Re: [tor-relays] tor-relays Digest, Vol 18, Issue 1
by Christian 13 Sep '12

13 Sep '12

Hi Roger, > Who owns that socket file? /var/run/tor/control is owned by debian-tor. > Anything else in that other default config file? The tor-service-defaults-torrc file contains: DataDirectory /var/lib/tor PidFile /var/run/tor/tor.pid RunAsDaemon 1 User debian-tor ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie Log notice file /var/log/tor/log > > ORPort 443 NoListen > > > ORPort 0.0.0.0:9090 NoAdvertise > > > ORPort [::]:9090 IPv6Only NoAdvertise > > > > Is this ipv6 bind attempt the one causing problems? > > > > The ipv6 bind attempt was a try to solve the problem. Problem persists with and without ipv6 bind attempt. Thanks a lot! christian > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Failed to parse/validate config: failed to bind one of the > listener ports (Christian) > 2. Re: Failed to parse/validate config: failed to bind one of > the listener ports (Roger Dingledine) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 01 Jul 2012 06:14:19 +0200 > From: Christian <brightsidedarkside(a)t-online.de> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] Failed to parse/validate config: failed to bind > one of the listener ports > Message-ID: <1341116059.2767.42.camel(a)delusions.local> > Content-Type: text/plain; charset="UTF-8" > > Hi Nick, hi Jean, > > thanks a lot for your fast reaction. I was at my parents' place for a > week, that's why I'm a little late. > > First, I tried port 9001, but in fact it is a port forwarding on the > router from 443 to 9090. > > Following, I post the terminal output when using the given torrc and the > torrc file itself. > Really, no logs are created, independent of the logging options. > The socket unlink issue happens since I use tor and that's for a while > now - it never affected functionality. > Yes, I'm into psychiatric symptoms. A friend of mine uses monsters' > names from films. ;-) > > Again, thanks a lot for your help! > > Thankfully > > christian > > ca@delusions:~$ sudo service tor restart > [sudo] password for ca: > * Stopping tor daemon... > [ OK ] > * Starting tor > daemon... > Jul 01 06:00:13.321 [warn] Could not unlink /var/run/tor/control: > Permission denied > Jul 01 06:00:13.321 [warn] Failed to parse/validate config: Failed to > bind one of the listener ports. > Jul 01 06:00:13.321 [err] Reading config failed--see warnings above. > > [fail] > ca@delusions:~$ > > > > The torrc (complete to prevent me from confusing, but slightly spoiled > by my mail client with line breaks - RunAsDeamon is set by another > default config file): > > > ## Configuration file for a typical Tor user > ## Last updated 22 April 2012 for Tor 0.2.3.14-alpha. > ## (may or may not work for much older or much newer versions of Tor.) > ## > ## Lines that begin with "## " try to explain what's going on. Lines > ## that begin with just "#" are disabled commands: you can enable them > ## by removing the "#" symbol. > ## > ## See 'man tor', or https://www.torproject.org/docs/tor-manual.html, > ## for more options you can use in this file. > ## > ## Tor will look for this file in various places based on your platform: > ## https://www.torproject.org/docs/faq#torrc > > ## Tor opens a socks proxy on port 9050 by default -- even if you don't > ## configure one below. Set "SocksPort 0" if you plan to run Tor only > ## as a relay, and not make any local application connections yourself. > #SocksPort 9050 # Default: Bind to localhost:9050 for local connections. > #SocksPort 192.168.0.1:9100 # Bind to this adddress:port too. > > ## Entry policies to allow/deny SOCKS requests based on IP address. > ## First entry that matches wins. If no SocksPolicy is set, we accept > ## all (and only) requests that reach a SocksPort. Untrusted users who > ## can access your SocksPort may be able to learn about the connections > ## you make. > #SocksPolicy accept 192.168.0.0/16 > #SocksPolicy reject * > > ## Logs go to stdout at level "notice" unless redirected by something > ## else, like one of the below lines. You can have as many Log lines as > ## you want. > ## > ## We advise using "notice" in most cases, since anything more verbose > ## may provide sensitive information to an attacker who obtains the > logs. > ## > ## Send all messages of level 'notice' or higher > to /var/log/tor/notices.log > #Log notice file /var/log/tor/notices.log > ## Send every possible message to /var/log/tor/debug.log > Log debug file /var/log/tor/debug.log > ## Use the system log instead of Tor's logfiles > #Log notice syslog > ## To send all messages to stderr: > #Log debug stderr > > ## Uncomment this to start the process in the background... or use > ## --runasdaemon 1 on the command line. This is ignored on Windows; > ## see the FAQ entry if you want Tor to run as an NT service. > #RunAsDaemon 1 > > ## The directory for keeping all the keys/etc. By default, we store > ## things in $HOME/.tor on Unix, and in Application Data\tor on Windows. > #DataDirectory /var/lib/tor > > ## The port on which Tor will listen for local connections from Tor > ## controller applications, as documented in control-spec.txt. > #ControlPort 9051 > ## If you enable the controlport, be sure to enable one of these > ## authentication methods, to prevent attackers from accessing it. > #HashedControlPassword > 16:872860B76453A77D60CA2BB8C1A7042072093276A3D701AD684053EC4C > #CookieAuthentication 1 > > ############### This section is just for location-hidden services ### > > ## Once you have configured a hidden service, you can look at the > ## contents of the file ".../hidden_service/hostname" for the address > ## to tell people. > ## > ## HiddenServicePort x y:z says to redirect requests on port x to the > ## address y:z. > > #HiddenServiceDir /var/lib/tor/hidden_service/ > #HiddenServicePort 80 127.0.0.1:80 > > #HiddenServiceDir /var/lib/tor/other_hidden_service/ > #HiddenServicePort 80 127.0.0.1:80 > #HiddenServicePort 22 127.0.0.1:22 > > ################ This section is just for relays ##################### > # > ## See https://www.torproject.org/docs/tor-doc-relay for details. > > ## Required: what port to advertise for incoming Tor connections. > #ORPort 443 > ## If you want to listen on a port other than the one advertised in > ## ORPort (e.g. to advertise 443 but bind to 9090), you can do it as > ## follows. You'll need to do ipchains or other port forwarding > ## yourself to make this work. > ORPort 443 NoListen > ORPort 0.0.0.0:9090 NoAdvertise > ORPort [::]:9090 IPv6Only NoAdvertise > > ## The IP address or full DNS name for incoming connections to your > ## relay. Leave commented out and Tor will guess. > #Address noname.example.com > > ## If you have multiple network interfaces, you can specify one for > ## outgoing traffic to use. > # OutboundBindAddress 10.0.0.5 > > ## A handle for your relay, so people don't have to refer to it by key. > Nickname BrightSideDarkSide > > ## Define these to limit how much relayed traffic you will allow. Your > ## own traffic is still unthrottled. Note that RelayBandwidthRate must > ## be at least 20 KB. > ## Note that units for these config options are bytes per second, not > bits > ## per second, and that prefixes are binary prefixes, i.e. 2^10, 2^20, > etc. > #RelayBandwidthRate 100 KB # Throttle traffic to 100KB/s (800Kbps) > #RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps) > > ## Use these to restrict the maximum traffic per day, week, or month. > ## Note that this threshold applies separately to sent and received > bytes, > ## not to their sum: setting "4 GB" may allow up to 8 GB total before > ## hibernating. > ## > ## Set a maximum of 4 gigabytes each way per period. > #AccountingMax 4 GB > ## Each period starts daily at midnight (AccountingMax is per day) > #AccountingStart day 00:00 > ## Each period starts on the 3rd of the month at 15:00 (AccountingMax > ## is per month) > #AccountingStart month 3 15:00 > > ## Contact info to be published in the directory, so we can contact you > ## if your relay is misconfigured or something else goes wrong. Google > ## indexes this, so spammers might also collect it. > ContactInfo Sides of the moon <brightsidedarkside AT t-online dot de> > ## You might also include your PGP or GPG fingerprint if you have one: > #ContactInfo 0xFFFFFFFF Random Person <nobody AT example dot com> > > ## Uncomment this to mirror directory information for others. Please do > ## if you have enough bandwidth. > #DirPort 9030 # what port to advertise for directory connections > ## If you want to listen on a port other than the one advertised in > ## DirPort (e.g. to advertise 80 but bind to 9091), you can do it as > ## follows. below too. You'll need to do ipchains or other port > ## forwarding yourself to make this work. > #DirPort 80 NoListen > #DirPort 127.0.0.1:9091 NoAdvertise > ## Uncomment to return an arbitrary blob of html on your DirPort. Now > you > ## can explain what Tor is if anybody wonders why your IP address is > ## contacting them. See contrib/tor-exit-notice.html in Tor's source > ## distribution for a sample. > #DirPortFrontPage /etc/tor/tor-exit-notice.html > > ## Uncomment this if you run more than one Tor relay, and add the > identity > ## key fingerprint of each Tor relay you control, even if they're on > ## different networks. You declare it here so Tor clients can avoid > ## using more than one of your relays in a single circuit. See > ## https://www.torproject.org/docs/faq#MultipleRelays > ## However, you should never include a bridge's fingerprint here, as it > would > ## break its concealability and potentionally reveal its IP/TCP address. > #MyFamily $keyid,$keyid,... > > ## A comma-separated list of exit policies. They're considered first > ## to last, and the first match wins. If you want to _replace_ > ## the default exit policy, end this with either a reject *:* or an > ## accept *:*. Otherwise, you're _augmenting_ (prepending to) the > ## default exit policy. Leave commented to just use the default, which > is > ## described in the man page or at > ## https://www.torproject.org/documentation.html > ## > ## Look at https://www.torproject.org/faq-abuse.html#TypicalAbuses > ## for issues you might encounter if you use the default exit policy. > ## > ## If certain IPs and ports are blocked externally, e.g. by your > firewall, > ## you should update your exit policy to reflect this -- otherwise Tor > ## users will be told that those destinations are down. > ## > ## For security, by default Tor rejects connections to private (local) > ## networks, including to your public IP address. See the man page entry > ## for ExitPolicyRejectPrivate if you want to allow "exit enclaving". > ## > #ExitPolicy accept *:6660-6667,reject *:* # allow irc ports but no more > #ExitPolicy accept *:119 # accept nntp as well as default exit policy > ExitPolicy reject *:* # no exits allowed > > ## Bridge relays (or "bridges") are Tor relays that aren't listed in the > ## main directory. Since there is no complete public list of them, even > an > ## ISP that filters connections to all the known Tor relays probably > ## won't be able to block all the bridges. Also, websites won't treat > you > ## differently because they won't know you're running Tor. If you can > ## be a real relay, please do; but if not, be a bridge! > BridgeRelay 1 > ## By default, Tor will advertise your bridge to users through various > ## mechanisms like https://bridges.torproject.org/. If you want to run > ## a private bridge, for example because you'll give out your bridge > ## address manually to your friends, uncomment this line: > #PublishServerDescriptor 0 > > User debian-tor > > > > tor-relays-request(a)lists.torproject.org: > > Send tor-relays mailing list submissions to > > tor-relays(a)lists.torproject.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > or, via email, send a message with subject or body 'help' to > > tor-relays-request(a)lists.torproject.org > > > > You can reach the person managing the list at > > tor-relays-owner(a)lists.torproject.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of tor-relays digest..." > > > > > > Today's Topics: > > > > 1. Re: Failed to parse/validate config: failed to bind one of > > the listener ports (Nick Mathewson) > > 2. Re: Failed to parse/validate config: failed to bind one of > > the listener ports (Jean Trolleur) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 26 Jun 2012 11:59:22 -0400 > > From: Nick Mathewson <nickm(a)freehaven.net> > > To: tor-relays(a)lists.torproject.org > > Subject: Re: [tor-relays] Failed to parse/validate config: failed to > > bind one of the listener ports > > Message-ID: > > <CAKDKvuyeEBDEO6rrbqVQSZcOy_cbeuGWMX2gisUjjETk0VgJEw(a)mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On Sat, Jun 23, 2012 at 7:38 PM, Christian > > <brightsidedarkside(a)t-online.de> wrote: > > > Hi dear fellows, > > > > > > I'm sorry to use again this way of addressing my problem as in Vol 17, > > > Issue 5. It will be the last time. Promise. > > > > > > I can't find any solution on the web. > > > When starting tor, it always reads "Failed to parse/validate config: > > > failed to bind one of the listener ports". > > > > Hm. It really should be saying something more than that on startup; > > there should be a message right before that about *why* it couldn't > > parse or validate the ports. > > > > I just tried the ORPort combination you listed there, and it seemed to > > work out okay for me. It might be easier to diagnose if you could > > upload your entire torrc, and the entire output of starting Tor up to > > the point where it says "failed to parse/validate config:" > > > > hth, > > -- > > Nick > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 26 Jun 2012 15:18:42 -0500 > > From: Jean Trolleur <sigtstp(a)gmail.com> > > To: tor-relays(a)lists.torproject.org > > Subject: Re: [tor-relays] Failed to parse/validate config: failed to > > bind one of the listener ports > > Message-ID: > > <CAPN5qOdaMr==8D-kTz01cAZDHrDXSGuh5T+3DVfscJLx8jLgZA(a)mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Try: > > > > ORPort 443 > > ORListenAddress 0.0.0.0:9001 > > > > On Sat, Jun 23, 2012 at 6:38 PM, Christian > > <brightsidedarkside(a)t-online.de> wrote: > > > Hi dear fellows, > > > > > > I'm sorry to use again this way of addressing my problem as in Vol 17, > > > Issue 5. It will be the last time. Promise. > > > > > > I can't find any solution on the web. > > > When starting tor, it always reads "Failed to parse/validate config: > > > failed to bind one of the listener ports". > > > > > > Furthermore, there are only empty logfiles, independent of the > > > configuration of the logs option "notice". > > > > > > Has anyone else this kind of problem? > > > > > > This is my ORPort section: > > > ORPort 443 NoListen > > > ORPort 0.0.0.0:9090 NoAdvertise > > > > > > I even can't make a control port accessible for e.g. arm running on the > > > same machine, although I didn't use it before. > > > > > > Client functionality is not working either. No connections through tor. > > > > > > Tor is configured as a bridge, my OS is Ubuntu lucid 10.04 and Tor's > > > version is 2.3.17-beta-1~lucid+1. > > > > > > It just worked until the upgrade to the new version through torproject's > > > repository. > > > > > > I really do have forwarded external port 443 to port 9090 on my machine. > > > > > > It nearly has me left in broken state dying. > > > > > > I checked for new requests concerning apparmor allowance, but there were > > > only the ability to chown and access to /sys/devices/system/cpu/ which I > > > granted both. > > > > > > I'm not so really competent with computers and therefore grateful for > > > any help. > > > Strange. No error logs, no function, no topic on the web.. > > > > > > Kind regards, > > > > > > christian > > > > > > > > > _______________________________________________ > > > tor-relays mailing list > > > tor-relays(a)lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > ------------------------------ > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > End of tor-relays Digest, Vol 17, Issue 8 > > ***************************************** > > > > > ------------------------------ > > Message: 2 > Date: Sun, 1 Jul 2012 05:14:22 -0400 > From: Roger Dingledine <arma(a)mit.edu> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Failed to parse/validate config: failed to > bind one of the listener ports > Message-ID: <20120701091422.GB8804(a)moria.seul.org> > Content-Type: text/plain; charset=us-ascii > > On Sun, Jul 01, 2012 at 06:14:19AM +0200, Christian wrote: > > Really, no logs are created, independent of the logging options. > > That's expected -- it's because logs are parsed in the same step as > binding the sockets, and it never gets to the 'setting up the logs' part. > > > The socket unlink issue happens since I use tor and that's for a while > > now - it never affected functionality. > > Who owns that socket file? > > > The torrc (complete to prevent me from confusing, but slightly spoiled > > by my mail client with line breaks - RunAsDeamon is set by another > > default config file): > > Anything else in that other default config file? > > > ORPort 443 NoListen > > ORPort 0.0.0.0:9090 NoAdvertise > > ORPort [::]:9090 IPv6Only NoAdvertise > > Is this ipv6 bind attempt the one causing problems? > > --Roger > > > > ------------------------------ > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > End of tor-relays Digest, Vol 18, Issue 1 > *****************************************

1 1

[OT] ExcludeNodes no longer working
by Scott Bennett 12 Sep '12

12 Sep '12

I know this really belongs on tor-talk, but I haven't been subscribed to it for a long time now. Sorry if posting this here bothers anyone. Back in early July, I upgraded from 0.2.3.13-alpha to 0.2.3.18-rc. I immediately ran into problems with a python script that honors the http_proxy environment variable, which I normally have set to the localhost port for privoxy, which, in turn, connects to tor's SOCKS port. I couldn't really see what was going wrong, but using arm to ask for a new identity seemed to help sometimes to get a circuit that worked. Sending tor a SIGHUP instead also seemed to work about as often. A bit over a week ago, I switched to 0.2.3.20-rc, and the problem still occurs. However, 0.2.3.20-rc now also emits a new message from time to time, the most recent occurrence of which is Sep 06 06:02:45.934 [notice] Low circuit success rate 7/21 for guard TORy0=753E0B5922E34BF98F0D21CC08EA7D1ADEEE2F6B. Wondering whether such circuit-building failures might be related to the other problem, I began a little experiment: each time I saw a "Low circuit success rate" message, I added the key fingerprint of the node in question to my ExcludeNodes list in torrc and sent tor a SIGHUP. The problem is still occurring, though, and when I look at the circuits involved, they all seem to have at least one of the excluded nodes in them, usually in the entry position. So my question is, what changed between 0.2.3.13-alpha and 0.2.3.18-rc (or possibly 0.2.3.20-rc) in the handling of nodes listed in the ExcludeNodes line in torrc? And is there anything I can do to get the ExcludeNodes list to work again the way it used to work? Thanks in advance for any relevant information. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

5 8

Re: [tor-relays] [OT] ExcludeNodes no longer working
by Scott Bennett 12 Sep '12

12 Sep '12

On Tue, 11 Sep 2012 16:24:36 -0400 Nick Mathewson <nickm(a)freehaven.net> wrote: >On Tue, Sep 11, 2012 at 1:12 PM, Jacob Appelbaum <jacob(a)appelbaum.net> wrote: >> Hi Scott, >> >> It is nice to see you posting again, I had wondered where you had gone. >> >> Scott Bennett: >>> I know this really belongs on tor-talk, but I haven't been subscribed >>> to it for a long time now. Sorry if posting this here bothers anyone. >> >> >> Seems like a fine place to discuss relay problems, which is what it >> sounds like, no? > >Maaybe! The very best place would be the bugtracker, of course. (I do >seem to recall that you have some issues with trac -- I'm just >mentioning the bugtracker so that other people don't get the idea that >the mailing lists are the best place for bug reports. But a bug >report on the mailing list is much much better than no bug report at >all.) You switched trackers a year or two ago. I don't recall whether I've tried the new one. Either way, I hesitate to submit a bug report until I'm pretty sure I'm looking at a bug, which is why I asked on this list whether anyone else could suggest anything. > >>> Back in early July, I upgraded from 0.2.3.13-alpha to 0.2.3.18-rc. >>> I immediately ran into problems with a python script that honors the >>> http_proxy environment variable, which I normally have set to the localhost >>> port for privoxy, which, in turn, connects to tor's SOCKS port. I couldn't >>> really see what was going wrong, but using arm to ask for a new identity >>> seemed to help sometimes to get a circuit that worked. Sending tor a >>> SIGHUP instead also seemed to work about as often. >> >> If you use 0.2.2.x - what happens? > >I'm not sure what the bug described here is, fwiw. What is the >behavior for the circuits that don't work, and to what extent is >0.2.2.x better? The problem is that the python script in question often has no trouble, but also often does. When it does, it usually gets a good connection twice and fails on the third connection. (Or at least I *think* that's what it does.) Then I either ask tor nicely with arm for a new set of circuits or I pound on tor with a SIGHUP for same, and then try the python script again. The process is slow, so it's very irritating to have to babysit it repeatedly until it finally gets a good connection. If I've left the script a small list of work to do, the failure may come at any point in the list, which then terminates the script. :-( I think it may have an option to ignore errors, but I don't really see an option like that as being very helpful in this situation because it would just fail its way through the rest of the list from that point, but it would take a long time to do that. Quitting outright is much faster. > >>> A bit over a week ago, I switched to 0.2.3.20-rc, and the problem >>> still occurs. However, 0.2.3.20-rc now also emits a new message from time >>> to time, the most recent occurrence of which is >>> >>> Sep 06 06:02:45.934 [notice] Low circuit success rate 7/21 for guard TORy0=753E0B5922E34BF98F0D21CC08EA7D1ADEEE2F6B. >>> >> >> That is an interesting message - I wonder if the author of that message >> might chime in? > >Looks like bug #6475. > >>> Wondering whether such circuit-building failures might be related to the >>> other problem, I began a little experiment: each time I saw a "Low circuit >>> success rate" message, I added the key fingerprint of the node in question >>> to my ExcludeNodes list in torrc and sent tor a SIGHUP. >>> The problem is still occurring, though, and when I look at the >>> circuits involved, they all seem to have at least one of the excluded >>> nodes in them, usually in the entry position. So my question is, what >>> changed between 0.2.3.13-alpha and 0.2.3.18-rc (or possibly 0.2.3.20-rc) >>> in the handling of nodes listed in the ExcludeNodes line in torrc? And >>> is there anything I can do to get the ExcludeNodes list to work again >>> the way it used to work? >>> Thanks in advance for any relevant information. >>> >> >> It seems that there are two issues - one is that a guard is failing to >> build circuits, the other is that you can't seem to exclude them. I have >> to admit, I'm more interested in the former... Is there a pattern to the >> failures? That is for the 7 successes for that node, did you see >> anything interesting? Were say, the nodes that worked somehow in the >> same country as that guard? Or perhaps were the other failed circuits >> all seemingly unrelated to the guard? >> >> As far as the ExcludeNodes - did you set StrictNodes at the same time? >> Are you also a relay? > >Any other configuration info would be helpful here too. Okay. Skipping over local port and IP address usage, here's some client-side stuff. TunnelDirConns 1 PreferTunneledDirConns 1 UseEntryGuards 1 NumEntryGuards [if you really need the number here, let me know--SB] AllowDotExit 0 LongLivedPorts 20-23,47,115,119,143,144,152,178,194,563,706,989,990,992-994,1863,5050,5190-5193,5222,5223,6000-6063,6523,6667,6697,8021,8300 There are also several NodeFamily statements and extensive ExcludeNodes and ExludeExitNodes statements. If there is other stuff you want, let me know, but depending upon what you ask for, I may choose to send it to you directly rather than post it here. > >(To answer your question: looking through the changelogs, and the >commit logs for src/or/circuitbuild.c and src/or/routerlist.c, I can't >find anything that stands out to me as something that might cause an >ExcludeNodes regression. So more investigation will be needed!) > The only thing remotely related that I saw was the following item in the Changelog for 0.2.3.15-rc. o Minor bugfixes (on 0.2.2.x and earlier): . . . - After we pick a directory mirror, we would refuse to use it if it's in our ExcludeExitNodes list, resulting in mysterious failures to bootstrap for people who just wanted to avoid exiting from certain locations. Fixes bug 5623; bugfix on 0.2.2.25-alpha. It probably has nothing to do with what has been causing me trouble, but it was the only item I found about either of the Exclude{,Exit}Nodes statement that mentioned a change between 0.2.3.13-alpha and 0.2.3.18-rc. Scott

1 0