Re: [tor-relays] Do they use their own modem/router?
> On Jun 14, 2023, at 10:49, Livingood, Jason via tor-relays > wrote: > > a customer that has Advanced Security has in essence (1) chosen to use an XB > gateway rather than buy their own modem & router in retail and manage it > themselves, and (2) turned on Advanced Security. I appreciate your perspective, and taking the time to inform this list, but... I have had three Comcast installations going back over a decade, the most recent less than 3 years ago. In every single case, I was told in no uncertain terms that I had to lease (for about $10/month) and use Comcast equipment in order to get static IP addresses. I tried to escalate the issue and was told it was non-negotiable, end of story. So, no, I haven't "chosen to use an XB gateway rather than buy [my] own modem." When I placed my orders, I specifically requested NO firewall or other extra security measures. In each and every case, the default installation had various kinds of blocking and filtering enabled, which I had to disable (sometimes with a truly monumental and expensive amount of effort, often later having to turn it off again when it is arbitrarily turned back on). So, no, I haven't "turned on Advanced Security." Setting the router to bridge mode on my current install causes it to disconnect from all my static IP addresses, fetch a single address using DHCP, and respond only to that one. So that, too, is not an option. So perhaps what you describe is the way things are *supposed* to work, but at least in my area (northern California) the folks in the field haven't got the memo. That said, I've run Tor relays on my Comcast connections and never had problems with anything blocking Tor per se. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Comcast blocks ALL traffic with tor relays
> On Jun 11, 2023, at 04:46, xmrk2 via tor-relays > wrote: > > I believe Comcast blocks all traffic between its customers and public tor > relay nodes I'm a reluctant Comcast Business user. Here's my experience (briefly, as I'm typing with a newly-fractured wrist): Though during install I asked for "just pipes" with none of the extra services they offer, instead they silently signed me up for their "Security Edge" service. Many things broke. I finally discovered that they were intercepting all outbound UCP and TCP traffic to port 53 and re-directing it to their own, badly-broken DNS resolver which seems to be pretty arbitrary about what it blocks. When I contacted them, they said it couldn't be removed but gave me instructions for turning it off, but the switch to do so on their web site was disabled (grey and not responsive to clicking, using multiple browsers and platforms). After over TWENTY HOURS on chat, they finally disabled it from their end. I had pointed out that it was a direct and blatant violation of California's net neutrality law. Life was good for about a week, then it came back on. I think I next posted a complaint on Reddit (which seems to get more attention than contacting customer service directly) and they, again, turned it off. Around a year later, they started MITMing all my DNS queries again, wreaking havoc on my business. I, again, poked around their web site, and I found that the switch to disable blocking is now enabled (though hard to find) and for a couple of months now things have been okay. None of my difficulties were directly related to Tor, even though I run a relay on one of my IP addresses. However, the variable and arbitrary nature of the blocks they implemented make it seem likely that they could be blocking Tor relays some of the time. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay operators meetup @ rC3
Hi! I couldn't make the meeting (I retire at the end of January, and should at long last have time to devote to things Tor). Thanks for posting the notes. It prompted me to review the draft "expectations for relay operators" document. It looks very good, though I do have a quibble. The line "Try not to let the cops get your relay keys"... ...seems to perpetuate the erroneous belief that the main use for Tor is to evade law enforcement ..."cops" can be considered derogatory in some English-speaking cultures and implies that the aims of Tor Project are averse to law enforcement ...ignores a large segment of potential Tor adversaries I think the community would be better served by language like "Try not to let potential adversaries get your relay keys". --Ron PS: I have requested a gitlab account so that I can comment on the document directly, but I have made such a request before and not received a reply. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [Censorship in Russia] Make HTTPS/Moat captcha more complex?
> On Dec 22, 2021, at 22:42, Gary C. New via tor-relays > wrote: > > Perhaps Directory Authorities could preform fingerprint to address > resolution? I'm not familiar with how I2P does this, but wouldn't this just shift blocking targets from the relatively large pool of bridges and relays to a much smaller and easier-to-block list of directory authorities? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs
> On Nov 10, 2021, at 10:29, Jonas via tor-relays > wrote: > > I could easily run thousands of [relays] across many ASes ... However, > providing proof of identity or anything which ties to my real world identity > is a non-starter. I'm in a similar situation, though it would be "dozens" instead of "thousands." I understand the argument in favor of restricting relays to well-known, identifiable operators but I also see a possible flaw in the logic. The more you restrict who can run a relay, the fewer relays there will be. Yet, no amount of restriction will eliminate all malicious relays. (Even requiring relay operators to submit DNA samples to prove they are first-degree relatives of Tor Project board members wouldn't guarantee perfection.) Given that malicious relays will always exist, there is merit in the idea of having the largest possible pool of relays against which bad actors would have to compete. With a low bar for entry, bad actors could even end up competing against other malicious operators, and ordinary users would still come out ahead. Unfortunately, I fear that reliable numbers would be hard to come by. But I think that there might be many people in the same position that Jonas and I are in: willing and able to run a significant number of high-value relays but only if we can do so ignoring or circumventing real-identity measures. Bad actors will disproportionately ignore or subvert such measures; worthy volunteers will be locked out. It is human nature, when faced with a threat, to respond by asserting control. I wonder if, in this case, decentralization and increased participation might be better strategies. --Ron ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ubuntu Focal
> On May 31, 2020, at 09:49, Pac-Man wrote: > > When will there be support for Ubuntu 20.04 LTS? There does not seem to be a > repo setup where you can use focal. I assume that you're trying to follow the instructions on https://2019.www.torproject.org/docs/debian.html.en and you're frustrated by the fact that the tool doesn't give a source list for Ubuntu 20.04, in spite of the warning to "Do not use the packages in Ubuntu's universe. In the past they have not reliably been updated. That means you could be missing stability and security fixes." Since 20.04 has been out less than two months, I'm not entirely surprised that the web page hasn't been updated yet. You could just ignore the warning, and install from the default Ubuntu repos: sudo apt install tor which will give you Tor version 0.4.2.7. Then, given the warning above, watch for the debian installation page to be updated and switch to a Tor repo as soon as one is available, thus addressing the "not reliably updated" concerns. Perhaps even better, I just tried using the instructions for bionic, but substituting "focal" for "bionic" in the /etc/apt/sources.list file. That gave me a quite-current Tor version 0.4.3.5. So the repo is apparently actually available, it's just that the web page hasn't been updated yet. The actual commands I used: Append to /etc/apt/sources.list: deb https://deb.torproject.org/torproject.org focal main deb-src https://deb.torproject.org/torproject.org focal main Install the repo signing key: apt install gnupg2 dirmngr ; \ wget https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc ; \ apt-key add https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Again: abuse email for non-exit relay (masergy)
I got a *bunch* (harassment-level) of telephone calls from my ISP similar to this. They refused to do anything by email, and wouldn't tell me anything more about the supposed port-scanning attacks. They just kept asking me to "make sure Windows and my router firmware were up to date." (No Windows, no router.) They kept saying that I was port-scanning a machine in the 10.x address space. When I finally got someone who knew enough to know that wasn't a routable address, they *still* couldn't tell me anything about the nature of the complaint. I finally had to threaten legal action, at which point they *still* refused to disclose anything about the complaint, but at least stopped calling me. The *hours* on the phone revealed only two things: the complaint was originating from somewhere in the Chicago (US) area, and the "port" I was "scanning" was always 9002. My relay was also a non-exit. Needless to say, I was monitoring my network traffic and there was no "port scanning" going on. My best guess is that some kindergartener in a sysadmin suit (or incompetent security suite vendor, if that's not redundant) configured a firewall to automatically report accesses via port 9002 as port scanning and they have a relay behind said firewall. As much as I would have welcomed the opportunity to educate and assist the operator of this misconfigured security system, my ISP would never divulge any contact information. Just a data point. --Ron > On May 3, 2020, at 14:15, wrote: > > That is really unhelpful of them to state Type of Attack/Scan: Generic > Hosts: 10.10.10.182 which is non-routable address. Something on their LAN is > wrong. You cannot even respond by blocking their actual WAN IP in torrc. > > Ask for the real WAN IP of their network so you can block the attack > > > > > -Original Message- > From: tor-relays On Behalf Of > li...@for-privacy.net > Sent: 03 May 2020 21:16 > To: tor-relays@lists.torproject.org > Subject: [tor-relays] Again: abuse email for non-exit relay (masergy) > > Hi, > > got multiple abuse in the last 2 weeks. > > 2 relays with 2 IP run on the server. Someone is always hammering my OR port > on one IP. (37.157.255.118:9002) > https://metrics.torproject.org/rs.html#details/BD2A34ADE4E603A272FAAD23AEF389801BB223BB > https://metrics.torproject.org/rs.html#details/8EE44717FA55705C12086F3ECD1F8D9C8676FD05 > > > What can I do? > > Found that in the archive: > https://lists.torproject.org/pipermail/tor-relays/2017-September/013030.html > > > the 5th complaint: > ## > > To Whom it May Concern, > > You have a system on your network that is actively scanning and/or > attacking external sites on the Internet. This can come from many > sources and because it is often difficult to detect this activity, we > are sending this E-mail in an attempt to help you solve the problem. > > We have detected your system with an IP of, 37.157.255.118, scanning a > client we monitor. This was not a short attack but a prolonged scan > and/or probe that was designed to find and intrude into the target > network. > > This may be someone on your network who is actively trying to hack > others. This person may be a legitimate user on your network or it may > be that this system has been compromised and is being used by someone to > hack others. It is also likely that the system is running automated > tools that have been installed to perform these actions without any > human intervention. > > Below is the information about the attack. Keep in mind that the source > IP of our client has been sanitized for anonymity. > > Date: 04/30/2020 > Time: 11:05:37 > Time Zone: America/Chicago > Source(s): 37.157.255.118 > Type of Attack/Scan: Generic > Hosts: 10.10.10.182 > Log: > > 37.157.255.118:9002 > 10.10.10.182:24562 > > Possible Cause: > > > Thank you for your attention to this matter, > > Masergy > email: e...@masergy.com > > -- > ╰_╯ Ciao Marco! > > Debian GNU/Linux > > It's free software and it gives you freedom! > ___ > 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] Running on a Raspberry Pi
> On Sep 9, 2019, at 19:16, William Denton wrote: > > Now I'm trying it on a Pi Four (which has four CPUs and two gigs of RAM) and > so far it's working, though it's not moving as much traffic as on the laptop. From what I have read about the Pi 4, heat is a big issue. If you're not doing something to cool it, your CPU speed is likely being throttled due to overheating. Also, I do not think that Tor will make effective use of the additional cores. I know a lot of folks run relays on Raspberry Pi devices, but I doubt they are great performers. (I run Tor on a number of Pi's, from Zero W's to 3's, but they're location hidden servers so I don't know how well they work as relays.) --Ron ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] What could cause a huge clock skew (9 days) across Tor restarts - anyone else experienced something like this?
> On Sep 7, 2019, at 04:13, s7r wrote: > > after upgrading from 0.4.1.2 to 0.4.2.0, I did an entire system > reboot because I also updated some other stuff. So the entire OS > restarted, not just Tor daemon It seems likely that your machine's hardware clock is off. During a reboot, the system will come up using the hardware clock, then (if configured to do so) eventually correct the time using NTP. You can check the hardware clock by running 'hwclock' as root. If it's off, you can set it to your (presumed accurate) system time by executing 'hwclock --systohc'. --Ron ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor relay shutsdown
> On Feb 1, 2019, at 03:01, Neelix wrote: > > Ah! This might be the problem. Tor is almost using 100% of the CPU. > Is there a way to reduce the CPU usage? Or should I upgrade the server? I would immediately suspect an overheating CPU. If the CPU cooler fan is defective, or if the heatsink compound is dried out, then the machine can shut down precipitously with no log entries. If you can open it up, make sure that the CPU heatsink fan spins freely and that the heatsink isn't clogged up with dust. If you can't open it (or are just naturally voyeuristic), on a debian-like distro you can follow these instructions to monitor the CPU temp: https://askubuntu.com/questions/15832/how-do-i-get-the-cpu-temperature --Ron ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] slow relays
> On Jan 15, 2019, at 11:15, Felix wrote: > > Just a guess: Your cpu idles and your bandwidth is underused? > Put a second relay to your ip. Fine idea! Will do. --Ron ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] slow relays
> On Jan 13, 2019, at 18:03, teor wrote: > > > On 14 Jan 2019, at 09:32, ronqtorrel...@risley.net wrote: >> >> Thanks. I'm curious what, in the consensus, suggests that I'm too far from >> the Authority Servers? I don't know how to read that page; I can't even >> figure out what units they're using to report bandwidth. > > It's a unitless amount due to scaling, but it starts as kilobytes per second. Good to know. > >> One of the relays is one hop away (via a lightly-loaded terabit switch) from >> the (formerly known as) Level3 tier 1 network, so should have excellent >> peering worldwide unless CenturyLink has degraded it since their acquisition >> last year. The other sits two or three hops (depending, apparently, on the >> phase of the moon) from the tier 1 network run by Telia. So, at least with >> my limited understanding of internet topography, they should both be >> topologically close to most hosts worldwide. > > So your guards have slightly lower than average utilisation: > 1 Mbps / 5.1 Mbps = 20% > 1.2 Mbps / 7.4 Mbps = 16% > > I wouldn't worry about it too much. Okay, I'll try to lose the inferiority complex around my bandwidth usage. Mostly trying to make sure I wasn't doing anything silly that was causing my surplus bandwidth to go to waste. > > On 14 Jan 2019, at 09:49, niftybunny wrote: > >> If you really want to know how much Tor will give you, run it as an Exit. >> Tor will love you and gives you every bit of traffic it has. Please don’t do >> this from home or if you are not sure what you are doing etc . (insert big >> fat disclaimer) Unfortunately, I can't do an exit at either of these sites. I'm actively working to line up a site that will support an exit. Thanks to you both for the information. --r ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] slow relays
Hi! Thanks. I'm curious what, in the consensus, suggests that I'm too far from the Authority Servers? I don't know how to read that page; I can't even figure out what units they're using to report bandwidth. One of the relays is one hop away (via a lightly-loaded terabit switch) from the (formerly known as) Level3 tier 1 network, so should have excellent peering worldwide unless CenturyLink has degraded it since their acquisition last year. The other sits two or three hops (depending, apparently, on the phase of the moon) from the tier 1 network run by Telia. So, at least with my limited understanding of internet topography, they should both be topologically close to most hosts worldwide. But I will admit that there is much that I don't understand about routing at this level. Again, thanks... --Ron > On Jan 13, 2019, at 11:58, niftybunny wrote: > > Looking at https://consensus-health.torproject.org/consensus-health.html my > best guess would be that you are too far away from the Authority Servers. So > your delay is too hight and the bw measurement is too low. Thats why the most > high speed relays cluster in some countries / providers. I am sure Teor could > this explain much better than I do. > > Markus > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] slow relays
> On Jan 12, 2019, at 18:32, teor wrote: > > Here are some initial steps for troubleshooting: > https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow Hi! I have been running a couple of relays for 4-5 years. In spite of following the advice in the link above, I still only average about 8Mb/s on both the relays, as reported by Nyx. D76E1FDC7A3D899282BB882F74111B36A6D14B64 56DCA89A6B41ADA30E891EF65FDCC071DC05079B Both are on 100Mb/s fiber optic lines, otherwise lightly loaded. Both have well over 99.99% uptime. They are on separate autonomous systems. One relay rarely has CPU usage above 5%. The other (on much lighter-weight hardware) approaches 40% CPU occasionally, but both have about the same reported bandwidth stats. The lines are both low-latency. Both relay boxes can sustain file transfers at close to the full 100Mb/s (or more) for extended periods of time in testing. Packet loss between the boxes is nearly zero. Testing with iperf shows full bandwidth to even disparate parts of the internet. One of the boxes is behind NAT, but with appropriate port forwarding. The other box sits directly on the net with a dedicated static IP. Both boxes are running Linux Devuan ASCII, though I saw similar numbers with vanilla Debian and Ubuntu. I haven't seen anything in the logs that indicates any problems. I don't have any bandwidth limits set in torrc. The metrics.torproject.org page shows "Advertised Bandwidth" of 7.45 MiB/s and 5.11 MiB/s respectively, but the bandwidth graphs are only rarely above 1 MiB/s. Both relays are reachable net-wide on their IPv4 addresses. I have IPv6 disabled for now. Correct addresses are showing on the directory authorities. They are the only relays on their respective IP addresses (indeed, on their respective AS's). They have seven flags on the consensus health page with what I think are reasonable bandwidth numbers (I'm not 100% sure how to interpret the "bw=4600" lines, but the number is over 4000 wherever it's reported for my relays.) So why do my relays seem to only be using about 8% of their available bandwidth? Thanks for any insight you can provide... --Ron ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Extreme Exit Policy
> On Dec 17, 2018, at 22:51, Mirimir wrote: > > And sure, I could setup .onion SSH for everything, and that'd arguably > be more secure. But sometimes I'm just too lazy for that. I'm pretty frickin' lazy, but I do this with all my servers. Here's the recipe for Linux/Debian provisioning: -*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*- # cat >>/etc/apt/sources.list deb https://deb.torproject.org/torproject.org stretch main deb-src https://deb.torproject.org/torproject.org stretch main # apt install gnupg2 dirmngr # gpg2 --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 I've had gpg2 fail, in which case this should work: # gpg --keyserver hkp://pool.sks-keyservers.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 # gpg2 --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add - # apt update # apt install tor deb.torproject.org-keyring edit /etc/tor/torrc, the "hidden services" section, to add: HiddenServiceDir /var/lib/tor/control/ HiddenServicePort 22 127.0.0.1:22 # service tor restart # cat /var/lib/tor/control/hostname Record the onion address for posterity -*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*- The SSH sessions to the .onion address seem pretty darned solid. --Ron___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor relay - impact on e-mail system reputation
> On Nov 25, 2018, at 10:10, starlight.201...@binnacle.cx wrote: > > If an IP is not on Spamhaus and not on Barracuda it > should have no problem obtaining a decent reputation. Not too many years back, I had a non-exit relay on the same IP address I use for my general home WiFi network. Mail reputation didn't seem to be affected, but I found that I was blacklisted by a number of media companies. I don't remember which ones, exactly, but services like Hulu and Netflix started giving me error messages to the effect that I was in a geographic region they didn't support (California, US). When I'd call customer support, they'd just deny that there was any problem and blame my ISP. It took quite a bit of sleuthing to figure out that the companies simply block any Tor-associated IP addresses. The impression I get is that it's deliberate and purely punitive. They see Tor as a service that might affect their bottom line (by facilitating piracy and/or getting around geographic restrictions), so they do anything they can to punish people who support it. They know perfectly well that a non-exit relay can't be used to bypass geographic restrictions, but they block them anyway out of arrogance. I moved my relay to a different IP and over the span of a month or two the blocking stopped. All of which is to say that there are certainly companies out there that *will* attack you for running a middle node. --Ron ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running A Tor Relay On Windows 10 (Was Continuing To Run A Relay On Mac OS High Sierra Via Homebrew After A New Mac OS Version Is Released)
> On Oct 4, 2018, at 23:03, Keifer Bly wrote: > > I was not able to run Debian Linux on my machine, or the new Mac OS. FWIW, I have been running various Debian-derived distros (Ubuntu and Devuan, currently) on vintage Macs since Apple switched to Intel processors (and I ran Yellow Dog for years back in the PPC days). You should be able to run it, should you want to try going down that road again. I usually use the text-based installer from an optical disc and don't install a GUI (in other words, I use the "server" distro of Ubuntu; with Devuan and vanilla Debian I think you just tell the installer that you don't want a GUI). --Ron ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Thoughts on automatically updating tor software on macos High Sierra
> On Jul 9, 2018, at 19:21, Keifer Bly wrote: > > I am attempting to find a way to do this automatically on macos High Sierra > where the process doesn’t have to be running every second. The preferred way to do this is with launchd. Basically, you create a special .plist file that defines the paramaters for the job, put it in /Library/LaunchDaemons, and use the launchctl command to activate it. Here's more info: https://www.splinter.com.au/using-launchd-to-run-a-script-every-5-mins-on/ --Ron ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] what is the Nyx "measured" bandwidth?
Thanks, but Nyx reports: > [sum:1912][~]$ nyx --version > nyx version 2.0.4 (released November 5, 2017) which, according to nyx.torproject.org, is the latest version. I sent a screenshot, but it was too big to make it to the list without moderation. --Ron > On Jul 4, 2018, at 15:00, Damian Johnson wrote: > > Hi Ron, are you sure you're using Nyx rather than the old arm > codebase? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] what is the Nyx "measured" bandwidth?
Hi! I've been running a couple of relays for 3-4 years now. They are on lightly-loaded 100MB/s fiber links. They have seven flags, lots of uptime, etc. They advertise 20Mb/s, but Nyx reports: "measured: 22.1 Kb/s" for D76E1FDC7A3D899282BB882F74111B36A6D14B64 and "measured: 28.6 Kb/s" for 56DCA89A6B41ADA30E891EF65FDCC071DC05079B The graphs Nyx displays usually show around 10Mbps (but are quite variable). The graphs on metrics.torproject.org show the bandwidth hovering around 800 K bytes/second. So why is the "measured" bandwidth from Nyx so low? --Ron ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
