My relay, sTORMUR, just passd its two week birthday. From the very start is has never had an incoming connection. Only outgoing.
It is operating on port 8080. I have verified internet connectivity to that port - when tor is running, I can telnet to it from anywhere. Also tor’s internal test passes every time it is restarted: Self-testing indicates your ORPort 195.246.231.14:8080 is reachable from the outside. Excellent. Publishing server descriptor.
This is unlike any other server I have ever seen, where inbound connections are usually close to the same as outbound.
I agree. Which is one reason why I am puzzled.
EDIT: On reflection, I think the relay is capable of semi-normal looking operation through connection caching - when tor makes an outgoing connection it will keep it open for up to an hour or more just in case communication is required. Once my server initiates the connection, it’s bidirectional and then used both ways. That leads to my server initiating more and more connections. SO that’s why the transfer status looks reasonable. But there is still something wrong in that nothing can connect to it, and I would like to diagnose that.
This makes sense. I would, however, like to get my relay operating correctly. When it starts up, it takes a very long time to get into the groove because it only starts with a handful of connections and can only “listen” for circuit requests on those connections.
If anyone has any advice on how to diagnose this, I’d appreciate it.
My provider (1984) is extremely Tor friendly and there are several other relays on their network, so they are doing no blocking at all. And, as I said, I can verify connectivity through to my relay’s ORPort from anywhere.
I am almost ready to open up a bug report on this.
Only if a client decides to have your relay in its circuit, it will happen.
With a low consensus value (new relay, low connectivity etc) the probability is low to be selected by a client to build circuit.
The relay then builds connections to necessary relays to enable the circuit path selection of the client.
I assist friend to set up a relay, and from the moment it was turned on it have some incoming connections. Not many, but some. And now, three days later, with similar consensus to mine, it have thousands of incoming:
My server has had much much higher consensus a week ago (I had to turn it down to conserve bandwidth) and even then when it had stable flag and consensus weight ~8000 and was getting 8MiB/s traffic, it had zero incoming connections and still none.
I can start a brand new relay on other VPSs I own (I cannot run the relays there permanently because of restrictions), but when I test them there is almost immediate incoming connections. This is after 30 seconds:
There is clearly a fault somewhere on my sTORMUR relay.
I have discovered the issue and it appears to be a bug in the tor software.
When in the configuration you specify a listen adapter, tor will refuse to accept incoming connections. It will only allow incoming connections if you allow it to listen on 0.0.0.0.
I do not want to allow tor to listen on 0.0.0.0, because I have multiple adapters and some are VPN. In any case, the reason is not relevant. This seems to be a clear bug in tor. Before I report, though, can someone please indicate if this is somehow intended behaviour?
Address had previously been set to CNAME. Setting it to the IP and omitting Address entirely has no effect. Namely:
ORPort 40.30.20.10:9001 ipv4only with Address unset, Address set to IP, or Address set to CNAME always causes no incoming connections.
ORPort 9001 ipv4only (listening on 0.0.0.0), with Address unset, Address set to IP, or Address set to CNAME always succeeds with immediate incoming connections seen.
In all cases, even when no incoming connections are seen, the self-test on external connectivity succeeds. Also, in all cases, remotely connecting to ORPort from any source also succeeds. This log entry is seen on all attempts: [NOTICE] Self-testing indicates your ORPort 40.30.20.10:9001 is reachable from the outside. Excellent. Publishing server descriptor.