Custom Query (24361 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (43 - 45 of 24361)

Ticket Resolution Summary Owner Reporter
#32123 implemented Implement minimal --disable-relay-mode teor teor
Description

Add:

  • --disable-relay-mode
    • Build tor with relay mode disabled: tor can not run as a relay, bridge, or authority. Implies --disable-dirauth-mode.
    • disable DirPort, DirCache, ORPort, and sets ClientOnly to 1
    • pick one quick module/function to disable

Update:

  • --disable-dirauth-mode
    • hidden alias --disable-module-dirauth
    • Build tor with authority mode disabled: tor can not run as a directory authority or bridge authority.
#32115 not a bug Hidden Service in TestingTorNetwork connected to non-Exit Nodes lewis85
Description

Hi folks,

I set up a testing environment made of lxd containers on Ubuntu 18.04. Each container is based on the Ubuntu 18.04 image and runs Tor version 0.4.1.6. Specifically, I have the following running machines:

  • 3 Authorities (named as TorAuthoritity[01,02,03])
  • 1 Hidden Service (named as TorHs01)
  • 1 Client (named as TorClient01)

The torrc file has the "TestingTorNetwork 1" configuration value.

Moreover, only the torrc of Exit Relays has the following configuration values:

ExitRelay 1 ExitPolicy accept *:*

whereas all the other torrc files (i.e., Authorities and non-Exit Relays) have the following configuration values:

ExitRelay 0 ExitPolicy reject *:*

All the Tor relays and hidden service are configured in order to use the three Authorities

However, I noticed that the Hidden Service is always connected to one or more non-Exit Relays whereas I expected to see only connections to Exit Relays. For example, by running the command lsof -i on the container providing the Hidden Service, I get the following result:

root@TorHs01:~# lsof -i COMMAND   PID            USER   FD   TYPE DEVICE SIZE/OFF NODE NAME systemd-n 180 systemd-network   14u  IPv4 128314      0t0  UDP TorHs01.lxd:bootpc systemd-r 182 systemd-resolve   12u  IPv4  52219      0t0  UDP localhost:domain systemd-r 182 systemd-resolve   13u  IPv4  52240      0t0  TCP localhost:domain (LISTEN) sshd      251            root    3u  IPv4  77216      0t0  TCP *:ssh (LISTEN) sshd      251            root    4u  IPv6  77314      0t0  TCP *:ssh (LISTEN) apache2   260            root    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN) apache2   272        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN) apache2   273        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN) apache2   274        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN) apache2   275        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN) apache2   276        www-data    4u  IPv6  81261      0t0  TCP *:8050 (LISTEN) tor       396             tor    9u  IPv4 116948      0t0  TCP localhost:9050 (LISTEN) tor       396             tor   14u  IPv4 117902      0t0  TCP TorHs01.lxd:54948->TorAuthority03.lxd:5000 (ESTABLISHED) tor       396             tor   15u  IPv4 117904      0t0  TCP TorHs01.lxd:41538->TorRelay02Exit.lxd:5000 (ESTABLISHED)

where the last two lines represent connections to TorAuthority03 (which is configured as a non-Exit Relay) and TorRelay02Exit (which is configured as an Exit Relay) respectively. Generally, the Hidden Service is always connected at least to a non-Exit Relay (e.g., TorRelay04, TorAuthority03, etc) whereas I expected that the Hidden Service was only connected to Exit Relays (in my lxd environment, TorRelay01Exit, TorRelay02Exit, TorRelay03Exit). Looking at the network traffic through Wireshark, it looks like the Hidden Service is using a non-Exit Relay as an exit node, although the consensus already includes the three Exit Relays in my testing environment. Is this behavior related to the testing environment only? If yes, do you already know why this happens? Is it possible to avoid this behavior?

Sincerely, lewis85

#32113 fixed Make "make doxygen" work with out-of-tree builds nickm nickm
Note: See TracQuery for help on using queries.