Re: TLS errors

[Hans Schnehl <torvallenator@xxxxxxxxx>]

Thx for the fast replies, I wasn't really scared but rather curious about what the logs were saying. 



On Wed, Jan 02, 2008 at 05:22:36PM +0100, Csaba Kiraly wrote:
> Hi,
> As far as I can tell (I'm not a developer) the error message you see  is 
> normal behavior, just logged in a way that scares people ;)
> Of course it can also be something else, but you can find a possible 
> explanation in my previous mail in the "no traffic?" thread:
> http://archives.seul.org/or/talk/Nov-2007/msg00038.html

I read the message, and there is a simularity, mayber there is something about openssl
with freebsd, as Scott Bennet  lso runs a freebsd machine.
Mine is running  now with freebsd7, but the logs did show up also with fbsd6-stable. 


> 
> The cause is a housekeeping operation at the other side, which tears down 
> your connection, but for some reason the TLS session is not closed nicely.
> Messages in the two logs should be similar to the following (say "auth1" is 
> your machine, "auth2" is the other node):
> 
> auth2   Nov 06 13:18:50.660 [info] run_connection_housekeeping(): Marking 
> duplicate conn to 193.168.2.1:34066 obsolete (fd 16, 140 secs old).
> auth2   Nov 06 13:18:50.660 [info] run_connection_housekeeping(): Expiring 
> non-used OR connection to fd 16 (193.168.2.1:34066) [Obsolete].
> auth1   Nov 06 13:18:50.661 [info] connection_read_to_buf(): tls error. 
> breaking (nickname auth2, address 193.168.2.2).

All correct, the ones I cannot really understand are those:
Jan 02 12:46:14.711 [debug] crypto error while performing RSA decryption: oaep decoding error (in rsa routines:RSA_padding_check_PKCS1_OAEP)
Jan 02 12:46:14.711 [debug] crypto error while performing RSA decryption: padding check failed (in rsa routines:RSA_EAY_PRIVATE_DECRYPT)

and the ones with:
Jan 02 12:45:57.965 [info] TLS error: <syscall error while writing> (errno=1: Operation not permitted)
Jan 02 12:45:57.965 [info] connection_handle_write(): tls error. breaking.
Jan 02 12:45:57.965 [info] TLS error: <syscall error while writing> (errno=1: Operation not permitted) 
 

what should be not permitted ?

strange...
> 
> This does not justify bandwidth problems, so you might have to look for 
> some other reason as well ....
> Csaba
> 

I reckon one reason for bandwidth behaviour is, the node runs with another secret-key, as I lost the original. 
It may take some time until it is 'named' again, so the 7 authorities handle the node  
differently. 
How long does it take nowadays for a registered name to expire and the name to be used for (in my case the same) 
new machine ?
 

> Alexander W. Janssen wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> Hans Schnehl wrote:
>>   
>>> Hi,
>>>     
>> 
>> Hi!
>> 
>>   
>>> Jan 02 12:46:06.204 [debug] TLS error: <syscall error while reading>
>>> (errno=54: Connection reset by peer) Jan 02 12:46:06.204 [info]
>>> connection_read_to_buf(): tls error [connection reset]. breaking
>>> (nickname NoNickNode, address 111.112.113.114).
>>>     
>> 
>> It looks like one of the nodes you have a connection too just kicked you
>> out for some reason ("connection reset by peer"). This is pretty normal.
>> Could be the remote node shutting down the software, rebooting and such.
>> 
>>   
>>> Jan 02 12:46:14.711 [debug] crypto error while performing RSA
>>> decryption: oaep decoding error (in rsa
>>> routines:RSA_padding_check_PKCS1_OAEP)
>>>     
>> 
>> Not sure about those, but it could be consecutive errors resulting from
>> the encrypted connection (TLS) being shut down.
>> 
>>   
>>> Tor is running, but appears to be using only fractions of the
>>> bandwidth it is supposed to. Can someone please give a short
>>> explanation?
>>>     
>> 
>> No idea about that though. But it usually takes some time until everyone
>> learned about your node - from my experience it takes up to 24 hours
>> until the bandwidth is fully utilized.
>> 
>> I'm just guessing from my generic experience :)

I had with Tor 0.2.0.7 and ..06 a full utilizatiojn of bandwidth within 
roughly 2 to three hours after reconnection,
but that was lost somewhere with the next -0.8- to todays -0.15.

Regards

Hans