See ticket 7707 for why we added that diagnostic log message in. In short, we were worrying that our round-robin bandwidth allocations would spread bytes too thin over all the connections we write out onto, making the overhead from TLS record headers too high a fraction of the overall bandwidth we use.
This log message is telling you how many extra bytes ...
The different levels are as follows (Tor Docs)
ERROR critical issue occurred, the user needs to be notified
WARN non-critical issue occurred that the user should be aware of
NOTICE information that is helpful to the user
INFO high level library activity
DEBUG low level library activity
TRACE request/reply logging
Warn means that an issue ...
Obligatory disclaimer: I'm not a lawyer and this should not be considered legal advise.
Tor usage may or may not be illegal depending on your jurisdiction. In the United States Tor is not illegal, and I have never heard of anyone actually being convicted (or even arrested) for crimes committed by others over their exit node (though there have been instances ...
Usually Tor stores its log files in /var/log/tor. Depending from the specific settings you'll find /var/log/tor/notices.log, /var/log/tor/log, /var/log/tor/info.log, etc.
The option Log in torrc specifies where the log file is stored and what kind of information is logged. So if you don't find the above mentioned files please have a look into your ...
The "owner" conditional, as per the AppArmor wiki:
The owner keyword is used to make the rule conditional on object ownership. Specifically the task must have the same euid/fsuid as the object being referenced by the permission check.
The problem seems to be that the user that tor is running as (debian-tor is the default on ubuntu and other debian ...
Tor needs an accurate clock to work correctly.
Please sync your time with an NTP (Network Time Protocol) server.
On Debian based machines use package ntpdate.
sudo ntpdate -v pool.ntp.org
w32tm /config /syncfromflags:manual /manualpeerlist:pool.ntp.org
w32tm /config /update
There is no way short of the hypothetical attacks you mentioned to determine if a relay is excessively logging. Excessive logging is a criterion for considering a relay malicious but that doesn't mean that there's a way to verify that it is actually logging sensitive information. However, if a relay operator openly admits to logging data that they shouldn't, ...
The term rend desc refers to a rendezvous descriptor. This is a special node for hidden services. In your case this information is missing and so it fails.
If I understand it correctly you can wait a few minutes and retry your connection. There is a chance that you'll get a rendezvous descriptor this time..
If you've installed tor as a system service through OpenSUSE's package manager:
You can define where tor logs to through use of Log directives in the torrc file, located by default in /etc/tor/torrc.
If it's a system service you'll need to manually configure applications to use Tor, normally through its SOCKSPort. However if it's a web browser, it's ...
After looking into this again after leaving it for a long time, I quickly found the solution.
It turned out that the files in the /var/lib/tor/keys folder were not owned nor writable for the debian-tor user. Make sure to set debian-tor as the owner and allow this user to read and write the files.
chown -R debian-tor /var/lib/tor/keys/*
chmod 600 /var/lib/tor/...
By default stdout and stderr of a systemd unit are sent to syslog. On my machine(Kali distro) it is stored in /var/log/syslog. So to see tor unit output run
cat /var/log/syslog | grep tor -i
In case someone needs to monitor tor unit i found a better way. Adding -f or --follow flag to journalctl makes it to continuously print new entries as they are ...
There is an entire chunk of the wiki dedicated to this subject.
Have a read of Debugging the Tor Browser.
(These are all either internal to Firefox or Linux/UNIX specific...I've no idea how you'd even approach this on lesser operating systems? Windows Event Logs and windbg? Can they reach the output of the extensions or firefox's logs to stderr in any way?)
So I believe I found the answer to this, in case anyone stumbles across this... According to a thread on Tor's bug tracker, this is "normal" and is only a concern if the number is greater than 60.
Quoting user "theor":
Feel free to ignore this, if all the numbers are less than 60. (60 is 1% of a relay's 6000 connections to other relays.)
Debug level logging is disabled as it would contain information that could be dangerous to keep around. If your bridge had serious problems that prevented it from working, these would be available in the standard logging setup.
The easiest way to tell that your bridge is working (if it is not a private bridge) is to check Relay Search. You will not be able ...
It looks like it's trying to fetch information from https://onionoo.torproject.org/ about the relays (I assume over it's own copy of Polipo) and since Polipo is trying to use Tor, which hasn't bootstrapped yet.
It hasn't bootstrapped because you've specified a limited set of reachable ports or addresses in the Orbot settings, and you have configured it to ...
It looks like you need to configure proxy credentials to access the internet.
Onion/Tor Button -> Network Settings
Tick 'This computer needs to use a local proxy to access the Internet' and configure the proxy type, address, port, username and password (all of this information is the same as you would use to access the internet normally).
This is a known issue on Ubuntu/Debian, there's a conflict with apparmor because Tor is still running as root when it tries to scan the hidden service directories. They're looking into making the appropriate changes so that it has changed user when it tries this.
This is documented under #22331.
In the meantime, a workaround from Yawnbox is to edit the /...
The IP address 220.127.116.11 belongs to the host maatuska.4711.se which is a directory authority within the Tor network. It seems it has banned your relay from the network (Fingerprint is marked rejected). So maybe it was the case that your relay messed with traffic or people thought it was harmful to the network. People could report bad relays. So please ...
The answer assumes that your runnig the the tor deamon on the same host as the browser and that DNS lookup are done via Tor. Both holds true if you use the Tor Browser.
If I visit http://expyuzz4wqqyqhjn.onion/ through Tor Browser, does my router see that address or does it only see the first relay Tor Browser connects to?
It only ...
The log you're showing can be MitM - and there's how to check it:
make a su to your Tor user
do a traceroute to the 18.104.22.168 - or also to other IP's that are mentioned in that Problem bootstrapping messages.
If the trace(s) completes OK - then it is a MitM proven. If it's not - do netstat -r and examine your routing table: many VPN's are setting ...
These are versions on the OR protocol which are negotiated between the client and the relay upon connection.
The initiator then sends a VERSIONS cell to the responder, which then
replies with a VERSIONS cell; they have then negotiated a Tor
protocol version. Assuming that the version they negotiate is 3 or ...
If you're using a standard setup with local DNS server located on your very PC - it caches the response locally inside the server, so no second request is made. If you have more questions - feel free to ask!
According to the FAQ:
If you compiled Tor from source, by default your Tor logs to "stdout"
at log-level notice. If you enable logs in your torrc file, they
default to /usr/local/var/log/tor/.
You have a couple of options:
Run Tor from the terminal and pass it the -v flag to output logs to the console. (Though from the above description you should ...
Tor Browser does not keep an on-disk log by default. Instead, you can get the log from the Browser. Click on the green onion, Tor Network Settings, and then on the bottom there's a button to copy the log to your clipboard.
To setup full logging from command line add the following option:
--Log "notice file tor1.notice.log"
This says Tor should log on notice level to the file tor1.notice.log in the local directory. You can also use other log levels and file names as well as stdout for logging to your console.
I recall that in years past, there were arrests of exit-node-operators in some places, e.g. Germany. The arrestee had to convince the legal authorities that the node operator was not the person whose traffic exited the node to the forbidden site. In the meantime, the node operator might have been sitting in jail.
That's why there are a lot fewer exit nodes ...
These log entries are just for notification (Loglevel notice) and provide general information. Tor writes these lines also when it is configured as client. They just tell you that Tor lives and transmitted some data.
If you don't want these log lines go to your torrc and look for lines starting with Log notice. Comment them out and restart your Tor process. ...
I'll summarize the discussion from the comments and the chat here:
The original poster had a system-wide installation of Tor in their Debian system and furthermore installed a Tor Browser.
The system-wide torrc which lives in /etc/tor is different from the one which Tor Browser uses. The configuration from the Tor Browser usually lives inside its ...
As it says it's debug message, so normally you should ignore or disable any debugs.
For that kind of messages I don't think you can find reasonable meaning without Googling it or checking the source code (svn, git), because these messages are mainly for developers.
If you think it could be a bug, check at Tor bug tracker.
The code responsible for that ...