**You can find the solution in the end of this post.**

My Tor relay is working as an Exit, but it is configured with `ExitPolicy reject *:*`.

![relayname is Hanswurst][1]
Hanswurst is the name of my relay.

Arm is giving me the warning, that the torrc differs from what tor's using.
![armwarning][2]

When I perform a SIGHUP to reload the `torrc`, my relay isn't an exit any longer.

![sighub performed][3]

Can i trust the arm connection list?

I use an RaspberryPi to route all wireless connections through the Tor network. Acting as an Tor client only works really well.

    Log notice file /var/log/tor/notices.log
    #DataDirectory /var/tor
    VirtualAddrNetwork 10.192.0.0/10
    AutomapHostsSuffixes .onion,.exit
    AutomapHostsOnResolve 1
    Exitpolicy reject *:*
    StrictNodes 1
    ExitNodes $E0C2C5223F6C219C5D41F57FFDF65661A36BCDA6, ...
    TransPort 9040                      <--------------- Line 23
    TransListenAddress 192.168.42.1
    AvoidDiskWrites 1
    DNSPort 53
    DNSListenAddress 192.168.42.1
    ControlPort 9051
    ControlListenAddress 127.0.0.1:9051
    HashedControlPassword 16:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx
    DisableDebuggerAttachment 0

    ##Relaystuff
    ORPort 9000
    Nickname Hanswurst
    RelayBandwidthRate 512 KB
    RelayBandwidthBurst 1024 KB
    ContactInfo sauerbraten[a t]privatdemail{dot]net

I added the `ExitPolicy` parameter in the default config too, but it made no difference. Every time i start the Tor service, my relay works as an exit. When i reload the config it isn't an exit any longer..

Is my torrc causing that behavior?


Edit: I added the option `DisableDebuggerAttachement 0` and got that list. The connections look kinda scary for being a relay..
![enter image description here][4]



Edit2: Following the `notices.log`. I can`t see anything suspicious..

    Mar 22 11:45:12.000 [notice] Your Tor server's identity key fingerprint is 'Hanswurst 52211EFD644E7555E849A48D87D1D63A289BB42A'
    Mar 22 11:45:22.000 [notice] Reloaded microdescriptor cache.  Found 17310 descriptors.
    Mar 22 11:45:34.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no recent usable consensus.
    Mar 22 11:45:35.000 [notice] Guessed our IP address as 46.128.228.XXX (source: 193.23.244.244).
    Mar 22 11:45:35.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no recent usable consensus.
    Mar 22 11:45:35.000 [notice] Bootstrapped 5%: Connecting to directory server.
    Mar 22 11:45:36.000 [notice] Heartbeat: Tor's uptime is 0:00 hours, with 1 circuits open. I've sent 2 kB and received 5 kB.
    Mar 22 11:45:36.000 [notice] Bootstrapped 10%: Finishing handshake with directory server.
    Mar 22 11:45:36.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection.
    Mar 22 11:45:36.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus.
    Mar 22 11:45:36.000 [notice] Bootstrapped 25%: Loading networkstatus consensus.
    Mar 22 11:45:40.000 [notice] Bootstrapped 45%: Asking for relay descriptors.
    Mar 22 11:45:40.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 0/5310 usable descriptors.
    Mar 22 11:45:42.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.
    Mar 22 11:45:43.000 [notice] Bootstrapped 50%: Loading relay descriptors.
    Mar 22 11:45:44.000 [notice] Bootstrapped 52%: Loading relay descriptors.
    Mar 22 11:45:44.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 96/5310 usable descriptors.
    Mar 22 11:45:45.000 [notice] Bootstrapped 54%: Loading relay descriptors.
    Mar 22 11:45:45.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 192/5310 usable descriptors.
    
    ........
    
    Mar 22 11:46:16.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 3976/5310 usable descriptors.
    Mar 22 11:46:17.000 [notice] We now have enough directory information to build circuits.
    Mar 22 11:46:17.000 [notice] Bootstrapped 80%: Connecting to the Tor network.
    Mar 22 11:46:18.000 [notice] Bootstrapped 85%: Finishing handshake with first hop.
    Mar 22 11:46:19.000 [notice] Bootstrapped 90%: Establishing a Tor circuit.
    Mar 22 11:46:20.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
    Mar 22 11:46:20.000 [notice] Bootstrapped 100%: Done.
    Mar 22 11:46:20.000 [notice] Now checking whether ORPort 46.128.228.XXX:9000 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
    Mar 22 11:46:25.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.



**EDIT:**

Hey I wanted to close that issue. The main problem was that I confused the EXIT of the internal circuit with the EXIT of the Tor network. 2 tickets exist to clarify that UX problem in ARM. [6430](https://trac.torproject.org/projects/tor/ticket/6430) and [12956](https://trac.torproject.org/projects/tor/ticket/12956).

> I think for non-general-purpose circuits, we should call that third hop something else. I'm open to suggestions -- one option would be to just call the last hop on a non-exit circuit "Middle" also. Another option would be to call it "Internal".

There exist one more stackexchange [question](https://tor.stackexchange.com/questions/7376/tor-is-making-me-an-exit-node-despite-configuration) too.

In conclusion, what I have seen is that TOR made internal circuits and called me the EXIT of them. That is not really a problem because I am not an EXIT of the Tor network itself.


  [1]: https://i.sstatic.net/9cpdn.png
  [2]: https://i.sstatic.net/785bw.png
  [3]: https://i.sstatic.net/7gsZx.png
  [4]: https://i.sstatic.net/A3nEj.png