I have a similar problem.
I am running a few bridges, with quite some traffic, I run them from my home connections with dynamic IPv4/IPv6 so running bridges is the best way I think. The IP only changes when the connection drops which happens about twice a month, so that is NOT the problem, the connections are fast back in spite of the IP change:
The problem is with one of the bridges which is ALWAYS shown as down with a downtime between one and 2 hours:
Downtime
1 hour 43 minute and 40 seconds
Last Seen
2022-12-31 03:58:42
It is never down, I am monitoring my connections to all my homes.
I don’t care about the way the metrics portray it, but it doesn’t have any connections, Bridge distribution mechanism is set to none.
I am looking for a solution or at least a workaround.
Now another bridge is shown as offline and that greatly reduced the connections and traffic, same symptoms:
Downtime
1 hour 53 minute and 51 seconds
Last Seen
2023-01-02 20:58:44
The downtime is always between 1 and 2 hours. If it were down, then the downtime would be longer.
There is no change in any of the bridges, the connection is up and all ports open. Again, the ORPort does not get unreachable every 2 hours or so and then comes back in two different locations.
I am looking for a resolution or at least a workaround. Otherwise I would keep providing relays only until this is fixed.
Yes, the bug is still present.
All my bridges have IPv6, all are running within the same provider on residential and company connections, all have dynamic IPs, all are running within VMs bridged to the router, there is no difference.
3 are shown online (with one exception which has been penalized harshly by the bug for a few days) and another in same conditions is shown as offline always for close to 2 hours, like it is coming back online for a few minutes, then off again.
Something did change. I never saw more than 2 hours downtime displayed, now it passed the threshold:
Downtime
2 hours 3 minutes and 30 seconds
Last Seen
2023-01-08 07:58:49
Is someone working on this?
I recently setup some obfs4 bridges on linux by following the official guide. they were fully functional and always online. I’ve tested and kept used them myself. the tor directory system that connects to the OR port every hour would correctly give it the green dot. however, the system that tests the obfs4 port every 18 or so hours, would usually find them “functional”, but sometimes dysfunctional. at one point, it even decided that one of the obfs4 bridges was a vanilla bridge, and bridgeDB and started distributing its OR port. all were configured identically.
I later realized that the obfs4proxy executable installed through the official guide was an older version. I’ve manually installed version 0.0.14 of obfs4proxy, and my bridges haven’t been judged dysfunctional since. could be a coincidence, but it’s been 20 days.
If yes, then I suppose it works completely fine! We shared it with the users from Turkmenistan; they have enormous internet restrictions there. Unfortunately, their censors blocked this bridge - and you faced the acute decrease in traffic.
Yes, it is, however, how are they blocking it? The traffic dropped after it was shown offline for a few days even as it was on. My experience so far shows it will pick up again once it is shown online for longer.
The IPs are dynamic albeit do not change too often.
In my view, this kind of bridge is the best, IPs change now and then, not too fast to be shown offline for long, and often enough so it is not blocked. Maybe it is best to change name so it can’t be found anymore.
The bug is still present with the one which is shown perma down with a downtime of about 2 hours.
Downtime
1 hour 53 minute and 3 seconds
Last Seen
2023-01-10 06:58:53
I have checked, installed from backports, if there is another one or I need to build from sources, by all means, please specify some place.
obfs4proxy is already the newest version (0.0.8-1+b6).
There is a new version of obfs4proxy (0.0.14) that fixes some important obfuscation bugs, the details of will be published soon. Please upgrade as soon as possible, to keep users safe.
If you use debian you can find the Debian package in stable-backports:
https://packages.debian.org/stable-backports/obfs4proxy
If you use docker you'll find the latest version in docker hub:
https://hub.docker.com/r/thetorproject/obfs4-bridge/
We are providing a package for ubuntu jammy:
https://people.torproject.org/~meskio/jammy/obfs4proxy_0.0.14-1_amd64.deb
Or you can find the source code in the upstream repository:
https://gitlab.com/yawning/obfs4
And don't forget to restart the tor daemon after upgrading obfs4proxy so the upgraded version is used by the Bridge.
It’s still uncertain how Turkmenistan censors are discovering Tor bridges, but some researchers pointed out that when censors see too many connections to one IP, they block it.
Alright, since yesterday (about 10 hours): obfs4proxy is already the newest version (0.0.14-1~bpo11).
Self-testing indicates your ORPort xxx.79.72.106:80 is reachable from the outside. Excellent.
Jan 11 10:10:03 debtorobfs1 Tor[3727]: Self-testing indicates your ORPort [2a02:2f01:7402:600:20c:29ff:xxxx:2d2b]:80 is reachable from the outside. Excellent. Publishing server descriptor.
Still:
Downtime
1 hour 56 minute and 17 seconds
Last Seen
2023-01-11 09:58:54
The problem persists after updating obfs4proxy more than a day ago:
Downtime
1 hour 57 minute and 41 seconds
Last Seen
2023-01-12 00:58:54
First Seen
2022-12-27 07:44:53
Last Restarted
2023-01-11 08:09:01
Platform
Tor 0.4.5.10 on Linux
Transport protocols
obfs4
Bridge distribution mechanism None
Since 27th of January it is shown permanently as offline but only with a downtime of about 2 hours. Any ideas on what else should be upgraded?
I did run a relay on the same residential IP recently; then I nuked the Tor keys/hashes/data and created this fresh bridge. I know it’s accessible from the outside on both IPv4/6; I can use it from my Tor Browser on my phone and laptop.
Could it be that I ran a relay that’s now off-line from the same IP in the recent past?
