Re: [tor-relays] Relay Bandwidth Limit

[Eddie]

I was never able to get the other bandwidth shaping parameters in tor to 
work how I wanted.


So, for my bandwidth limited server, I ended up loading "wondershaper" 
so I could provide a limited bandwidth continuously throughout the month 
instead of an on/off/on/off/... connection.


Cheers.


On 10/16/2023 7:15 AM, Jonathan van der Steege wrote:

Hi Dan,

Please be aware that the AccountingMax is per direction of traffic 
(in/out). So 5TB is effectively 2*5=10TB in total.
See also 
https://support.torproject.org/relay-operators/limit-total-bandwidth/
And maybe you don't want all your bandwidth used and want some traffic 
reserved for connecting/operating via ssh for example and installing 
updates during the month.
And indeed, the traffic will stop when the limit is reached or when 
all bandwidth the VPS provider gave is used.


Regards,
Jonathan



*De :*
Dan 

*Envoyé :* 16 octobre 2023 15:19:36 GMT+02:00
*À :*
"tor-relays@lists.torproject.org" 

*Objet :*
Re: [tor-relays] Relay Bandwidth Limit


“day 1 00:00”. It looks as though my relay is going to blow past that 
limit based on the average data transferred per day and how many days 
are left in the month. Will it simply stop transferring data when the 
monthly limit is hit?


Thanks



On Mon, Oct 16, 2023 at 8:17 AM, Dan mailto:On Mon, 
Oct 16, 2023 at 8:17 AM, Dan <> wrote:

Hi all,

I’ve been running my first relay for a few weeks now. The VPS 
provider I chose provides 5TB of bandwidth per month so I have set 
AccountingMax to “5 TB” and AccountingStart to



--
/ Jonathan van der Steege

My GnuPG key is: c6f32128e7522f4acb878d6a4a9f0b50ace75416


___
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] Middle relay IP blocking

[Eddie]

On 8/7/2023 1:28 PM, s7r wrote:

li...@for-privacy.net wrote:

On Samstag, 5. August 2023 08:40:42 CEST Marco Predicatori wrote:

secureh...@gmail.com wrote on 8/4/23 01:46:
I tried reporting a similar issue a few months ago (post wasn’t 
approved

by
moderator). I was running a relay from my home ISP. After a short 
while

certain websites became inaccessible from other computers in my home
network that shared the same public IP. After trial and error with 
other

IP addresses (non-Tor) I realized commercial gateway services had
blacklisted our IP address.


Same here, middle node. In order to access some sites, I have to 
shut down

briefly my modem in order to obtain a new IP, and for a while all goes
smoothly again.


Hi @all,

Just my 2 cents. Is this worth the hassle?
Calculate your power consumption 24x7x30 @home.

For 1-5$ you can get a VPS.
This exit has 1GB RAM and 1CPU and costs $3.50/month
https://metrics.torproject.org/rs.html#details/376DC7CAD597D3A4CBB651999CFAD0E77DC9AE8C 



Search or ask for offers on LEB & LET:
https://lowendbox.com/
https://lowendtalk.com/discussion/185210/tor-relay-bridge

$websearch: cheap vps unlimited bandwidth
IONOS 1,-EUR/Month - 1GB RAM - 1vCore unlimited bandwidth - prepaid 
(=no contract term)

https://www.ionos.de/server/vps

Dedicated server for $15 per month: 4 Cores/4 threads - 16GB DDR3 - 5 
usable IPv4  :-)

https://www.nocix.net/cart/?id=261


While all the above is true, a thing to remember is to make sure we 
don't end up all renting too many VPS'es or dedicated servers in the 
same places / same AS numbers - we need network diversity, it is a 
very important factor, more AS numbers, more providers, more physical 
locations, etc. So, running at home is super good and recommended from 
this perspective, provides us with the diversity we need, however not 
being to login to online banking to pay an electricity bill because of 
a middle relay is also way too annoying.. however who can afford the 
hassle should definitely run a middle relay or bridge at home (even 
Exit relay, I do run an Exit relay at my office place and I had one 
police visit in like 8 years or so).


The problem here is with the people who treat 1 IP address = 1 person, 
this assumption which is 3 decades old should disappear once and 
forever. I cannot imagine what kind of an IT/security expert would use 
a black list (haha) that contains Tor relays (double haha) and also 
applies same restrictions to *middle* relays (triple haha). There are 
so many ways to properly handle an IP address that sends 
robotic/unrequested traffic which are so obvious I'm not going to spam 
the list to enumerate them.


As much as I would like to laugh along with you, it's clearly the case 
from my experiences, and some of the folks in this thread, that there 
are some major outsourced firewall/protection companies who 
unfortunately do have the IT/security folks you can't imagine.  I've 
spoken to one senior network technician at a major US wide bank because 
after running a middle relay for 5 years with only minor issues, my wife 
who works from home for the bank was suddenly blocked from accessing the 
bank network.  He fully understood what a middle relay was and was quite 
happy for me to run one, but was unable to do anything as they had just 
outsourced the network "protection" and whoever they had outsourced to 
was classing the middle relay as a threat, and so blocking her access.


Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Metrics falsely showing my relay as offline

[Eddie]

On 8/19/2022 12:21 AM, Georg Koppen wrote:

Eddie:
I have 1 relay (40D13096BBD11AF198CE61DEE4EAECCE5472F2E7) that 
according to the metrics is always bouncing between online and 
offline, sometimes multiple times per day.  The logs show it running 
the whole time and when the metrics also show it running, the uptime 
continues to increase correctly.  This hasn't always been the case, 
as the history shows this didn't happen prior to around June based on 
the guard flag usage.  This relay is hosted at AWS if that makes any 
difference.


What are you looking at when you say "according to the metrics"? Are 
you constantly watching relay-search or is it something else we could 
look at to figure out what is going on.


Yep, metrics.torproject.org searching on a partial nickname: OhNoAnother

Should I care about this, because the relay is running correctly. 
It's just that it never gets the stable (long running) and guard 
flags any more because of this yo-yo effect, which I'm sure is 
affecting how the relay is allocated circuits.


Right. I wonder whether some directory authorities have issues 
reaching your relay sometimes resulting in the loss of flags you are 
seeing, but I have not looked at the votes for your relay since June.


That's why I added the additional information about the AWS hosting, 
which I didn't last time, in case that had a bearing.



Georg

I do have another relay (E823B5F000835A669E902EBAE5ECCB9A324F46C9) 
that sometimes exhibits the same issues, but to a much lesser 
extent.  Like it will show offline (maybe) once a month for a very 
short period and any flags lost are quickly regained.

___
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

[tor-relays] Metrics falsely showing my relay as offline

[Eddie]

I have 1 relay (40D13096BBD11AF198CE61DEE4EAECCE5472F2E7) that according 
to the metrics is always bouncing between online and offline, sometimes 
multiple times per day.  The logs show it running the whole time and 
when the metrics also show it running, the uptime continues to increase 
correctly.  This hasn't always been the case, as the history shows this 
didn't happen prior to around June based on the guard flag usage.  This 
relay is hosted at AWS if that makes any difference.


Should I care about this, because the relay is running correctly. It's 
just that it never gets the stable (long running) and guard flags any 
more because of this yo-yo effect, which I'm sure is affecting how the 
relay is allocated circuits.


I do have another relay (E823B5F000835A669E902EBAE5ECCB9A324F46C9) that 
sometimes exhibits the same issues, but to a much lesser extent.  Like 
it will show offline (maybe) once a month for a very short period and 
any flags lost are quickly regained.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] How useful are bridges on ports other than 80 and 443

[Eddie]

Unfortunately I've had to shut down my home based tor relay because my 
wife's employer is mis-categorising it as an exit node, instead of the 
middle/guard that it really is.  So, until she retires, in a few months, 
that relay will now be silent after about 5-years running (all of which 
her having the same employer.  Go figure).


So, I thought in the meantime I'd run a couple of tor bridges, as my IP 
should now be clear of any published tor node lists.


But I do need to leave ports 80 and 443 open for "normal" HTTP(S) 
traffic, which I know are the recommended bridge ports as they raise the 
least suspicion.


Are there any other ports that folks might suggest I use that would get 
enough traffic and not be blocked by a simple firewall.  I also run an 
internal mail server, so all those ports are off limits as well.


Cheers.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor bridges limit

[Eddie]

It's not a good idea to run a bridge on the same node as a relay. All 
relay IPs are published and so anyone blocking relays would block your 
bridge as well.


Cheers.


On 7/21/2022 5:20 AM, Me via tor-relays wrote:
Good day all. I am currently running two middle relays on my home 
network and was wondering if I can add any bridges to my existing set 
up. I am aware of the limit of two middle relays per ip address but do 
not see anything stating whether there was any such limit for bridges. 
I am also not clear on whether the bridges are recognized by the tor 
network in the same manner as Middle relays and whether the two unit 
limit applies to the total of devices connected.


Thank you in advance for any guidance and always remember

They are watching

___
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] Metrics shows my relay down. But it's not.

[Eddie]

The metrics is showing one of my relays 
(40D13096BBD11AF198CE61DEE4EAECCE5472F2E7) as down for around the last 3 
hours.  Logging in to it, I see everything running normally.


This server has also lost a bunch of flags for no apparent reason, so 
I'm not sure if they're connected.


Cheers.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Identifying a relay

[Eddie]

Unfortunately that option is very specifically disallowed as it's 
considered as trying to hide the source IP.


Cheers.


On 6/16/2022 1:33 AM, Gary C. New via tor-relays wrote:

Eddie,

When experiencing similar issues, the recommended solution I received, 
from this list, and that seems to work best is a VPN for affected traffic.


With dnsmasq, iptables or reverse proxy, and a dedicated split-tunnel 
vpn, I shunt affect traffic over the split-tunnel vpn without 
end-users on my local network even knowing.


Seems to work fairly well.

Best of luck.


Gary
—
This Message Originated by the Sun.
iBigBlue 63W Solar Array (~12 Hour Charge)
+ 2 x Charmast 26800mAh Power Banks
= iPhone XS Max 512GB (~2 Weeks Charged)


On Wednesday, June 15, 2022, 11:56:37 PM PDT, Eddie 
 wrote:



Have a question about how a server I connect to can tell I am running a
guard/middle relay.  All I can think of is that they check the published
list of tor nodes against the IP.  Or (maybe, but unlikely) portscan the
IP and probe any open ports to determine the service.  Are there any
other methods that can be used.

Background:  The corp my wife works for blocked our IP.  The excuse they
gave was that it was due to a change made by a vendor they use to
identify malicious IP addresses.  I have been running the relay for
almost 5 years without any previous flagging.  They also state that
running a middle relay is not in violation of any policy, but the vendor
mis-identified our relay as an exit, hence blocking it.

After changing the IP, the new IP was also blocked in less than 24
hours.  My feeling is that the vendor is now just using the full list of
tor nodes and indiscriminately blocking everything, despite what the
corp security folks say.

I'm looking for some sort of validation I can use to counter their claims.
___
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

[tor-relays] Identifying a relay

[Eddie]

Have a question about how a server I connect to can tell I am running a 
guard/middle relay.  All I can think of is that they check the published 
list of tor nodes against the IP.  Or (maybe, but unlikely) portscan the 
IP and probe any open ports to determine the service.  Are there any 
other methods that can be used.


Background:  The corp my wife works for blocked our IP.  The excuse they 
gave was that it was due to a change made by a vendor they use to 
identify malicious IP addresses.  I have been running the relay for 
almost 5 years without any previous flagging.  They also state that 
running a middle relay is not in violation of any policy, but the vendor 
mis-identified our relay as an exit, hence blocking it.


After changing the IP, the new IP was also blocked in less than 24 
hours.  My feeling is that the vendor is now just using the full list of 
tor nodes and indiscriminately blocking everything, despite what the 
corp security folks say.


I'm looking for some sort of validation I can use to counter their claims.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Loss of Guard and HS Dir flags

[Eddie]

Necro alert !!

Again, the same server has exhibited the same thing.  It has lost the 
Guard, HS Dir, and Long-Lived (Stable) flags, despite being up for 
almost 5 months with no reduction in Bandwidth.


Cheers.


On 10/18/2021 9:42 PM, Eddie wrote:

On 10/18/2021 1:03 AM, Georg Koppen wrote:

Eddie:

On 10/13/2021 11:29 PM, Eddie wrote:

I currently run 3 relays, across different servers and today I noticed
that one has now lost it's Guard and HS Dir flags.  What's surprising
is that this particular relay has the highest Bandwidth and Consensus
Weight of all 3 and has not been restarted for over a month.

The stats for all 3 can be found with:  OhNoAnotherRelay

I know that just running the relay is the important part and caring
about what flags it has is a side issue, but I'm just interested in
seeing why this has happened.

Cheers.

Now the relay has lost the Long-Lived Circuits flag despite showing an
up-time of 34 days.

You mean the Stable flag? Seems to be back now at least. I've filed a
ticket[1], though, to look a bit closer at what is going on but am not
sure how fast we get to that (help is welcomed!).

And the Stable flag has gone again.

There's something strange going on here.

Maybe. :)

Georg

[1] https://gitlab.torproject.org/tpo/network-health/team/-/issues/128



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


--
This e-mail was checked for spam by the freeware edition of CleanMail.
The freeware edition is restricted to personal and non-commercial use.
You can remove this notice by purchasing a commercial license:
http://antispam.byteplant.com/products/cleanmail/index.html


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Possible Connection Storm

[Eddie]

Checking my relays after being away for a few days, noticed that one of 
them was showing as Overloaded, which I've never seen in over a year's 
running.


Looking in the logs, it looks like there was a huge increase in 
connections, which has now settled down and I'm no longer showing as 
overloaded.  Here's some relevant pieces:


Apr 21 03:45:08.000 [notice] Heartbeat: Tor's uptime is 110 days 12:00 
hours, wi
th 6977 circuits open. I've sent 5236.04 GB and received 5121.19 GB. 
I've receiv
ed 5232797 connections on IPv4 and 269395 on IPv6. I've made 2018765 
connections

 with IPv4 and 580408 with IPv6.
Apr 21 03:45:08.000 [notice] Circuit handshake stats since last time: 
1901/1901

TAP, 244943/244943 NTor.

Apr 21 07:04:49.000 [warn] Your computer is too slow to handle this many 
circuit
 creation requests! Please consider using the MaxAdvertisedBandwidth 
config opti

on or choosing a more restricted exit policy.

Apr 21 09:45:08.000 [notice] Heartbeat: Tor's uptime is 110 days 18:00 
hours, wi
th 47998 circuits open. I've sent 5263.73 GB and received 5148.85 GB. 
I've recei
ved 5244063 connections on IPv4 and 270025 on IPv6. I've made 2021914 
connection

s with IPv4 and 581488 with IPv6.
Apr 21 09:45:08.000 [notice] Circuit handshake stats since last time: 
1609/1609

TAP, 6391488/6532508 NTor.

Apr 21 15:45:08.000 [notice] Heartbeat: Tor's uptime is 111 days 0:00 
hours, wit
h 45439 circuits open. I've sent 5300.03 GB and received 5185.19 GB. 
I've receiv
ed 5253283 connections on IPv4 and 270537 on IPv6. I've made 2024515 
connections

 with IPv4 and 582464 with IPv6.
Apr 21 15:45:08.000 [notice] Circuit handshake stats since last time: 
467/467 TA

P, 9937327/9984534 NTor.

Is this anything I need to be concerned about, or is it just one of 
things that occasionally happens.


Cheers.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Moving Bridges

[Eddie]

One of my bridges has just taken on a slew of new connections.  Over the 
last few days it's gone from an average of around 15 users to over 300 
(according to tor metrics.  The logs show over 1,000 unique clients for 
the same period).  Unfortunately with the VPS provider I'm using, this 
isn't sustainable as I'll probably blow my bandwidth allowance in a 
matter of days and the excess charges are crazy.


So I'm looking to move both my bridges to a new VPS, which unfortunately 
is probably going to p!ss off the 300 plus folks who have just found my 
bridge only for it to promptly disappear, as I'm certain that there's no 
way to "move" them to the new location and have a couple of questions.


I'm guessing that the only advantage in copying over the keys directory 
is that the historical statistics will remain.


Is there any reason to copy over the pt_state directory, to retain the 
same bridgeline information.


Cheers.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bridge showing offline

[Eddie]

This has now happened again, on the same bridge, showing off-line to the 
metrics, but the logs showing it running with activity taking place.


Guess I'll keep an eye on the metrics to see if it pops back to available.

I'm wondering how often this might be happening, because I don't check 
the metrics that often and the instance documented below didn't change 
the Uptime or Last Restart to indicate anything had happened.  So unless 
I notice while it's in this state, like now, I have no way of knowing if 
it happens regularly or not.


Cheers.




On 10/14/2021 12:11 PM, Eddie wrote:

On 10/14/2021 2:44 AM, Bleedangel Tor Admin wrote:
You are running 0.4.5.8, maybe updating to a newer version of tor 
will help?


Sent from ProtonMail for iOS


On Thu, Oct 14, 2021 at 03:02, Georg Koppen  wrote:

Eddie:
> Looking at tor metrics, one of my bridges is showing as off-line:
> B080140DC1BAB5B86D1CE5A4CA2EF64F20282440
>
> However, the log isn't showing any issues:
>
> Oct 14 00:00:28.000 [notice] Tor 0.4.5.8 opening new log file.
> Oct 14 00:00:28.000 [notice] Configured hibernation. This interval
> began at 2021-10-14 00:00:00; the scheduled wake-up time was 
2021-10-14

> 00:00:00; we expect to exhaust our quota for this interval around
> 2021-10-15 00:00:00; the next interval begins at 2021-10-15 00:00:00
> (all times local)
> Oct 14 01:49:40.000 [notice] Heartbeat: Tor's uptime is 124 days 6:00
> hours, with 0 circuits open. I've sent 907.23 GB and received 
922.28 GB.

> I've received 63052 connections on IPv4 and 8375 on IPv6. I've made
> 512684 connections with IPv4 and 100974 with IPv6.
> Oct 14 01:49:40.000 [notice] While not bootstrapping, fetched this 
many

> bytes: 1801791624 (server descriptor fetch); 175792 (server descriptor
> upload); 221750347 (consensus network-status fetch); 10974 (authority
> cert fetch); 19905655 (microdescriptor fetch)
> Oct 14 01:49:40.000 [notice] Heartbeat: Accounting enabled. Sent: 
140.52

> MB, Received: 140.69 MB, Used: 281.21 MB / 200.00 GB, Rule: sum. The
> current accounting interval ends on 2021-10-15 00:00:00, in 22:10 
hours.
> Oct 14 01:49:40.000 [notice] Heartbeat: In the last 6 hours, I 
have seen

> 14 unique clients.
>
> Initially I thought of a previous issue I had with IPv6 connectivity,
> but don't think this is the problem here as the 2nd bridge on the same
> server is showing on-line.  Also an IPv6 port scan shows the ports for
> both bridges as accessible.
>
> Ideas ??

I wonder whether that is another instance
https://gitlab.torproject.org/tpo/core/tor/-/issues/40424. Hard to tell,
though. Does that issue happen regularly?

Georg

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


I didn't touch anything, and this morning the metrics say the bridge 
is running normally, with an uptime of over 125 days.


Looks like it might have been a metrics issue, not the bridge itself.

Cheers.


___
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] Relay MIGHTYWANG consensus issues and loss of STABLE flag

[Eddie]

Welcome to the club: 
https://gitlab.torproject.org/tpo/network-health/team/-/issues/128


Since Georg opened that (on my behalf) I too have lost the Stable flag.

Cheers.


On 10/29/2021 9:10 AM, Mighty Wang wrote:


Hello fellow operators


I have one pretty large relay, MIGHTYWANG which is an IP4/6 guard, 
dedicated hardware running on a 1Gb line uncontended. It is usually 
one of the top 5 relays by consensus weight but on the morning of 14th 
October it lost Guard status on account of losing the stable flag.


I checked logs, connectivity and server health - nothing unusual, 
everything is generally pretty bullet proof in and around the relay 
and it had been running for well over a year without a reboot - just 
the very occasional Tor daemon restart following upgrades but no such 
activity prior to the 14th.


So next I checked the consensus and I see that around half of the 
directory authorities seem to be not assigning the stable flag. See 
attached screenshot showing current consensus.


The peering to each of those relays seems OK from what I can see (IP4 
and IP6) so any idea what gives?


I've got a MIGHTYWANG sitting here twiddling it's thumbs because have 
the directory authorities don't want to use it. Bit of a waste.


I had similar things happen a few years ago with one of my old relays; 
again no obvious reason, just seemed to be the a random whim of the 
directory authorities.


I've noticed a couple of other long term relays are in a similar 
position - is this some time of attack, deliberate action or just Tor 
magic?



Wang


--
MIGHTYWANG 9B2BC7EFD661072AFADC533BE8DCF1C19D8C2DCC

___
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] Loss of Guard and HS Dir flags

[Eddie]

On 10/18/2021 1:03 AM, Georg Koppen wrote:

Eddie:

On 10/13/2021 11:29 PM, Eddie wrote:

I currently run 3 relays, across different servers and today I noticed
that one has now lost it's Guard and HS Dir flags.  What's surprising
is that this particular relay has the highest Bandwidth and Consensus
Weight of all 3 and has not been restarted for over a month.

The stats for all 3 can be found with:  OhNoAnotherRelay

I know that just running the relay is the important part and caring
about what flags it has is a side issue, but I'm just interested in
seeing why this has happened.

Cheers.

Now the relay has lost the Long-Lived Circuits flag despite showing an
up-time of 34 days.

You mean the Stable flag? Seems to be back now at least. I've filed a
ticket[1], though, to look a bit closer at what is going on but am not
sure how fast we get to that (help is welcomed!).

And the Stable flag has gone again.

There's something strange going on here.

Maybe. :)

Georg

[1] https://gitlab.torproject.org/tpo/network-health/team/-/issues/128



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] What is: Channel padding timeout scheduled

[Eddie]

Noticed that one of my relays (OhNoAnotherRelay02) is showing as 
off-line.  Looking at the logs, I see a bunch of these messages:


Oct 18 08:39:16.000 [notice] Channel padding timeout scheduled 143041ms 
in the past.
Oct 18 08:39:21.000 [notice] Channel padding timeout scheduled 156925ms 
in the past.
Oct 18 08:39:24.000 [notice] Channel padding timeout scheduled 168712ms 
in the past.
Oct 18 08:39:25.000 [notice] Channel padding timeout scheduled 166895ms 
in the past.

.
.
.
Oct 18 10:18:48.000 [notice] Channel padding timeout scheduled 194581ms 
in the past.
Oct 18 10:35:22.000 [notice] Channel padding timeout scheduled 216311ms 
in the past.
Oct 18 10:35:30.000 [notice] Channel padding timeout scheduled 224267ms 
in the past.


What's the cause of this.

I used this downtime as an excuse to do a bunch of upgrades and a re-boot.

Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Loss of Guard and HS Dir flags

[Eddie]

On 10/13/2021 11:29 PM, Eddie wrote:
I currently run 3 relays, across different servers and today I noticed 
that one has now lost it's Guard and HS Dir flags.  What's surprising 
is that this particular relay has the highest Bandwidth and Consensus 
Weight of all 3 and has not been restarted for over a month.


The stats for all 3 can be found with:  OhNoAnotherRelay

I know that just running the relay is the important part and caring 
about what flags it has is a side issue, but I'm just interested in 
seeing why this has happened.


Cheers.


Now the relay has lost the Long-Lived Circuits flag despite showing an 
up-time of 34 days.


There's something strange going on here.

Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bridge showing offline

[Eddie]

On 10/14/2021 2:44 AM, Bleedangel Tor Admin wrote:
You are running 0.4.5.8, maybe updating to a newer version of tor will 
help?


Sent from ProtonMail for iOS


On Thu, Oct 14, 2021 at 03:02, Georg Koppen <mailto:g...@torproject.org>> wrote:

Eddie:
> Looking at tor metrics, one of my bridges is showing as off-line:
> B080140DC1BAB5B86D1CE5A4CA2EF64F20282440
>
> However, the log isn't showing any issues:
>
> Oct 14 00:00:28.000 [notice] Tor 0.4.5.8 opening new log file.
> Oct 14 00:00:28.000 [notice] Configured hibernation.  This interval
> began at 2021-10-14 00:00:00; the scheduled wake-up time was 2021-10-14
> 00:00:00; we expect to exhaust our quota for this interval around
> 2021-10-15 00:00:00; the next interval begins at 2021-10-15 00:00:00
> (all times local)
> Oct 14 01:49:40.000 [notice] Heartbeat: Tor's uptime is 124 days 6:00
> hours, with 0 circuits open. I've sent 907.23 GB and received 
922.28 GB.

> I've received 63052 connections on IPv4 and 8375 on IPv6. I've made
> 512684 connections with IPv4 and 100974 with IPv6.
> Oct 14 01:49:40.000 [notice] While not bootstrapping, fetched this many
> bytes: 1801791624 (server descriptor fetch); 175792 (server descriptor
> upload); 221750347 (consensus network-status fetch); 10974 (authority
> cert fetch); 19905655 (microdescriptor fetch)
> Oct 14 01:49:40.000 [notice] Heartbeat: Accounting enabled. Sent: 
140.52

> MB, Received: 140.69 MB, Used: 281.21 MB / 200.00 GB, Rule: sum. The
> current accounting interval ends on 2021-10-15 00:00:00, in 22:10 
hours.
> Oct 14 01:49:40.000 [notice] Heartbeat: In the last 6 hours, I have 
seen

> 14 unique clients.
>
> Initially I thought of a previous issue I had with IPv6 connectivity,
> but don't think this is the problem here as the 2nd bridge on the same
> server is showing on-line.  Also an IPv6 port scan shows the ports for
> both bridges as accessible.
>
> Ideas ??

I wonder whether that is another instance
https://gitlab.torproject.org/tpo/core/tor/-/issues/40424. Hard to tell,
though. Does that issue happen regularly?

Georg

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


I didn't touch anything, and this morning the metrics say the bridge is 
running normally, with an uptime of over 125 days.


Looks like it might have been a metrics issue, not the bridge itself.

Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Loss of Guard and HS Dir flags

[Eddie]

I currently run 3 relays, across different servers and today I noticed 
that one has now lost it's Guard and HS Dir flags.  What's surprising is 
that this particular relay has the highest Bandwidth and Consensus 
Weight of all 3 and has not been restarted for over a month.


The stats for all 3 can be found with:  OhNoAnotherRelay

I know that just running the relay is the important part and caring 
about what flags it has is a side issue, but I'm just interested in 
seeing why this has happened.


Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Bridge showing offline

[Eddie]

Looking at tor metrics, one of my bridges is showing as off-line: 
B080140DC1BAB5B86D1CE5A4CA2EF64F20282440


However, the log isn't showing any issues:

Oct 14 00:00:28.000 [notice] Tor 0.4.5.8 opening new log file.
Oct 14 00:00:28.000 [notice] Configured hibernation.  This interval 
began at 2021-10-14 00:00:00; the scheduled wake-up time was 2021-10-14 
00:00:00; we expect to exhaust our quota for this interval around 
2021-10-15 00:00:00; the next interval begins at 2021-10-15 00:00:00 
(all times local)
Oct 14 01:49:40.000 [notice] Heartbeat: Tor's uptime is 124 days 6:00 
hours, with 0 circuits open. I've sent 907.23 GB and received 922.28 GB. 
I've received 63052 connections on IPv4 and 8375 on IPv6. I've made 
512684 connections with IPv4 and 100974 with IPv6.
Oct 14 01:49:40.000 [notice] While not bootstrapping, fetched this many 
bytes: 1801791624 (server descriptor fetch); 175792 (server descriptor 
upload); 221750347 (consensus network-status fetch); 10974 (authority 
cert fetch); 19905655 (microdescriptor fetch)
Oct 14 01:49:40.000 [notice] Heartbeat: Accounting enabled. Sent: 140.52 
MB, Received: 140.69 MB, Used: 281.21 MB / 200.00 GB, Rule: sum. The 
current accounting interval ends on 2021-10-15 00:00:00, in 22:10 hours.
Oct 14 01:49:40.000 [notice] Heartbeat: In the last 6 hours, I have seen 
14 unique clients.


Initially I thought of a previous issue I had with IPv6 connectivity, 
but don't think this is the problem here as the 2nd bridge on the same 
server is showing on-line.  Also an IPv6 port scan shows the ports for 
both bridges as accessible.


Ideas ??

Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Move or Recreate

[Eddie]

I'm thinking of switching a couple of the VPS servers I have, where I'm 
running both relays and bridges.  (On separate VPSs, obviously).


I know how to maintain the keys for both relays and bridges for the 
replacements, but was wondering exactly what does that buy me, as both 
will now be running at different IPv4/6 addresses.


As opposed to just blowing away the current ones and starting fresh copies.

Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Is my node dropping packets?

[Eddie]

On 7/29/2021 7:57 AM, Marco Predicatori wrote:

Hi, my Tor node is inside a local network protected by a firewall. Only port 
9001
is NATted towards the Tor server.
Moreover, I have iptables active on the Tor server itself. The outer firewall
blocks any incoming packet except for packets on port 9001 and returning packets
from established connections.

My iptables blocks several packets which were allowed through by the outer 
firewall,
where I assume they are recognized as returning packets from established
connections. Then my local iptables drops them. I can't understand why.

You can find here an extract from my Tor node "iptables -L -n" and a typical
day's log of dropped packets on the Tor node:
https://easyupload.io/m/48if5l

Many packets coming from other Tor nodes where dropped. The Tor log doesn't 
mention
any problem. What may be wrong?

--


Not that it helps any, but I see exactly the same scenario on my system 
as well.  It averages about 200 dropped packets per day.


Cheers.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] tor fails on start-up after yum update

[Eddie]

Running a CentOS 7.9 system, pulling tor updates from 
https://rpm.torproject.org/centos/$releasever/$basearch


The last 2 times that tor has been yum updated, the restart of the 
service has just stopped, at exactly the same point:


Jun 18 06:46:50.000 [notice] Tor 0.4.6.5 opening log file.
Jun 18 06:46:50.830 [notice] We compiled with OpenSSL 100020bf: OpenSSL 
1.0.2k  26 Jan 2017 and we are running with OpenSSL 100020bf: 
1.0.2k-fips. These two versions should be binary compatible.
Jun 18 06:46:50.831 [notice] Tor 0.4.6.5 running on Linux with Libevent 
2.0.21-stable, OpenSSL 1.0.2k-fips, Zlib 1.2.7, Liblzma 5.2.2, Libzstd 
1.5.0 and Glibc 2.17 as libc.
Jun 18 06:46:50.831 [notice] Tor can't help you if you use it wrong! 
Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 18 06:46:50.831 [notice] Read configuration file 
"/usr/share/tor/defaults-torrc".

Jun 18 06:46:50.831 [notice] Read configuration file "/etc/tor/torrc".
Jun 18 06:46:50.833 [notice] Based on detected system memory, 
MaxMemInQueues is set to 6342 MB. You can override this by setting 
MaxMemInQueues by hand.
Jun 18 06:46:50.833 [notice] You configured a non-loopback address 
'192.168.0.254:9100' for SocksPort. This allows everybody on your local 
network to use your machine as a proxy. Make sure this is what you wanted.

Jun 18 06:46:50.833 [notice] Opening Socks listener on 192.168.0.254:9100
Jun 18 06:46:50.833 [notice] Opened Socks listener connection (ready) on 
192.168.0.254:9100

Jun 18 06:46:50.833 [notice] Opening Control listener on 127.0.0.1:9051
Jun 18 06:46:50.833 [notice] Opened Control listener connection (ready) 
on 127.0.0.1:9051

Jun 18 06:46:50.833 [notice] Opening OR listener on 0.0.0.0:9001
Jun 18 06:46:50.834 [notice] Opened OR listener connection (ready) on 
0.0.0.0:9001

Jun 18 06:46:50.834 [notice] Opening Directory listener on 0.0.0.0:9030
Jun 18 06:46:50.834 [notice] Opened Directory listener connection 
(ready) on 0.0.0.0:9030

Jun 18 06:46:51.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.

Starting the service then it starts correctly.  I also couldn't see 
anything out of the ordinary in the main system logs, other than it 
echoing the above.


Any ideas on what's going on here.

Also, what is the correct setting for systemctl enable/disable 
tor/tor-master  (I don't have any tor@ services), because I get 
inconsistent results using tor-master.  Issuing "systemctl stop 
tor-master" will stop the accompanying tor instance, but "systemctl 
start tor-master" doesn't start it, but a "systemctl restart tor-master" 
does do a stop/start.  I haven't had time to experiment with what 
happens on a re-boot (yet).


Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help with running a Tor Bridge

[Eddie]

You might want to add "IPv4Only" to ORPort.

Cheers.


On 5/16/2021 12:49 AM, Cor.ling wrote:


Hi, I have set up a bridge on Kubuntu following this guide: 
https://community.torproject.org/relay/setup/bridge/debian-ubuntu/ 

In TODO1 I put: 443 and in TODO2: 80 (I used these values only because 
they were in the example).


But in my log (/var/log/syslog) I'm seeing these errors:
Tor[X]: Your server has not managed to confirm reachability for its 
ORPort(s) at X.X.X.X:443. Relays do not publish descriptors until 
their ORPort and DirPort are reachable. Please check your firewalls, 
ports, address, /etc/hosts file, etc.
Tor[X]: Unable to find IPv6 address for ORPort 443. You might want to 
specify IPv4Only to it or set an explicit address or set Address. [60 
similar message(s) suppressed in last 3600 seconds]


How can I resolve them? And also: how can I enable IPv6?



___
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] OS Upgrade

[Eddie]

On 4/23/2021 11:50 AM, The Doctor [412/724/301/703/415/510] wrote:

‐‐‐ Original Message ‐‐‐
On Friday, April 23, 2021 2:01 AM,  wrote:


  Ubuntu 20.4 on my Digital Ocean droplet needs to be upgraded.

  Can the upgrade be done without shutting down the relay. I
  currently have six flags and don't want to loose them. How
  is the upgrade done on a relay that is in operation?

Yes, it can.  I've done it several times on D-O- (Ubuntu 16.04 LTS to Ubuntu 
18.04 LTS to
Ubuntu 20.04 LTS).  Use Digital Ocean's dist-upgrade and distro-upgrade docs 
and you should
be okay.  Take your time, there's no rush.


And you're left with programs running on a back-level version of libc 
and a very out-of-date kernel.




Just be sure to back up your tor config file and contents of /var/lib/tor, just 
in case
something goes pear-shaped.

The Doctor [412/724/301/703/415/510]
WWW: https://drwho.virtadpt.net/
The old world is dying, and the new world struggles to be born. Now is the time 
of monsters.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


--
This e-mail was checked for spam by the freeware edition of CleanMail.
The freeware edition is restricted to personal and non-commercial use.
You can remove this notice by purchasing a commercial license:
http://antispam.byteplant.com/products/cleanmail/index.html


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Is OVH a safe vps provider to run an exit relay on?

[Eddie]

William,

At (about) what number of relays per provider should we be considering 
looking elsewhere.


Cheers.



On 4/1/2021 12:53 AM, William Kane wrote:

Hi,

no, OVH is the second most commonly used hosting provider, another
relay hosted there would hurt the network more than it would help:

https://metrics.torproject.org/bubbles.html#as

We need to make the network as diverse as possible, in order to make
it as hard as possible for law enforcement and other bad actors to
de-anonymize tor circuits.

--Very large snip snip--

Look for a host, get it's AS ID, then input it here:
https://metrics.torproject.org/rs.html#search/as:

Example:

https://metrics.torproject.org/rs.html#search/as:AS197019

If this was a bit too much, I apologize - I will gladly answer any
questions you have.

- William

On 30/03/2021, Keifer Bly  wrote:

Hi,



I am wondering if OVH is a safe VPS provider to run an exit relay on? Thank
you.



--Keifer



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


--
This e-mail was checked for spam by the freeware edition of CleanMail.
The freeware edition is restricted to personal and non-commercial use.
You can remove this notice by purchasing a commercial license:
http://antispam.byteplant.com/products/cleanmail/index.html


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] bridge static or dynamic ip and multiple bridge config

[Eddie]

But one that keeps changing IP will get very little, if any, traffic, 
based on how bridge information is distributed.


Cheers.

On 3/31/2021 2:19 PM, Volker Mink wrote:

Bridge does not require static ip. You can run one at home.
More than one —> use different ports


Am 31.03.2021 um 22:14 schrieb gi vi an :

does bridge require static or dynamic ip?

if more than one bridge can be configured per one isp connection, how do i 
configure?

--
who am i ? https://mstdn.social/@gvian

donate or patron:
[+]₿ bitcoin (BTC): 3K7Ba2DFyyuGTukNqXEmogG4VgYp2RWnZV
[×]gridcoin (GRC): SK7A2yq4rsoDSKc592dxSb3JSYeSSopbNB
[÷]Ᵽ peercoin (PPC): PENnyj6dvEqaAKtqh9tV9KzRKc4N5EWfeH
[=]pivx (PIVX): DNyihy8xWXkGyaLnipzWUrC3kjrbcvahHJ
[<]blackcoin (BC): B4pCYCRhS6itEs2rsSAVbRnoKkL6thj3Bt
___
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


--
This e-mail was checked for spam by the freeware edition of CleanMail.
The freeware edition is restricted to personal and non-commercial use.
You can remove this notice by purchasing a commercial license:
http://antispam.byteplant.com/products/cleanmail/index.html


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Thoughts and insight before bridge moving

[Eddie]

As well as the keys, be sure to also move/copy the pt_state folder and 
contents.


Cheers.


On 3/8/2021 8:07 AM, William Kane wrote:

Hi,

Every bridge is useful, and a possible chance for a tor user to
circumvent censorship, you can't possibly know which bridges are
already blocked for a user, so every bridge in the network counts  -
looking at your graphs, on average 50 people are connected to it,
compared to other bridges, that's a lot of users - if you move your
bridge, make sure to keep / back up the private signing keys, the
bridge related data (it's a separate folder inside the DataDirectory)
and if possible, the IP address it's running under, if you lose either
of them, you will lose all your clients which trust and possibly rely
on you, the bridge operator, to continue operations.

More information on moving tor nodes can be found here:
https://2019.www.torproject.org/docs/faq.html.en#UpgradeOrMove

Regards,
William

2021-03-07 10:35 GMT, a tor op :

Hello

I was thinking of perhaps asking and checking if the list has some comments
on thoughts I have.

I'm attaching a picture, hope that's not a problem, guess it's better than
providing a URL to a file upload place (or maybe that's ok too?).

I've been running a TOR bridge node for some years and need to rebuild/move
it.

For some time I wasn't sure how useful it was, whether or not it contributed
in a useful way and I don't think it still has all the flags it could/should
have?

So, for you around here with an even deeper experience of the network,
looking at the stats, are there any particular insights that can be drawn
from there? Is it a useful bridge, stats that could or should look
differently, anything else?

BTW, there's a huge spike in connections on 9 Aug -20 (and there's been
similar occasions earlier too) does that coincide with known attacks on the
network or what?

I guess, should I want to continue providing service, that it's useful or
possibly preferred to move over the keys/config (?) to indicate same admin
(and for users if there's no noticeable interruption the move won't even be
noticed I suppose).


TIA,
a tor op



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


--
This e-mail was checked for spam by the freeware edition of CleanMail.
The freeware edition is restricted to personal and non-commercial use.
You can remove this notice by purchasing a commercial license:
http://antispam.byteplant.com/products/cleanmail/index.html


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bridge operator iat_mode setting

[Eddie]

On 2/24/2021 12:34 PM, William Kane wrote:

Thank you for running obfs4 bridges with iat_mode != 0, only very few
obfs4 bridges support the additional traffic obfuscation in both
directions.

Kudos to you my friend.

- William
Should I take this as a recommendation to update my bridges to support 
iat_mode=2.


Cheers.

2021-02-23 1:18 GMT, torjoy :

Hi All,

I work with time and frequency references and run some tor bridges. What is
the objective of "iat_mode" setting? Is an good timming reference important
for this setting? For now, i'm adminstrating 3 briges, one with iat_mode=0,
iat_mode=1 and iat_mode=2.
Could you explain or forward me to some reading about it?

Best regards,

Luiz

Sent with [ProtonMail](https://protonmail.com) Secure Email.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


--
This e-mail was checked for spam by the freeware edition of CleanMail.
The freeware edition is restricted to personal and non-commercial use.
You can remove this notice by purchasing a commercial license:
http://antispam.byteplant.com/products/cleanmail/index.html


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Stable flag and client load

[Eddie]

On 2/21/2021 7:16 PM, enrollado wrote:
I am running a bridge, realseven, fingerprint 
10B5293C71793DC1E56A5B17434C0539F70FBB38. It's been up for 71 days and 
has yet to get the stable flag or more than 3 or 4 connected clients. 
Is there something misconfigured?



Bridges don't get the stable flag AFAIK, only running and valid.

Depending on the distribution method for your bridge, only a handful of 
clients could be quite normal.


Cheers.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Huge increase in bridge connections

[Eddie]

Just trying to understand if this is normal or if something else is 
going on.
I have 2 bridges on a VPS.  One is designated as "moat", the other 
"email".  Until earlier today, for over a year, both averaged under 10 
unique clients, per 6-hour reporting period.
Today, the "moat" bridge, in a single period went from single digits to 
almost 300 unique clients.  Is this normal/possible or what other 
explanation could there be.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Can't connect to bridge after rebuilding server

[Eddie]

OK, I *CAN* connect to the 443 port bridge using the new cert and the 
original fingerprint, just like port 80.  So I'm not sure why the bridge 
status page reports what it does.


So, my question is still, is there a way to get my new configuration to 
rebuild itself to use the previous certs.


Cheers.


On 2/8/2021 10:30 PM, Roger Dingledine wrote:

On Mon, Feb 08, 2021 at 06:58:55PM -0800, Eddie wrote:

Following the rebuild, the bridges
appear to start correctly, according to both the logs and
https://metrics.torproject.org/rs.html#search/OhNoAnotherBridge. However
attempting to connect via the tor browser from my home system just hangs.

The ports on the VPS are open.  I can see an ESTABLISHED connection from
home, but the browser just hangs throwing out this:  [WARN] Proxy Client:
unable to connect to aaa.bbb.ccc.ddd:443 ("general SOCKS server failure")

Not sure what to check next.

It looks like the "vanilla ORPort" part of your bridge works (I just
bootstrapped my Tor through it to confirm), but your obfs4 port is
busted somehow:
https://bridges.torproject.org/status?id=8BBAB62EA65E47CDF204E3D795DAD12E5046EB72
https://lists.torproject.org/pipermail/tor-relays/2021-January/019221.html

I wonder if, when you restored things, you also restored the obfs4
keys?

It looks like OhNoAnotherBridge80 is doing better?
https://bridges.torproject.org/status?id=B080140DC1BAB5B86D1CE5A4CA2EF64F20282440

--Roger

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


--
This e-mail was checked for spam by the freeware edition of CleanMail.
The freeware edition is restricted to personal and non-commercial use.
You can remove this notice by purchasing a commercial license:
http://antispam.byteplant.com/products/cleanmail/index.html


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Can't connect to bridge after rebuilding server

[Eddie]

Ha.  I copied the complete keys directory from my old configuration to 
the new, hoping everything would be the same.  But I didn't realise that 
the cert used in the connection string would now be different.  Using 
the new cert and original fingerprint I can now connect over the port 80 
bridge.  Is there any way to revert back to the original cert, so that 
the folks who already have the bridge configured can use it as they 
always have.


Let me look at what might be wrong with the 443 port, but I did exactly 
the same "shift and drop" technique for both the bridges.


Cheers.

On 2/8/2021 10:30 PM, Roger Dingledine wrote:

On Mon, Feb 08, 2021 at 06:58:55PM -0800, Eddie wrote:

Following the rebuild, the bridges
appear to start correctly, according to both the logs and
https://metrics.torproject.org/rs.html#search/OhNoAnotherBridge. However
attempting to connect via the tor browser from my home system just hangs.

The ports on the VPS are open.  I can see an ESTABLISHED connection from
home, but the browser just hangs throwing out this:  [WARN] Proxy Client:
unable to connect to aaa.bbb.ccc.ddd:443 ("general SOCKS server failure")

Not sure what to check next.

It looks like the "vanilla ORPort" part of your bridge works (I just
bootstrapped my Tor through it to confirm), but your obfs4 port is
busted somehow:
https://bridges.torproject.org/status?id=8BBAB62EA65E47CDF204E3D795DAD12E5046EB72
https://lists.torproject.org/pipermail/tor-relays/2021-January/019221.html

I wonder if, when you restored things, you also restored the obfs4
keys?

It looks like OhNoAnotherBridge80 is doing better?
https://bridges.torproject.org/status?id=B080140DC1BAB5B86D1CE5A4CA2EF64F20282440

--Roger

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


--
This e-mail was checked for spam by the freeware edition of CleanMail.
The freeware edition is restricted to personal and non-commercial use.
You can remove this notice by purchasing a commercial license:
http://antispam.byteplant.com/products/cleanmail/index.html


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Can't connect to bridge after rebuilding server

[Eddie]

I had to rebuild my VPS today.  Before doing so, I copied off everything 
I thought I needed to rebuild my bridges.  Following the rebuild, the 
bridges appear to start correctly, according to both the logs and 
https://metrics.torproject.org/rs.html#search/OhNoAnotherBridge. However 
attempting to connect via the tor browser from my home system just hangs.


The ports on the VPS are open.  I can see an ESTABLISHED connection from 
home, but the browser just hangs throwing out this:  [WARN] Proxy 
Client: unable to connect to aaa.bbb.ccc.ddd:443 ("general SOCKS server 
failure")


Not sure what to check next.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Wildly Different BandWidth Numbers

[Eddie]

Looking at the consensus health page for my relay 
D195E5CE8AE77BAC91673E6CFB7BD0AF57281646), I see wildly different values 
for bandwidth:


bw=3060
bw=910
bw=340
bw=620
bw=5130

Why is there such a discrepancy.  I'm guessing this has something to do 
with my relay bouncing in and out of Guard status on a regular basis 
(which I'm sure can't be a good thing).


Is there anything I can do to maintain a consistent value, be it at one 
end of the scale or the other.


Cheers.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Could Zoom be using the wrong dan-tor blacklist

[Eddie]

Gus,

It's "OnNoNotAnotherTorRelay";

D195E5CE8AE77BAC91673E6CFB7BD0AF57281646

Cheers.

On 9/9/2020 7:44 PM, gus wrote:

Hi Eddie,

Could you inform your relay fingerprint?

Thanks,
Gus

On Mon, Sep 07, 2020 at 11:54:47AM -0700, Eddie wrote:

Starting yesterday (maybe Saturday) we have been unable to initiate any Zoom
calls.  They just sit "connecting".  According to Zoom, there are no issues
that would lead to this.

My investigation, traces I have run on the server, and using a VPN (on a
tablet on my LAN) show the exact same symptoms I had a year (or so) ago with
a couple of AT sites, which I eventually narrowed down to being caused by
the same blacklist by routinely switching IPs and then eventually shutting
down my relay temporarily.

Is anyone else seeing similar and/or have any suggestions as I rather not
have to shut my relay down.  Running a multitude of VPNs on my internal
machines is not really an option and my relay isn't going to function if I
throw a VPN on my server.

Cheers.

___
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] Could Zoom be using the wrong dan-tor blacklist

[Eddie]

Starting yesterday (maybe Saturday) we have been unable to initiate any 
Zoom calls.  They just sit "connecting".  According to Zoom, there are 
no issues that would lead to this.


My investigation, traces I have run on the server, and using a VPN (on a 
tablet on my LAN) show the exact same symptoms I had a year (or so) ago 
with a couple of AT sites, which I eventually narrowed down to being 
caused by the same blacklist by routinely switching IPs and then 
eventually shutting down my relay temporarily.


Is anyone else seeing similar and/or have any suggestions as I rather 
not have to shut my relay down.  Running a multitude of VPNs on my 
internal machines is not really an option and my relay isn't going to 
function if I throw a VPN on my server.


Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor bandwidth scanner "longclaw" slow to the US West Coast

[Eddie]

Not sure if my relay is similar, but I've been seeing a slow fall in 
consensus weight and advertised bandwidth over the past few months even 
though absolutely nothing has changed at my end.  Well, apart from me 
*increasing* the RelayBandwidth settings.


Also before I shut my relay down for a couple of weeks late last year, 
it had, and maintained guard status for about 6 months.  Now it yo-yos 
in and out of guard on a regular basis.


https://metrics.torproject.org/rs.html#details/D195E5CE8AE77BAC91673E6CFB7BD0AF57281646

Cheers.


On 8/15/2020 5:41 PM, Neel Chauhan wrote:

Hi,

Is anyone else hosting West Coast relays having this issue? Is 
"longclaw" actually measuring bandwidth from Europe? If so, WHY?




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor is reporting my bridges as offline

[Eddie]

Firstly, forgive me replying to my first post, but I didn't receive 
mails for my follow-up or Marco's helpful suggestion to reply to.


After contacting my VPS provider, they found that they were indeed 
having IPv6 issues, which they have now fixed.  Both bridges now show as 
on-line and I'm waiting for a distribution mechanism to be assigned.


Cheers.



On 6/30/2020 6:05 PM, Eddie wrote:

Hi,

I run 2 bridges on a hosted VPS.  Tor is currently showing both these 
as offline for the last hour or so, but I can still connect to them 
from a Tor Browser and looking at the local logs, they are both 
running quite happily.


Any ideas why they are showing as offline: 
https://metrics.torproject.org/rs.html#search/OhNoAnother


Cheers.

___
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] Tor is reporting my bridges as offline

[Eddie]

As a follow up, the "Last Seen" time keeps moving forward and the 
"Downtime" always seems to keep track with the "Last Seen" time, so it 
looks like the reporting thinks it occasionally  sees the bridge 
on-line, but there's nothing on the server to indicate the service 
yo-yoing between on and off line.


Cheers.



On 6/30/2020 6:05 PM, Eddie wrote:

Hi,

I run 2 bridges on a hosted VPS.  Tor is currently showing both these 
as offline for the last hour or so, but I can still connect to them 
from a Tor Browser and looking at the local logs, they are both 
running quite happily.


Any ideas why they are showing as offline: 
https://metrics.torproject.org/rs.html#search/OhNoAnother


Cheers.

___
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] Tor is reporting my bridges as offline

[Eddie]

Hi,

I run 2 bridges on a hosted VPS.  Tor is currently showing both these as 
offline for the last hour or so, but I can still connect to them from a 
Tor Browser and looking at the local logs, they are both running quite 
happily.


Any ideas why they are showing as offline: 
https://metrics.torproject.org/rs.html#search/OhNoAnother


Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] obfs4 bridge port question

[Eddie]

On 5/9/2020 1:06 PM, to...@protonmail.com wrote:
I am looking at the post install instructions here after putting up my 
first bridge:

https://community.torproject.org/relay/setup/bridge/post-install/
and thought I would try out the bridgeline for it.
|Bridge obfs4 :  cert= 
iat-mode=0|
I have all the parts mentioned in the text except for .  I have 
ExtORPort set to auto, so I never picked a port in my torrc.

How do I get there from here?

TIA,

--Torix

It's the port from this line:  ServerTransportListenAddr obfs4 
0.0.0.0: where the odfs4 is listening.


Cheers.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Is this probing normal for a bridge

[Eddie]

Hi,

On the VPS where I run a couple of bridges, I often see the following:

tcp6   0  0 aaa.bbb.cc.dd:443 194.14.247.1:18913  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 54.93.50.35:18457   SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.68.0.1:29917    SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.68.0.1:23629    SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.247.1:8846   SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.165.1:11833  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 54.93.50.35:20856   SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.247.1:38085  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.246.1:60957  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.165.1:10471  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.68.0.1:60852    SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.246.1:45321  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.246.1:43384  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.165.1:31634  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.68.0.1:29895    SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 54.93.50.35:51774   SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 54.93.50.35:27223   SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.246.1:6  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.0.1:31465    SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 54.93.50.35:30646   SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.246.1:7  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.165.1:46609  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.247.1:57978  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.68.0.1:59133    SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 54.93.50.35:27371   SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.68.0.1:13364    SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.165.1:50336  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.165.1:34511  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:80 aa.bb.ccc.dd:59349  ESTABLISHED
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.0.1:20251    SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.68.0.1:11573    SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.0.1:37358    SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 54.93.50.35:44226   SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 54.93.50.35:59194   SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.14.165.1:38300  SYN_RECV
tcp6   0  0 aaa.bbb.cc.dd:443 194.68.0.1:18209    SYN_RECV

Is this normal probing by the script kiddies or is it specific because 
I'm running the bridges.


Cheers.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] How to Limit Bridge Traffic

[Eddie]

Hi,

I'm quite happy to continue to run a couple of bridges on my VPC, but I 
need to understand how to manage the bandwidth so I'm not being charged 
for exceeding it's monthly allocation.


Does BandwidthRate apply to bridges.  I can (hopefully) guess that 
RelayBandwidth doesn't.


Does the AccountingMax apply.

I noticed the following in the manual:

If you have bandwidth cost issues, enabling hibernation is preferable to 
setting a low bandwidth, since it provides users with a collection of 
fast servers that are up some of the time, which is more useful than a 
set of slow servers that are always "available".


Does that advice apply equally to bridges, assuming that the Accounting 
options do apply.  Or would it more advantageous for a bridge to be 
constantly available, as switching bridges isn't as seamless as 
switching relays.


Cheers.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Is This Leap in Bridge Clients Normal

[Eddie]

Hi,

For about 6 weeks now, I've been running a couple of obfs4 bridges, one 
on port 80, the other port 443.  Up to yesterday, the port 80 one had 
seen zero traffic, when this started to be reported:


Feb 09 13:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 
0 unique clients.
Feb 09 19:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 
533 unique clients.
Feb 10 01:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 
63 unique clients.
Feb 10 07:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 
212 unique clients.
Feb 10 13:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 
93 unique clients.
Feb 10 19:46:19.000 [notice] Heartbeat: In the last 6 hours, I have seen 
61 unique clients.


Is this kind of sudden usage normal.

For the port 443 bridge, I have seen very little traffic at all, which 
surprises me as I thought that obfs4 bridges on port 443 were highly 
sought after.


A relay search for "OhNoAnother" will pull up the details.

Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bridge Questions, Best Practices

[Eddie]

Thanks for the follow up.

On 12/18/2019 3:20 PM, Philipp Winter wrote:

On Wed, Dec 18, 2019 at 12:12:03PM -0800, Eddie wrote:

I've seen a few comments mentioning the lack of obfs4 bridges using port
443, so as I don't run any kind of webserver on the VPS I can do this.  I
also wanted to run an obfuscated bridge on port 80, but it seems that you
can only run a single instance of obfs4. Searching around, the most common
setup I found was this:

ServerTransportListenAddr obfs3 [::]:80
ServerTransportListenAddr obfs4 [::]:443

Is this the best way to support both port 80 and 443, or is there a better
way.

You cannot run two obfs4 instances under one Tor instances.  You will
either have to start two Tor instances or configure a port forward from
port 80 to 443.
Let me look into the easiest option for this.  For now, I've just 
dropped the obfs3:80 part.

Also, there's no point in running both obfs3 and obfs4: If a bridge runs
multiple transports and some are resistant to active probing attacks
(scramblesuit, obfs4) while others aren't (vanilla Tor, obfs2, obfs3,
fte), then BridgeDB won't hand out the bridge's vulnerable transports
because they constitute a liability to the resistant transports.  See
the following ticket for more details:
<https://bugs.torproject.org/28655>


Next, the ORPort.  There seems to be confusing information about setting
this up, in conjunction with obfs4proxy.  Again, my setup:

ORPort 9001
ORPort [--my public ipv6 address--]:9002

Ideally, it shouldn't be necessary to expose an OR port if one is only
running an obfs4 bridge.  Unfortunately, we're not quite there yet:
<https://bugs.torproject.org/7349>

I suggest selecting a random OR port other than 9001.

Done.

Again, is the the best way, as I've seen some information that says avoid
9001, but others say it's OK to use for a bridge, with obfs4proxy.

It's best to avoid port 9001 because this port is commonly associated
with Tor.  Censors could easily scan the entire IPv4 address space for
port 9001 and block whatever turns out to be a Tor bridge.

Cheers,
Philipp
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Bridge Questions, Best Practices

[Eddie]

Hi,

Just setting up a new bridge, on a new VPS, to complement the relay I 
run at home and have a couple of questions regarding best practices.


I set the bridge up from scratch, so it has no connections back to my 
relay fingerprint etc. as I understand that's "a bad thing".


I've seen a few comments mentioning the lack of obfs4 bridges using port 
443, so as I don't run any kind of webserver on the VPS I can do this.  
I also wanted to run an obfuscated bridge on port 80, but it seems that 
you can only run a single instance of obfs4. Searching around, the most 
common setup I found was this:


ServerTransportListenAddr obfs3 [::]:80
ServerTransportListenAddr obfs4 [::]:443

Is this the best way to support both port 80 and 443, or is there a 
better way.


Next, the ORPort.  There seems to be confusing information about setting 
this up, in conjunction with obfs4proxy.  Again, my setup:


ORPort 9001
ORPort [--my public ipv6 address--]:9002

Again, is the the best way, as I've seen some information that says 
avoid 9001, but others say it's OK to use for a bridge, with obfs4proxy.


Cheers.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays