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
