[tor-relays] Relay - Conflicting data (Atlas != log)

Tue Dec 3 04:19:23 UTC 2013

On 3/12/2013 11:52 AM, Roger Dingledine wrote:
>
> $ telnet 110.146.133.98 9001
> Trying 110.146.133.98...
>
> It looks like it's not up currently.

I've restarted, this time as a service from root -- not as a daemon from 
user. Don't think it's been long enough for Atlas to have updated.

>
>> Not sure what to think or do. Is it advertised on Atlas as false due
>> to this entry: [notice] Not advertising DirPort (Reason:
>> AccountingMax enabled)
> No, that just means it's going to write '0' for its dirport in its
> relay descriptor, discouraging clients from using it for fetching
> directory information.

Does this need addressing?

>
>> Or is one of the two sources (system or Atlas) wrongly reporting? Thank you.
> https://metrics.torproject.org/relay-search.html?search=110.146.133.98
> looks like it was up for that one consensus period and then down after
> that. Are you doing port forwarding (wrong)?
>
> --Roger
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
I don't think so: 9030 and 9001 are open on the router, do I need to 
open anything else up (besides IRC ports advertised in torrc)? I haven't 
even ran PF in this jail, or even on the host yet (fresh install), 
because I wanted to get the relay running first. So, the only firewall 
is on the router. Here's some more intelligence:

## torrc
SocksPort 0
Log notice file /usr/local/var/log/tor/notices.log
/usr/home/torrelay/log/tor/notices.log
RunAsDaemon 1
ORPort 9001
Nickname alphadet
RelayBandwidthRate 256 KB
RelayBandwidthBurst 512 KB
AccountingMax 20 GB
AccountingStart month 3 15:00
ContactInfo mark 696872F91EF8745B4FDF99061CB0654ACD57BC18 <mark at bsdbox.co>
DirPort 9030
ExitPolicy accept *:6660-6667,reject *:*
ExitPolicy reject *:*

## relevent excerpts from notices.log
Dec 03 03:12:40.000 [notice] Reloaded microdescriptor cache.  Found 0 
descriptors.
[...]
Dec 03 03:12:41.000 [notice] Heartbeat: It seems like we are not in the 
cached consensus.
Dec 03 03:12:41.000 [notice] Heartbeat: Tor's uptime is 0:00 hours, with 
3 circuits open. I've sent 0 kB and received 0 kB.
[...]
Dec 03 03:12:51.000 [notice] We'd like to launch a circuit to handle a 
connection, but we already have 32 general-purpose client circuits 
pending. Waiting until some finish.
[...]
Dec 03 03:13:33.000 [notice] We now have enough directory information to 
build circuits.
[...]
Dec 03 03:13:34.000 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Dec 03 03:13:38.000 [notice] Tor has successfully opened a circuit. 
Looks like client functionality is working.
Dec 03 03:13:38.000 [notice] Tor has successfully opened a circuit. 
Looks like client functionality is working.
Dec 03 03:13:38.000 [notice] Bootstrapped 100%: Done.
Dec 03 03:13:38.000 [notice] Bootstrapped 100%: Done.
Dec 03 03:13:38.000 [notice] Now checking whether ORPort 
110.146.133.98:9001 and DirPort 110.146.133.98:9030 are reachable... 
(this may take up to 20 minutes -- look for log messages indicating success)
Dec 03 03:13:38.000 [notice] Now checking whether ORPort 
110.146.133.98:9001 and DirPort 110.146.133.98:9030 are reachable... 
(this may take up to 20 minutes -- look for log messages indicating success)
Dec 03 03:13:41.000 [notice] Self-testing indicates your ORPort is 
reachable from the outside. Excellent. Publishing server descriptor.
Dec 03 03:13:46.000 [notice] Self-testing indicates your DirPort is 
reachable from the outside. Excellent.

## tor process
PID USERNAME    THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
54844 _tor          2  20    0 65536K 45648K sbwait   0:16  0.00% tor

This would indicate Tor is successfully running as a relay. Atlas, 
however, still reports differently: 
https://atlas.torproject.org/#details/EE16D7A4FBCF6494FEE75C856D76782295CB9DC4
Although it may be too early for an Atlas update.

I'm also somewhat concerned about the following, but not sure if it 
needs addressing:

## further, albeit unrelated, notices.log excerpts
Dec 02 15:37:54.000 [warn] Mismatched accounting interval: moved by 
-87.92%. Starting a fresh one.
Dec 03 03:12:38.000 [notice] No AES engine found; using AES_* functions.
Dec 03 03:12:38.000 [notice] This version of OpenSSL has a slow 
implementation of counter mode; not using it.
Dec 03 03:12:40.000 [notice] We weren't able to find support for all of 
the TLS ciphersuites that we wanted to advertise. This won't hurt 
security, but it might make your Tor (if run as a client) more easy for 
censors to block.
Dec 03 03:13:44.000 [notice] Your DNS provider gave an answer for 
"hxfu4dgtdhch", which is not supposed to exist. Apparently they are 
hijacking DNS failures. Trying to correct for this. We've noticed 1 
possibly bad address so far.

The exact same process and configuration was used as the test run, so 
I'm not sure why this instance is being reported as down on Atlas.

-- 
01101101 01100001 01110010 01101011