yopu need check your router or other stuff for miss config first.
It is definitely not offline, I can connect to it manually and I have not run any relay at home due to the dynamic IPs.
tcp 0 0 192.168.100.129:40308 95.215.45.138:443 ESTABLISHED 199/tor
tcp 0 0 192.168.100.129:48692 142.132.204.165:4080 ESTABLISHED 199/tor
Jan 18 17:08:45 toronly2 Tor[242]: Now checking whether IPv4 ORPort 82.79.72.106:2077 is reachable… (this may take up to 20 minutes – look for log messages indicating success)
Jan 18 17:08:45 toronly2 Tor[242]: Now checking whether IPv6 ORPort [2a02:2f01:7402:600::2]:2077 is reachable… (this may take up to 20 minutes – look for log messages indicating success)
Jan 18 17:08:46 toronly2 Tor[242]: Self-testing indicates your ORPort [2a02:2f01:7402:600::2]:2077 is reachable from the outside. Excellent.
Jan 18 17:08:46 toronly2 Tor[242]: Self-testing indicates your ORPort 82.79.72.106:2077 is reachable from the outside. Excellent. Publishing server descriptor.
Jan 18 17:08:47 toronly2 Tor[242]: Performing bandwidth self-test…done.
The IPs do change occasionally, but I have proceeded with reboots and that didn’t fix the issue even as the IP was read correctly.
Unlikely.
I have 3 homes I run bridges from. I also run relays and exits from various Datacenters, but taht is a different story, those are working perfectly.
The problems are with the bridges at home. Since I have dynamic IPs I thought a bridge is the best usage, 2x 1 gbps and 1x10 gbps with unlimited traffic should not remain unused.
It is proving way more complicated than I thought, sometimes they work great, sometimes they are shown as offline with about 2 hours perma-downtime.
While I did have downtime for reboots, updates and even a tree falling over the powerline due to heavy winds as well as repeated IP changes, usually about once per week per location, that does NOT mean the bridges are really offline for longer.
They do appear as offline and sometimes are not even distributed by any mechanism:
Downtime
2 hours 2 minutes and 47 seconds
Last Seen
2023-01-30 18:45:48
BUT:
Heartbeat: In the last 6 hours, I have seen 0 unique clients.
Jan 29 16:11:26 toronly2 Tor[199]: Heartbeat: Tor’s uptime is 7 days 0:00 hours, with 14 circuits open. I’ve sent 457.68 MB and received 627.24 MB. I’ve received 489 connections on IPv4 and 246 on IPv6. I’ve mad>
Jan 29 16:11:26 toronly2 Tor[199]: While bootstrapping, fetched this many bytes: 53217 (server descriptor fetch); 26553 (consensus network-status fetch); 2533021 (microdescriptor fetch)
Jan 29 16:11:26 toronly2 Tor[199]: While not bootstrapping, fetched this many bytes: 123180838 (server descriptor fetch); 9811 (server descriptor upload); 17554658 (consensus network-status fetch); 1774 (authori>
Jan 29 16:11:26 toronly2 Tor[199]: Heartbeat: In the last 6 hours, I have seen 0 unique clients.
Jan 29 22:11:26 toronly2 Tor[199]: Heartbeat: Tor’s uptime is 7 days 6:00 hours, with 14 circuits open. I’ve sent 459.46 MB and received 633.48 MB. I’ve received 493 connections on IPv4 and 246 on IPv6. I’ve mad>
Jan 29 22:11:26 toronly2 Tor[199]: While bootstrapping, fetched this many bytes: 53217 (server descriptor fetch); 26553 (consensus network-status fetch); 2533021 (microdescriptor fetch)
Jan 29 22:11:26 toronly2 Tor[199]: While not bootstrapping, fetched this many bytes: 127369034 (server descriptor fetch); 10174 (server descriptor upload); 17887868 (consensus network-status fetch); 1774 (author>
Jan 29 22:11:26 toronly2 Tor[199]: Heartbeat: In the last 6 hours, I have seen 0 unique clients.
Jan 30 04:11:26 toronly2 Tor[199]: Heartbeat: Tor’s uptime is 7 days 12:00 hours, with 15 circuits open. I’ve sent 461.16 MB and received 640.02 MB. I’ve received 494 connections on IPv4 and 246 on IPv6. I’ve ma>
Jan 30 04:11:26 toronly2 Tor[199]: While bootstrapping, fetched this many bytes: 53217 (server descriptor fetch); 26553 (consensus network-status fetch); 2533021 (microdescriptor fetch)
Jan 30 04:11:26 toronly2 Tor[199]: While not bootstrapping, fetched this many bytes: 131855179 (server descriptor fetch); 10529 (server descriptor upload); 18292982 (consensus network-status fetch); 1774 (author>
Jan 30 04:11:26 toronly2 Tor[199]: Heartbeat: In the last 6 hours, I have seen 0 unique clients.
Jan 30 10:11:26 toronly2 Tor[199]: Heartbeat: Tor’s uptime is 7 days 18:00 hours, with 15 circuits open. I’ve sent 463.38 MB and received 647.77 MB. I’ve received 494 connections on IPv4 and 246 on IPv6. I’ve ma>
Jan 30 10:11:26 toronly2 Tor[199]: While bootstrapping, fetched this many bytes: 53217 (server descriptor fetch); 26553 (consensus network-status fetch); 2533021 (microdescriptor fetch)
Jan 30 10:11:26 toronly2 Tor[199]: While not bootstrapping, fetched this many bytes: 136226770 (server descriptor fetch); 10884 (server descriptor upload); 19537132 (consensus network-status fetch); 1774 (author>
Jan 30 10:11:26 toronly2 Tor[199]: Heartbeat: In the last 6 hours, I have seen 0 unique clients.
Jan 30 16:11:26 toronly2 Tor[199]: Heartbeat: Tor’s uptime is 8 days 0:00 hours, with 15 circuits open. I’ve sent 464.91 MB and received 653.67 MB. I’ve received 494 connections on IPv4 and 246 on IPv6. I’ve mad>
Jan 30 16:11:26 toronly2 Tor[199]: While bootstrapping, fetched this many bytes: 53217 (server descriptor fetch); 26553 (consensus network-status fetch); 2533021 (microdescriptor fetch)
Jan 30 16:11:26 toronly2 Tor[199]: While not bootstrapping, fetched this many bytes: 140275085 (server descriptor fetch); 11244 (server descriptor upload); 19897789 (consensus network-status fetch); 1774 (author>
Jan 30 16:11:26 toronly2 Tor[199]: Heartbeat: In the last 6 hours, I have seen 0 unique clients.
One bridge that works:
Heartbeat: Tor’s uptime is 6 days 12:00 hours, with 1150 circuits open. I’ve sent 727.71 GB and received 738.81 GB. I’ve received 72335 connections on IPv4 and 504 on IPv6. I’ve
made 263488 connections with IPv4 and 74864 with IPv6.
Same settings, another one that is shown as offline:
Heartbeat: Tor’s uptime is 10 days 18:00 hours, with 17 circuits open. I’ve sent 28.58 GB and received 29.18 GB. I’ve received 1601 connections on IPv4 and 249 on IPv6. I’ve made 17701 connections with IPv4 and 4692 with IPv6.
The unnerving thing is that this looks like random. I have not been able to determine what is the difference between bridges that are shown as online and those that are set offline by the consensus. Moreover, the status could flip into offline for the working ones, also at random and for random intervals which means that, even after it returns to an online status (again random) it has a long period of low activity.
1 Like
Will this ever be fixed?
1 Like
I have the exact same problem with an OBFS4 bridge under Docker on my Synology DS720+.
Is there a solution to this in the meantime?
Downtime
2 hours 5 minutes and 51 seconds
Last Seen
2023-02-19 15:44:03
Reinstalled a working one because of a ssd crash, it has been permanently offline, even racking up more offline time than since it was “first seen”.
At this point, I think it is fair to say the bridge system is a lottery, more than half are not working,
Just look here: Relay Search, what are the chances to have 1/4 of the listed installations down for about 2 hours?
1 Like
Even official snowflake bridges are “down for 2 hours” at this moment.
So, is this going to be fixed or we continue to blame the operators for not setting up the bridges properly? Or at least give us a workaround, so we stop reinstalling in the hope we would be lucky. Or how to reinstall properly, something, please!
how is your setup friend ?
I think I might have cracked it.
I have setup 4 identical bridges on the same connection (same IPv4, different IPv6). Port pairs:
80:443
110:995
143:993
61000:61001
The first one went straight to downtime, the rest are showing uptime. It is too early to see some traffic, but I believe this might be it. Avoid 80:443 as ports for the bridge and it might work. I am awaiting answers from other people having this issue.
From Tor Project | Debian / Ubuntu
you can read more to set more option on tor(1): second-generation onion router - Linux man page
BridgeRelay 1
ORPort use one of those ports if you live in censorship country 53,443,80
Tor recognizes these flags on each ORPort:
**NoAdvertise**::
By default, we bind to a port and tell our users about it. If
NoAdvertise is specified, we don't advertise, but listen anyway. This
can be useful if the port everybody will be connecting to (for
example, one that's opened on our firewall) is somewhere else.
**NoListen**::
By default, we bind to a port and tell our users about it. If
NoListen is specified, we don't bind, but advertise anyway. This
can be useful if something else (for example, a firewall's port
forwarding configuration) is causing connections to reach us.
**IPv4Only**::
If the address is absent, or resolves to both an IPv4 and an IPv6
address, only listen to the IPv4 address.
**IPv6Only**::
If the address is absent, or resolves to both an IPv4 and an IPv6
address, only listen to the IPv6 address.
For obvious reasons, NoAdvertise and NoListen are mutually exclusive, and
IPv4Only and IPv6Only are mutually exclusive.
ServerTransportListenAddr obfs4 0.0.0.0:53,80,443 → use someone of those ports or above 10000
ExtORPort auto → autogenerated config
Nope, that’s wrong. Using a low ORPort will make easier for censors to scan and find your Tor bridge. ORPort should be a random port. OBFS4 port can be 443, 53, or 80.
2 Likes
As censors blocks bridges by IP and not IP:Port, this is not very useful and you can’t run IPv6-only bridges. Could you run just one bridge per IP instead? After that we can investigate the offline error if the issue persist.
I know that, the only reason for this was to test a theory and it looks like I have found the issue. Besides the IPv4 is dynamic, changes about once a week, so GL with that.
Look up these bridges (first is the name, instead of PickANickName to make it harder to block):
ghfjdiuetg ports 80:443
i83uejsoi ports 110:995
p0rth89bd ports 143:993
l8knghytcx ports 61000:61001
They are on same connection, same IP, same exact setup in 4 different containers, the only differences are the ports and the IPv6. So there can be NO confusion about mistakes in setup, outdated stack or offline connection.
The one with 80:443 combo was perma offline from creation. The others are online eversince.
I have given you a lot of info as I am battling this for months.
Alright, I see that the uptime has been restored for the 80:443 one and is the same with the others even as it has been shown as offline before for days while the others were online in the consensus.
Should I conclude that the bug has been fixed and end this experiment?