The site seeded with tor=always isn't downloded to another peer with tor=always

[yurivict]

I created a blog on one Arch linux with tor=always, and no open 15441 port. Another instance of ZN running on another similar Arch setup always fails to download content.json.

The original instance also shows this message:

Your network connection is restricted. Please, open 15441 port
on your router to make your site accessible for everyone.

I think this message is completely wrong for tor=always because incoming connections should come from tor HS, and not from the port open on the router. It should work on tor.

The debug log on the downloading peer shows a timeout:

[18:55:03] WorkerManager:1HDT1a..wn9Z Timeout, Skipping: {'optional_hash_id': None, 'site': <Site 1HDT1a..wn9Z>, 'done': False, 'size': 0, 'inner_path': 'content.json', 'peers': None, 'time_started': 1465264443.315883, 'time_action': None, 'priority': 9999, 'failed': [<Peer:ill4ijostvqk4h7e.onion>, <Peer:jccprijdxlok4krr.onion>, <Peer:jccprijdxlok4krr.onion>], 'workers_num': 0, 'time_added': 1465264443.303915, 'evt': <gevent.event.AsyncResult object at 0x7f81b07c2250>}
[19:04:34] WorkerManager:1HDT1a..wn9Z Timeout, Skipping: {'optional_hash_id': None, 'site': <Site 1HDT1a..wn9Z>, 'done': False, 'size': 0, 'inner_path': 'content.json', 'peers': None, 'time_started': 1465265000.060174, 'time_action': None, 'priority': 9999, 'failed': [<Peer:ill4ijostvqk4h7e.onion>, <Peer:jccprijdxlok4krr.onion>], 'workers_num': 0, 'time_added': 1465265000.058588, 'evt': <gevent.event.AsyncResult object at 0x7f81a9cc2990>}
[19:05:35] WorkerManager:1HDT1a..wn9Z Timeout, Skipping: {'optional_hash_id': None, 'site': <Site 1HDT1a..wn9Z>, 'done': False, 'size': 0, 'inner_path': 'content.json', 'peers': None, 'time_started': 1465265074.553957, 'time_action': None, 'priority': 9999, 'failed': [<Peer:ill4ijostvqk4h7e.onion>, <Peer:jccprijdxlok4krr.onion>], 'workers_num': 0, 'time_added': 1465265074.541852, 'evt': <gevent.event.AsyncResult object at 0x7f81a9c95fd0>}
...
out:[19:23:51] FileServer FileRequest: Conn#92 ill4ijostvqk4h7e.onion [v2] pex 1HDT1a{...}wn9Z None
out:[19:23:56] WorkerManager:1HDT1a..wn9Z Timeout, Skipping: {'optional_hash_id': None, 'site': <Site 1HDT1a..wn9Z>, 'done': False, 'size': 0, 'inner_path': 'content.json', 'peers': None, 'time_started': 1465266175.363997, 'time_action': None, 'priority': 9999, 'failed': [<Peer:ill4ijostvqk4h7e.onion>, <Peer:jccprijdxlok4krr.onion>, <Peer:jccprijdxlok4krr.onion>], 'workers_num': 0, 'time_added': 1465266175.36015, 'evt': <gevent.event.AsyncResult object at 0x7f81a9c10b10>}

Is ZN supposed to succeed seeing site hosted on tor-only peer from another tor-only peer? I think this should work, but it doesn't work for me.

When the site is seeded on tor-only peer it can only be visible to the clearnet ZN peers through the peers that are in both tor and clearnet.

[HelloZeroNet]

it should work between tor-only peers (please not there is some warmup time on tor hidden services, so you have to wait 1-10 minute after you created your site)

are you sure are you running in tor only mode? it should display "Successfully started Tor onion hidden services." message then (https://github.com/HelloZeroNet/ZeroNet/blob/master/src/Ui/UiWebsocket.py#L68) then.

[yurivict]

Yes, one of my hosts had disabled tor control port. I ran zeronet with --tor always, but ZN was still able to update sites. I think this is a bug that when tor=always fails it falls back to working through the clearnet. This is insecure, the correct behavior is to fail with the clear message that Tor is not configured correctly.

[sergei-bondarenko]

Yes, one of my hosts had disabled tor control port. I ran zeronet with --tor always, but ZN was still able to update sites. I think this is a bug that when tor=always fails it falls back to working through the clearnet. This is insecure, the correct behavior is to fail with the clear message that Tor is not configured correctly.

@yurivict @HelloZeroNet Can't reproduce. With --tor always option there is no fallback to clearnet.