"Client terminated connection early"

Hi Jeff,

In your savdid.conf please can you check the scanprotocol section to see if SUBDIR is specified? 

Regards,

Stephen

Yes, and I've tried with DIR as well.

Any ideas?

Come on Sophos.

Don't make us switch to ESET.

We're stuck here.

Hi Jeff,

Are you able to share your SAVDID Conf file please?

Please can you also confirm how you are sending the files for scanning/which ICAP client you are using?

Regards,

Stephen

# No of worker threads to start up
threadcount: 8
maxqueuedsessions: 4

onexception: REQUEST  
onrequest: SESSION

log {
type: FILE
logdir: C:\ProgramData\Sophos\SAV Dynamic Interface\Logs\
loglevel: 3
}

channel {

logrequests: YES

commprotocol {
type: IP
address: xxxxxxxx 
port: 1344
sendtimeout: 2
recvtimeout: 2
}

service {
name: avscan
type: avscan

scanprotocol {
type: ICAP
allowscanfile: SUBDIR (Have tried with removing completely, subdir and dir)
version: 1.01
allow204: YES
tmpfilestub: C:\ProgramData\Sophos\SAV Dynamic Interface\Temp\icap_
}

scanner {
type: SAVI
inprocess: YES
savists: enableautostop 1 savigrp: grpsuper 1
}
}
}

My message from the wirecap.

Here's the wirecap:

And as you can see, there's no disconnect of the client, only after I receive the Server Error from the server. [Last entry]

It only seems to affect normal files. (.exe, .com, etc)

Does not affect .zip or .rar files. They work fine.

Here are some comments from one of my colleagues:

• ‘threadcount’ is set to 8.  We recommend that you have no more than 2x the number of cores on the system for ‘threadcount’.  Is this a 4 core system?
• The ‘loglevel’ set to 3 which is not a valid value.  You can have 0, 1, or 2.
• Unlikely it’s the issue, but it might be worth increasing the value of ‘recvtimeout’ just in case the connection is being closed because the sending client is taking big pauses whilst sending and hitting this timeout.
• In the ‘scanprotocol’ section there is an entry for ‘allowscanfile’.  This is not an option supported by ICAP.  ICAP only supports scanning file streams, it does not provide the facility to instruct the scanner to scan a file by path.
• The ‘scanner’ section appears to have all the scanning options on one line, that may be a copy/paste error but just in case, each option must be on a line of its own

• Looking at the wireshark image the data string is definitely not eicar. It shows as a file called ‘note.pdf’, so if you have created a PDF file that contains the eicar string then no, this will not get detected.  Our detection of eicar is specifically against the actual eicar test file (eicar.com), we do not have detection that looks for the eicar string in every other file type.

Addressing them in numbers;

1. It's a 2 core system. We changed to 4. Still the same problem though.

2. We tried to get more debug logs while trying to identify the problem, trying to fix it ourselves. (a lot companies hide additional logs that way) Too bad you didn't.

3. Tried with >60, but nothing changed. 

4. We've now tested without, and it's still the same problem.

5. Copy-paste problem.

6. Sure, sorry about the confusion. Yes, it's the EICAR-String, (check the hexa-data). But that's simply because we've tried with different file-endings (in this case, .pdf), just to find SOMETHING else, other than the 500 server error.

The only files that reports a VIRUS is [note2.zip] and [note2.rar] (CONTAINERS). Which both contain the [note.exe], (which contain the eicar-string).

So. 

We've been stuck here since the 8th.

Getting kinda tired of this.

Hi Jeff,

I appreciate this is frustrating, have you created a support case? We can escalate your ticket and add steps, but we may well need to involve development. 

In the meantime, have you run this test locally on the server that is running SAVDI? I wonder if the configuration of Sophos AV is only looking at archives and we need to check that configuration rather than the SAVDI config.

Stephen