Seen in log: > ---------------------------------------- > Exception happened during processing of request from ('::ffff:10.40.0.48', 62314, 0, 0) > Traceback (most recent call last): > File "/usr/lib64/python2.7/SocketServer.py", line 568, in process_request > self.finish_request(request, client_address) > File "/opt/thinlinc/sbin/tlwebaccess", line 613, in finish_request > ForkingTLSServer . finish_request ( self , request , client_address ) > File "/opt/thinlinc/modules/thinlinc/tlstunnel.py", line 77, in finish_request > o00ooooO0oO = request . recv ( 8 , socket . MSG_PEEK ) > error: [Errno 104] Connection reset by peer > ---------------------------------------- It's a very short window for this though, so I'm not sure how to trigger it.
I was able to reproduce this issue when performing some nmap's to collect info about supported TLS versions, like so: nmap -script ssl-enum-ciphers -p 443 foo.bar.se | grep -E "TLSv|SSL" This was run on a public available webaccess server. While browsing through the log I found that this has happened in the wild as well, most probably due to all the noise coming in from the Internet. This could lead to consfusion/frustration as to why there are trace backs found in the tlwebaccess.log
We can see this happen now and then on our public ThinLinc-server, so it does produce some log spam in real systems.
