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
