Hi.
I am trying to have my tor client [v0.4.6.9] use a relay that I am hosting [C02A8A4731AE509BA33F89C98B28999B7B7E2B36] as the middle node using the MiddleNodes torrc option.
The client bootstrap process becomes stuck at 50% (loading relay descriptors).
I’ll also note that trying to use my relay with EntryNodes also does not work, and becomes stuck at 75% (enough_dirinfo) instead.
If I instead designate some other relay from the ‘top relays’ on tor (e.g. F6740DEABFD5F62612FA025A5079EA72846B1F67) as the middle node, my client finishes bootstrapping just fine.
Additionally, my relay seems to be servicing a small number of other clients on the tor network (just not mine…), so I’m not sure where the problem lies.
When grep’ing the debug log for my relay fingerprint I find this entry…
Jan 26 13:18:42.000 [debug] node_set_hsdir_index(): ed25519 identity public key not found when trying to build the hsdir indexes for node $C02A8A4731AE509BA33F89C98B28999B7B7E2B36~TSTestRelay at 107.191.98.121 and [2604:180:f3::19a]
But I don’t understand what this issue means, or how to resolve it.
Is there an expected amount of time for directories to update, or is it variable?
I had another node (35072A396139CB4189F537ADB865DA9B2E8091A2) running for about five days before killing it and was still encountering the issue. But if this is expected then I can be patient and wait.
My client is still failing to connect. I also tried a client on a fresh Ubuntu 18 install on a different network to the same result.
The debug log still has me confused.
It would seem like my client is also failing to select entry guards whenever my relay is selected as the middle node.
Jan 27 21:42:01.000 [debug] entry_guard_set_filtered_flags(): Updated sampled guard [REMOVED] ($[REMOVED]): filtered=1; reachable_filtered=1.
Jan 27 21:42:01.000 [debug] count_usable_descriptors(): 1 usable, 1 present (microdescs).
Jan 27 21:42:01.000 [debug] compute_frac_paths_available(): mid: 0 present, 0 usable
Jan 27 21:42:01.000 [debug] compute_frac_paths_available(): guard: 0 possible
Jan 27 21:42:01.000 [debug] count_usable_descriptors(): 1403 usable, 1303 present (microdesc exit policies and flags).
Jan 27 21:42:01.000 [debug] compute_frac_paths_available(): exits: 1303 present, 1403 usable
Jan 27 21:42:01.000 [debug] compute_weighted_bandwidths(): Generated weighted bandwidths for rule weight as middle node based on weights Wg=0.407100 Wm=1.000000 We=0.000000 Wd=0.000000 with total bw 1900000.000000
Jan 27 21:42:01.000 [debug] compute_weighted_bandwidths(): Generated weighted bandwidths for rule weight as exit based on weights Wg=1.000000 Wm=1.000000 We=1.000000 Wd=1.000000 with total bw 29094711000.000000
Jan 27 21:42:01.000 [debug] compute_frac_paths_available(): f_guard: 0.00, f_mid: 1.00, f_exit: 0.93
Jan 27 21:42:01.000 [info] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 1/1, and can only build 0% of likely paths. (We have 0% of guards bw, 100% of midpoint bw, and 93% of exit bw = 0% of path bw.)
My client torrc contains only the MiddleNodes and StrictNodes lines in addition to the debug logging.
I’ll let it sit and come back to it in a few days time to see if more time resolves the issue.
ok, could reproduce your error now.
indeed, when I try to use your middle-node without using a bridge as an entry, i’m not able to use it.
first guess is, your provider for the node does some kind of filtering: https://metrics.torproject.org/rs.html#search/as:AS3842
try using a bridge and you should be able to use your node as a middle.
maybe have a look at the logs of your relay, perhaps you see some errors there, also worth a try might be asking your provider if an IDS/IPS or firewall is in place, dropping incoming connections from the tor-network or doing other things to the traffic