[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



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@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx>
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

_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays