October 2018 - tor-relays - lists.torproject.org

Strength in numbers (of $$)
by I 24 Oct '18

24 Oct '18

4 3

Loss of Guard Flag
by Harkirat Virk 22 Oct '18

22 Oct '18

Hi, I am running an Tor Node nickname 3sKtjMnoiZAIGz07 from ip 59.179.28.221. I was given guard flag briefly on 20th Oct and flag removed on 22 Oct. My advertised bandwidth also dropped from 2.29 MiB/s to 1.79 MiB/s unceremoniously. The consensus weight reduced from 992 to 810. I have checked but did not find any discontinuity on the network end or any connections dropped. Will is be possible to confirm as the the exact reasons for loss of guard and drop in both advertised bandwidth and consensus weight. Regards, Loopback team

2 1

Relay country mismatch
by nusenu 21 Oct '18

21 Oct '18

Hi Mariel The Tor Project uses Maxmind's data to map IP addresses to countries, your IP address block might get updated in Maxmind's file in the future and after onionoo (the data source behind Relay Search) updates its Maxmind file it might appear. This might take a while. kind regards, nusenu btw: please avoid sending the same email to multiple lists, tor-relays is the correct list for this. Mariel: > Hello, > > I am running a relay 3B03DE96FEFB384972D1D31A105DD70E6BDBF079 which has IP 5.188.238.58 and is hosted at G-Core labs Brazil datacenter, but Tor Metrics engine shows the IP country as Luxembourg - https://metrics.torproject.org/rs.html#details/3B03DE96FEFB384972D1D31A105D… > > The valid WHOIS data is: > % Abuse contact for '5.188.238.0 - 5.188.239.255' is 'abuse(a)gcore.lu' > > inetnum: 5.188.238.0 - 5.188.239.255 > netname: LU-GCORELABS-20120809 > country: BR > org: ORG-WIG6-RIPE > admin-c: LA5122-RIPE > tech-c: LA5122-RIPE > status: ALLOCATED PA > geoloc: -23.468962 -46.843583 > mnt-by: RIPE-NCC-HM-MNT > mnt-by: GCL1-MNT > mnt-lower: GCL1-MNT > created: 2018-03-13T10:06:22Z > last-modified: 2018-08-08T10:44:27Z > source: RIPE # Filtered > > Thus, since country is BR it should have be shown as Brazil. Can you fix this data somehow? Thanks in advance. > > > _______________________________________________ > metrics-team mailing list > metrics-team(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team > -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 0

exit operators: overall DNS failure rate above 5% - please check your DNS
by nusenu 20 Oct '18

20 Oct '18

Dear Exit relay operators, (you are getting this email because you are a subscriber of the tor-relays mailing list or because you are among the top 10 affected parties - addressed via BCC to protect the address) first of all thanks for running exit relays! One of the crucial service that you provide in addition to forwarding TCP streams is DNS resolution for tor clients. Exits relays which fail to resolve hostnames are barely useful for tor clients. We noticed that lately the failure rates did increase again and would like to urge you to visit Arthur's "Tor Exit DNS Timeouts" page that shows you the DNS error rate for exit relays: https://arthuredelstein.net/exits/ (the page is usually updated once a day) Please consider checking your DNS if your exit relay consistently shows a non zero timeout rate - and make sure you run an up to date tor version. If you are an exit operator but have no (or no working) ContactInfo, please consider updating that field in your torrc so we can reach you if something is wrong with your relay. kind regards nusenu -- https://twitter.com/nusenu_

5 5

Why is there a difference in the amount of data tor has sent and received?
by Keifer Bly 17 Oct '18

17 Oct '18

Hello list, So when running my OBFS4 bridge I noticed something, tor recently popped up with a message saying “I’ve sent 30mb and received 104mb.” Why is there such a big difference in the amount of data my bridge has received and sent? Info – tor 0.3.4.8 running on Windows 10 (Although tor seems to think it’s running on Windows 8 for some reason)? Thanks. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

Memory leak in 0.3.4.8?
by r1610091651 17 Oct '18

17 Oct '18

Hi I've noticed following after upgrading to latest stable version (0.3.4.8): Memory usage [image: image.png] Connection count [image: image.png] Cpu usage [image: image.png] You'll notice the upgrade happened around Saturday midnight. Known issue? Any work-around? Thanks Sebastian

5 4

Tor relays Workshop in FOSSCOMM
by George Kadianakis 17 Oct '18

17 Oct '18

Greetings list, a few days ago, Elias Papavasileiou did a "Setup your own Tor relay" workshop in the Greek open source conference FOSSCOMM. I attended the workshop and helped out a bit. During the workshop, a presentation was given describing how to setup a relay, and then we moved to hands-on, where we helped 3 groups of 2 people each setup a Tor bridge in their laptop. Even tho a laptop is definitely not the right platform for this, the idea was that if those people learned how to setup a Tor relay/bridge they could afterwards set it up themselves on proper hardware. A few takeaways: - Setting up a Tor relay is not easy even if it's just "apt-get tor, edit torrc, reload tor". There are various things that can go wrong in the between, and basically all groups asked for assistance even tho they all seemed experienced with Linux system administration. - Example of fail: One group put a wrong line in their torrc (they tried to launch with a low-port ORPort of 443 even tho they were not root), then had trouble debugging what's going on, then wiped logs and ran Tor manually as root. Tor overwrote the log file, permission issues occured, and Tor could not start again. We had to manually figure this out and remove the bad log file for Tor to work again. That took a while. - Example of fail: People kind of gave up reading all the comments in the Debian default torrc and asked us for assistance because they did not know what they had to do to make it work. aka what was necessary and what was optional. - After about 45 mins all three groups managed to successfuly run a bridge. I'm just mentioning these things here in case someone can relate and improve the situation. There might be a few things we can do (aka improve the default Debian torrc), or even provide images/docker/vagrant for relays. But I'm not good with these things so I can't really suggest things. Cheers!

2 1

"ORPort auto" versus "ORPort 9001" for a bridge
by Toralf Förster 17 Oct '18

17 Oct '18

I do wonder if the advice [1] is ok or wrong. [1] https://tor.stackexchange.com/questions/6370/how-to-run-an-obfs4-bridge -- Toralf PGP C4EACDDE 0076E94E

2 3

libssh vulnerability (CVE-2018-10933)
by Colin Childs 16 Oct '18

16 Oct '18

Hi tor-relays, This email is just to notify the list of a recent libssh vulnerability[1], and encourage any operators who may be running a vulnerable version of libssh to update. It appears this only impacts libssh in server mode: “This is an important security and maintenance release in order to address CVE-2018-10933., libssh versions 0.6 and above have an authentication bypass vulnerability in the server code. By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication the attacker could successfully authenticate without any credentials. The bug was discovered by Peter Winter-Smith of NCC Group.” Thanks for being relay operators! [1]: https://www.libssh.org/2018/10/16/libssh-0-8-4-and-0-7-6-security-and-bugfi…

1 0

Circuit ID assignment
by Gabbi Fisher 15 Oct '18

15 Oct '18

Hi all, I wanted to learn more about how Tor circuit IDs work. Correct me if I'm wrong, but this is my current understanding: Each hop along the Tor network has its own circuit ID number. (No universal circuit ID number is used to identify a ip-to-ip stream of traffic). How are the circuit ID numbers determined at each hop? What generates the circuit ID number given to a packet? Thanks!

3 2