Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 3 subscribers
  • Views 14012 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

"Client terminated connection early"

Jeff Olsen

Hi there!,

 

 

So when I send the EICAR file for example, it says that my client disconnects (It doesn't.)

 

But some other files that I send DOES not say that the client disconnects and continues either clearing the file or marking it as a violation.

Which should exclude any syntax related errors.

 

This pattern is consistent as well. The same file works each time, and each file that doesn't work, never work.

 

 

In wire shark I can see that the server returns;

500 Server Error

505 Unsupported Protocol or Version

 

 

Why is it saying that the client is disconnected on certain files? And how do I stop it?

 

Any ideas?



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to Jeff Olsen

    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

  • 0 in reply to StephenMcKay

    # 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]

  • 0 in reply to Jeff Olsen

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

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

  • 0 in reply to Jeff Olsen

    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.
  • 0 in reply to StephenMcKay

    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.

  • 0 in reply to Jeff Olsen

    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

  • 0 in reply to StephenMcKay

    Yes please!

    Did not know we could create a support case. Please do!

    Ok.

  • 0 in reply to Jeff Olsen

    Please send me your support case id when you have created it. bottom right of the screen if you've not done this before.

    Stephen

  • 0 in reply to Jeff Olsen

    Thanks Jeff,

    Are you able to confirm if you can run these tests locally on the server and remove SAVDI from the equation? 

    Regards,

    Stephen

Unfiltered HTML