Aptann

Switched to pre-release and ran an update, and the problem remains. I'm on Windows 10 x64 And here's the module list: Virus signature database: 12684P (20151207) Rapid Response module: 7142 (20151207) Update module: 1060 (20150617) Antivirus and antispyware scanner module: 1475 (20151204) Advanced heuristics module: 1163 (20151201) Archive support module: 1241 (20151124) Cleaner module: 1116 (20151113) Anti-Stealth support module: 1091 (20151117) Personal firewall module: 1292 (20151111) ESET SysInspector module: 1257 (20151113) Real-time file system protection module: 1012 (20151124) Translation support module: 1429 (20151119) HIPS support module: 1207 (20151130) Internet protection module: 1238 (20151124) Web content filter module: 1046.1 (20151202) Advanced antispam module: 2899P (20151207) Database module: 1072 (20150831) Configuration module (33): 1213B.8 (20151124) LiveGrid communication module: 1020 (20150807) Specialized cleaner module: 1010 (20141118) Banking & payment protection module: 1056 (20151207)

Disabling protocol filtering worked. I've sent the pcapng files in a PM, I didn't feel comfortable uploading those anywhere public. Here's some code to reproduce the problem: server.py import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind(('127.0.0.1', 8080)) s.listen(1) conn, addr = s.accept() try: data = conn.recv(1024) print(data) except Exception: pass conn.close() client.cs using System; using System.Net; using System.Net.Sockets; using System.Text; namespace this_is_broken { class Program { static void Main(string[] args) { var client = new TcpClient(); client.Connect(new IPEndPoint(IPAddress.Parse("127.0.0.1"), 8080)); var stream = client.GetStream(); var greeting = Encoding.UTF8.GetBytes("hello server!"); // adding \n, \0, or \r anywhere inside this string will allow it to pass through stream.Write(greeting, 0, greeting.Length); client.Close(); } } } Edit: For convenience, here's the client written in python import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 8080)) s.send('hello server!'.encode()) # adding \n, \0, or \r anywhere inside this string will allow it to pass through input() The recv call ends up blocking until the socket either is closed, or until \n, \0, or \r is written to the stream.

I noticed recently that TCP streams weren't acting like I was expecting them to. Specifically, write operations would sometimes not reach their destination until a null byte, newline, or carriage return was written to the stream. At first I dismissed it as a bug with the programming language I was using (golang), but then I noticed the same behavior in other languages(python, C#). I managed to figure out that it was Eset Smart Security's doing. Disabling the firewall made no difference, but uninstalling Smart Security fixed it. I'm assuming this is a bug. But, if it's not, Is there a setting that could affect this?

No luck, it's still happening

Bump

Safe mode re-install did not work either.

Automatic and learning modes makes no difference on the problem. I have also formatted(unrelated reason) and re-installed Windows after this problem started happening, which didn't help. I'll give a safe mode re-install a try though.

I did a re-install yesterday, which gave me a newer version. Disabling application modification detection didn't help, it's still happening.

Unless that option would affect programs that haven't been modified then I don't think it'll make much of a difference. I'll try disabling the feature though. Can take a couple of hours before I get results.

A couple of months ago the firewall started misbehaving. I'm not sure if it was an update to Smart Security or the upgrade to Windows 8.1(from 8) that caused it. I've confirmed that it's the firewall causing it though, turning it off makes the problem go away. The problem is that processes will seemingly at random stop responding to internet related tasks. The process will act as if there's a working connection, but it gets stuck doing whatever it was trying to do. So for example if a program needs to get information from a website, it'll say it's getting the information indefinitely, without any timeout when there's supposed to be one. Basically, it's as if the connection is frozen. When closed, the process will remain in the background, and attempts to kill the process is met with "Access is denied". The only way to get rid of the process is to restart the computer. It's not a permission problem, I've been ruled out. It's also not any specific process, it can happen to anything that attempts to access the internet. I have formatted(for unrelated reasons), and re-installed Smart Security recently without any luck. I have contacted Eset about this, and was instructed to turn off firewall features and see if it would stop. The problem with that is that these problems can be far and few between, sometimes taking a whole day before I notice that something's gotten stuck, so that'd take too long to test out. I will do it, of course, but I was hoping perhaps someone else could shed some light on this issue before I delve into it. I did some Googling when this first started, and my findings suggested it could be related to the firewall failing something in the kernel.