Re: A MAJOR problem with "remote" scanning using ClamAV

Thanks! (And welcome back.) 

I never noticed that option in clamd.conf, nor had it occurred to me that there might be such.  

Since I had previously been using clamd locally for scanning, I used "--fdpass", which does not hit *that* limit, since only the commands are streamed, not the data to be scanned.

In the remote case, I only got "Broken Pipe" (TCP RST), rather that any error message, so it looked like a lower level problem. If clamd had given an explicit response, it probably would have been obvious.

I guess it would work for me to set StreamMaxLength to 2G-1, since the new machine running clamd has 32G of RAM (even though it is far from "high end").

Paul

--------------------------------

On Mon, 1 Dec 2025 22:40:19 +0000
"Val Snyder (valsnyde)" <[email protected]> wrote:

> Hi Paul,
> 
> Sorry for the long delay. I have been away for a couple of weeks.
> 
> ClamD has a StreamMaxLength setting with a default value of 100M which is close to the 105 MB value you encountered.
> I suspect you're running into this limit when streaming files to be scanned.  If you want to send a bigger file you can increase this to match MaxFileSize .
> 
> E.g. set both of these in clamd.conf:
> 
> MaxFileSize 2000M
> StreamMaxLength 2000M
> 
> Respectfully,
> Val
> 
> Valerie Snyder (she/they)
> ClamAV Development
> Talos
> Cisco Systems, Inc.
> 
> ________________________________
> From: Paul Kosinski <[email protected]>
> Sent: Thursday, November 13, 2025 2:01 PM
> To: [email protected] <[email protected]>; Val Snyder (micasnyd) <[email protected]>
> Cc: Akshit Jain <[email protected]>; Kris Deugau <[email protected]>
> Subject: A MAJOR problem with "remote" scanning using ClamAV
> 
> Several people have noted that using ClamAV remotely (e.g., via TCP) does not perform scanning *while* the file/data is being transferred, but only after all the data has been transferred. This makes sense, given the way some signatures work (e.g., those that depend on total hashes).
> 
> But there is a much worse problem that I have observed: sometimes it *never* scans the file/data at all! This happens when there is "too much" data to be scanned. By too much, I don't mean the well known 32-bit size limit, I mean sizes that can easily be scanned locally, either by a direct (but slow) call of clamscan, or a more efficient call of clamdscan with the "--fdpass" option (assuming clamd is running locally).
> 
> Since I am temporarily using ClamAV on a small but powerful new computer and remotely scanning email that way, I also have to use it to scan things like downloaded files. I have had no trouble with email, but some downloaded files abort with "Broken Pipe". Monitoring this behavior with Tshark, I observed that the remote clamd started sending RST packets after about 105 MB of a 170 MB file.
> 
> I haven't studied the source code for either clamd or clamdscan, but I suspect a buffer allocation problem, since TCP has no such inherent limit. (And my new "small" computer has 32 GB of RAM with a recent AMD Ryzen CPU, and doesn't currently have any real load beyond ClamAV.)
_______________________________________________

Manage your clamav-users mailing list subscription / unsubscribe:
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/Cisco-Talos/clamav-documentation

https://docs.clamav.net/#mailing-lists-and-chat