Hi there.
I have done all steps which have being described here:
and here:
Metrics reports the bridge would being working.
But my bridge obviously is not being visible for clients or at least won’t be used. Why?
Because your bridge is not advertised to users.
Bridge distribution mechanism
None
Maybe I am wrong but can you please check in your torrc that this line is there ExtORPort auto
Yup. You’re wrong. That is for obfs4proxy to connect to, and doesnt really affect the bridge dist.
Oops! That’s new. As I have checked metrics on Thursday, 16th March 2023 a.m., it said “moat”.
So, obviously my bridge has a life of its own.
I think I will set up it again completely from the scratch.
As for me, as an Apple user, it is a melange of challenging but sometimes as well of a little bit annoying to provide a Tor bridge and maintain it.
Checking your bridge with bridgestrap shows that your obfs4 is dysfunctional:
Bridge CA39A0DD187313930099F0BD470E5EA676EB85C0 advertises:
* obfs4: dysfunctional
Bandwidth Ratio: 1.984452
Error: timed out waiting for bridge descriptor
Last tested: 2023-03-20 04:00:14.289458032 +0000 UTC (13h17m15.715287944s ago)
Which port are you using for your obfs4proxy?
Can you test if the port is publicly reachable? (click on the link below)
https://bridges.torproject.org/scan/
I am using Port 443. And yes, that’s what I already know: The port is not reachable from outside. But what I am unable to is to figure out, where in the setting I did the failure to avoid to be reachabel from outside. At least my Fritz!Box 7490 notifies that it can being reached from outside via port 443. So I think the failure is in the configuration of Tor.
From the Tor Bridge guide:
If you decide to use a fixed obfs4 port smaller than 1024 (for example 80 or 443), you will need to give obfs4 CAP_NET_BIND_SERVICE capabilities to bind the port with a non-root user:
sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
To work around systemd hardening, you will also need to set NoNewPrivileges=no in /lib/systemd/system/tor@default.service and /lib/systemd/system/tor@.service and then run systemctl daemon-reload. For more details, see ticket 18356.
Or just try a high random port and restart your tor?
What is a »high« port number?
Example
ORPort auto
ORPort 65000
ORPort 0.0.0.0:auto
random port is used by software to choose any available port to be used by tor. you can see info on tor man
Any port between 49152 to 65535 can be good
Hey, it’s not the ORPort that needs a higher port. It’s the obsf4 port ServerTransportListenAddr, for example, ServerTransportListenAddr obfs4 0.0.0.0:65000.
Please check the right information before commenting, @red0bear. It’s very unhelpful to share a wrong piece of information.
1 Like
As said i gave a example how it could be. But since i didnt try this mode yet ; but example could be valid.
I have tried it in the last hours with a port 4***. This seemed has been working.
Why should I not use a port within the range of 4***?
Just now I have changed ServerTransportListenAddr obfs4 to a port 6*****
ServerTransportListenAddr obfs4 0.0.0.0:64100
ServerTransportListenAddr obfs4 [::]:64100
Why do those ports beyond 49141 are better than lower ports?
And one more question: When in torrc I would write
ServerTransportListenAddr obfs4 0.0.0.0:auto
ServerTransportListenAddr obfs4 [::]:auto
could I than in my router write port 443 for obfs4?
I already pointed out that this configuration suggested in this thread is wrong. Don’t do that.
You can. The only restriction is with lower ports that you need to give a special permission.
High ports are general use while low ports are made to specifc uses.
Look at this → List of TCP and UDP port numbers - Wikipedia
I know. Though the question ist, does it have an impact on the reliabilty or the performance of my bridge, when using port 6**** whilst not 443?
Obviously it is having an impact: Now, for almost one week, I have seen 0 or at maximum 1 unique clients. So I will switch back to port 443. And if my bridge then remains failing, I’ll break it down. It is taking too much time, to make it running.
The obfs4 port won’t change your bridge popularity. You should check if your bridge is reachable and working fine.
as visible on metrics your bridge was doing well until beginning of this year (see 6 month stats). did anything in your network change at that time (maybe switch of your ISP, contract or modem/router)? does your provider give you a new IP every night or is your modem/router set to get a new one every day?
personal off-topic suggestion - try not to get frustrated at learning - yes a fruity computer works most of the time but you do not exactly know why. debugging something with the penguin now gives insights you would never have otherwise. the break-even-point comes later in time and your RIO expectation might need adjustment.
“Digital first, Bedenken second”
2 Likes