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
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 ...
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
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 ...
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 ...
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?)...
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 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 188.8.131.52 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 184.108.40.206 - 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 ...
The warning was introduced as part of security fix. It is just information that some client was trying to send to you some unexpected SENDME cell which could be used to do targeted memory denial-of-service attacks on entry nodes.
The brief description of that security fix is:
Tear down the circuit if we get an unexpected SENDME cell. Clients
could use ...
According to the Tor FAQ you should be able to find the log files in the following paths:
On OS X, Debian, Ubuntu, Red Hat, etc.: /var/log/tor
Windows: no default log files on Windows. If you enable logging in torrc file, logs would appear in \username\Application Data\tor\log\ or \Application Data\tor\log\
You can always set up custom logging by editing ...