How to diagnose lack of traffic on bridge?
I have a bridge that gets no traffic. I don't mean "hardly any" traffic; I mean none. The contents of bridge-stats are always empty except for the date, which advances once per day. In the state file the last date, apart from daily accounting entries, is a EntryGuardAddedBy entry from 09 Sep 2012. Yeah, that's six weeks ago. The log file contains only a weekly notice of log file rotation and a daily notice of bandwidth self-test. I never see errors or even warnings in the log. My bridge is not unstable. It has been running continuously for the last 25 days, which is pretty typical for this bridge. I understand that bridges can be identified and their IP addresses blocked. But I am not lacking traffic just from China, or just from Iran, or just from any other entity. It doesn't seem likely that my IP address has been blacklisted by *everybody*. I am also aware that the bridge authorities seem to favor handing out some addresses more than others. Really, though, this IP address is never given out at all? What are the odds of that? On the rare occasions that I restart the bridge, I see in the log that my ORPort is reachable from outside and that my server descriptor is being published. That's nice. Also, I am running the current stable version of Tor, so it is not a matter of obsolete software. How can I diagnose the failure of my bridge to garner any traffic? Thanks.
On Thu, 25 Oct 2012 16:33:03 +0000, Steve Snyder wrote: ...
How can I diagnose the failure of my bridge to garner any traffic?
I assume you didn't set 'PublishServerDescriptor 0' in the tor.rc. Then the next step would be to check which pool the bridge ended up in, like (replace 'name' with your bridge name): https://onionoo.torproject.org/details?search=name Interesting part is the pool assignment (and whether it shows up at all). (Besides; stats are turned on? Mine are empty even though it gets used, according to the occasional netstat.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds <torvalds@*.org> Date: Fri, 22 Jan 2010 07:29:21 -0800
On 10/26/2012 01:21 AM, Andreas Krey wrote:
On Thu, 25 Oct 2012 16:33:03 +0000, Steve Snyder wrote: ...
How can I diagnose the failure of my bridge to garner any traffic?
I assume you didn't set 'PublishServerDescriptor 0' in the tor.rc.
This is the content of my torrc file (with ContactInfo removed): SocksPort 0 ORPort 443 BridgeRelay 1 Exitpolicy reject *:*
Then the next step would be to check which pool the bridge ended up in, like (replace 'name' with your bridge name):
This is what I'm shown when I search for my bridge (fingerprint) at the URL you suggested: {"relays_published":"2012-10-26 22:00:00", "relays":[ ], "bridges_published":"2012-10-26 21:37:04", "bridges":[ ]}
Interesting part is the pool assignment (and whether it shows up at all).
(Besides; stats are turned on? Mine are empty even though it gets used, according to the occasional netstat.)
Andreas
On Fri, Oct 26, 2012 at 10:52 PM, Steve Snyder <swsnyder@snydernet.net> wrote:
On 10/26/2012 01:21 AM, Andreas Krey wrote:
On Thu, 25 Oct 2012 16:33:03 +0000, Steve Snyder wrote: ...
How can I diagnose the failure of my bridge to garner any traffic?
I assume you didn't set 'PublishServerDescriptor 0' in the tor.rc.
This is the content of my torrc file (with ContactInfo removed):
SocksPort 0 ORPort 443 BridgeRelay 1 Exitpolicy reject *:*
Then the next step would be to check which pool the bridge ended up in, like (replace 'name' with your bridge name):
This is what I'm shown when I search for my bridge (fingerprint) at the URL you suggested:
{"relays_published":"2012-10-26 22:00:00", "relays":[ ], "bridges_published":"2012-10-26 21:37:04", "bridges":[ ]}
Interesting part is the pool assignment (and whether it shows up at all).
If you're not seeing any traffic at all, it's likely that your bridge was assigned to the "Unassigned" pool. This means that rather than handing the bridge out via email or https distributors it gets assigned to the "Bucket" distributor -- which basically writes a list of bridges to a file that gets sent to a contact or twitter, etc. It looks like we're not currently handing out bridges via this mechanism. That sucks. I'll try to find out what went wrong and fix it. Thanks for running a bridge! And thanks for drawing this to my attention. --Aaron
(Besides; stats are turned on? Mine are empty even though it gets used, according to the occasional netstat.)
Andreas
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 10/25/2012 10:33 PM, Steve Snyder wrote:
I have a bridge that gets no traffic. I don't mean "hardly any" traffic; I mean none.
The contents of bridge-stats are always empty except for the date, which advances once per day. In the state file the last date, apart from daily accounting entries, is a EntryGuardAddedBy entry from 09 Sep 2012. Yeah, that's six weeks ago.
The log file contains only a weekly notice of log file rotation and a daily notice of bandwidth self-test. I never see errors or even warnings in the log.
My bridge is not unstable. It has been running continuously for the last 25 days, which is pretty typical for this bridge.
I understand that bridges can be identified and their IP addresses blocked. But I am not lacking traffic just from China, or just from Iran, or just from any other entity. It doesn't seem likely that my IP address has been blacklisted by *everybody*.
Does the "Heartbeat" in tor.log say anything about circuits seen? Also, there is an option called ExitPortStatistics which you can turn on (by default it's off). Linus Nordberg said there was a bug which should be fixed since 0.2.4.4 with the client statistics (not sure if it's implemented in 0.2.2.x and 0.2.3.x). I don't know if there is a simpler way to check it, but it can be done over Tor control port (or control socket). First you'll need the content of control cookie in hex to be able to connect (depends on what authentication is set in torrc, but cookie default I think), for example using this: $ xxd -c 256 -ps /var/run/tor/control.authcookie 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f Then connect to control port (by default 9051) using netcat: $ nc localhost 9051 Write these two commands to see the stats (bridge needs to be running for at least 24 hours to get a meaningful value), the string after AUTHENTHICATE is the cookie from above: AUTHENTHICATE 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f GETINFO status/clients-seen The output should look something like this if it worked: AUTHENTHICATE 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 250 OK GETINFO status/clients-seen 250-status/clients-seen=TimeStarted="2012-10-19 21:24:18" CountrySummary=cn=16,??=8,ca=8,fr=8,ir=8,nl=8,sy=8,tw=8,us=8 IPVersions=v4=8,v6=40 250 OK Somebody said on the #tor-dev channel that "bridges tend to get forgotten", which I am not sure what it meant. Maybe they get handed out less? Ondrej
On 10/27/2012 12:17 AM, Ondrej Mikle wrote:
Also, there is an option called ExitPortStatistics which you can turn on (by default it's off). Linus Nordberg said there was a bug which should be fixed since 0.2.4.4 with the client statistics (not sure if it's implemented in 0.2.2.x and 0.2.3.x).
Sorry, the correct option is EntryStatistics (pasted wrong one). Ondrej
participants (4)
-
Aaron -
Andreas Krey -
Ondrej Mikle -
Steve Snyder