Immunet 7.3.2 update error

[zombunny2]

Hi,

Well, I tried out version 7.3.2 as it appears to have been released within the last few days, but alas there are still bugs...

Basically the clamav module won't update. Steps to reproduce:

1. enable clamav and definition updates in the settings
2. click "update now" in main gui.

Expected result:

• ClamAV main/daily/bytecode cvd files are downloaded
• GUI says "update completed"
• main/daily/bytecode cvd files appear in C:\program files\immunet\clamav\[version number]\

Actual result:

• The updater downloads daily.cvd, which reaches 100%, and then the GUI notifies the user, "unable to apply the updates. please try again later"
• No cvd files appear in c:\program files\immunet\clamav\[version number]\ (although one file, windows.cvd, already exists in this folder).

This was done on a completely fresh installation of Immunet. I've tried restarting the computer. I know clamav isn't the greatest, but I still like to have some offline detection.

Hopefully it's just a quirk on my particular computer, or maybe the server is temporarily busy. Has anyone else observed this?

[ritchie58]

Oh no zom! I was really, really hoping that this new build would have fixed the previous update issues. Now I'm not so sure that's the case with what you're reporting! "Bummer!!"

I don't use the ClamAV module since I have Immunet paired with another paid AV product so I'm not experiencing this issue of course but the ETHOS/SPERO cloud look-ups seem to be currently functioning normally, so far anyway.

Yeah, try waiting a day or two and then manually update ClamAV to see if the same behavior happens again.

[lavamagma]

i didn't notice this, although i did make fresh install as precaution (answering "no" to final question). this is preliminary view only.

[ritchie58]

Glad to hear that you're not experiencing the same ClamAV update behavior lavamagma.

If any user sees the same behavior as zombunny2 then please post an additional thread to this topic.

[lavamagma]

seems that it's more complicated.

first machines it's seems to work but second machine i get same error. gui is not clear on this. maybe it's timeout. i'm looking what's going on, but anyway it's a bug, what makes this bug annoying, it won't happen all cases.

as a speculation, if downloading of clamav definition files happen quickly then it works.

[ritchie58]

"Oh boy, here we go again!" I'm sorry to say that it does appear that the new 7.3.2 build has the same ClamAV updating bug as the last 7.3.0 build. I don't understand why the devs are having such a hard time fixing this issue. I know I'm not exactly pleased with this current situation!

At least the cloud look-ups are still thankfully happening (for now) but that's little consolation for those that want to use the ClamAV module. If the exact same 7.3.0 scenario takes place even the cloud look-ups will eventually cease to function as well. I hope I'm wrong on that prediction though.

Regards, Ritchie...

[zombunny2]

Sorry to have been the harbinger of doom!

I agree with lavamagma in that it is probably some sort of timeout issue. A while back I started experiencing update timeouts with both Freshclam and the "clamav-unofficial-sigs" scripts on my GNU/Linux boxes. It was basically caused by a time-out value that was too low in freshclam.conf (or wget/curl's default settings, in the case of the unofficial signatures script). Once the database had grown to a certain size, it was impossible to download it quickly-enough for the entire file to be complete before the timeout was reached.

This was initially noticeable with the unofficial signatures script, because the SecuriteInfo "old" database is extremely large (~300MB), and SecuriteInfo restricts download-speeds for free users to circa 384KB/s.

I believe a change to the default freshclam.conf fixed this in one of the recent versions.

I suspect that you won't see this issue if you've already downloaded all the ClamAV databases once, because subsequent updates only require downloading the latest .cld patches.

One way to test this would be to manually download the ClamAV databases from the web site, stop Immunet's service, copy them to Immunet's ClamAV dir, and then restart Immunet. Another option, if Immunet honours freshclam.conf settings, is to look to see if freshclam.conf is present in the folder, and set the ConnectTimeout and ReceiveTimeout settings to something like 300 (5 minutes) and 3600 (1 hour) respectively.

I may have a quick look at these two options when I am next back in Windows.

[zombunny2]

Another thing that had occurred to me, is that it could be a "self-protection" or "permissions" issue. The Immunet program folder is not writeable while the service is running. I wonder if Immunet has forgotten to give itself permission to write the databases to the folder?

[zombunny2]

Wow, that's strange! I've just reinstalled Immunet (I had uninstalled it, selecting "no", so that all data and settings would be deleted). The first thing it did was update the ClamAV databases successfully!

I hope this was just a temporary glitch. Fingers crossed it's now fixed...

[ritchie58]

Out of curiosity did you save your settings this time around when you uninstalled & reinstalled zom?

Still though, that's a less than ideal fix to get the ClamAV module to work again. But if it worked that's the important thing I guess.

[zombunny2]

Hello Ritchie, in answer to your question, I never save my settings when I uninstall. I like to keep a new install / upgrade as "pure" as possible because it has historically saved me from various issues with Immunet - so I do a fresh install and manually add my settings or exclusions back in.

[ritchie58]

Hey zom, thanks for getting back to me.

I was just curious if that had made any difference if you save your settings or not.

Is the ClamAV module still updating normally for you after the reinstall?

[zombunny2]

Hello Ritchie, the machine that started working experienced multiple failures updating the database after this first initial update - and then I think might have subsequently updated successfully.

---

As an additional test...:

I have tried Immunet on a second machine and nothing works to make the ClamAV module update on the second machine:

• I tried editing freshclam.conf to change the timeouts to much larger values. Update still fails.
• I tried booting from GNU/Linux and manually copying recent (a couple of days old) clamav cvd files to Immunet\clamav\[version] folder. Update seems to have been attempted once and failed. No further updates are attempted when clicking "update" in the Immunet GUI.
• I tried uncompressing the latest windows 64-bit clamav portable zip file from the ClamAV official website, overwriting the files in Immunet's %programfiles%\Immunet\clamav\[version] folder. No updates are attempted when clicking "update" in the Immunet GUI.

I'm not sure what the difference is between the two machines. They're both 64-bit Windows 10 and Immunet was a fresh install (i.e. any previous installation had been removed with the "save settings: no" option).

There is a log file in Immunet's ClamAV dir, which indicates that the ClamAV engine itself loads into memory, but I've not found any log file detailing what happens during an update attempt.

It's a shame, as ClamAV can actually have a really good detection rate if you supplement it with the Securiteinfo and Sane Security custom databases. While attempting to diagnose it, I'm reluctant to customise my installation beyond anything required for the diagnostic effort, though.

[ritchie58]

You're right about that Frank. Immunet's program/config files are hardened against manipulation while the program is running. This is a built in security feature.

[zombunny2]

Hello Frank, yes I do overwrite the old ClamAV version, effectively making a "FrankenImmunet" with version 0.103.0 of ClamAV in Immunet's "0.102.1.76" folder. Critical files such as freshclam.exe etc. get overwritten, and the module seemingly loads correctly (and even detects things if you manually put the ClamAV database in there yourself) - it just doesn't update itself.
I don't think it's a ClamAV version issue, as old versions of ClamAV on Linux boxes (or even the abandonware ClamWin package) are still capable of updating themselves, although really old versions of the engine of course balk at newer databases and won't load them properly. Also - at least one of my Immunet installations has updated itself at least once since I started noticing this issue.

I think it might be some sort of Immunet self-protection issue, as the update is attempted and at least one cvd file will download to 100%, but it then won't subsequently be installed in Immunet's ClamAV dir.

It's still not ideal that Immunet are bundling an outdated ClamAV engine with their software. I will try to update my FrankenImmunet again, because this solution fixed update-problems on previous versions of Immunet. It may be that after doing this modification I didn't realise my database was still current, so naturally there'd be no updating to do.

[ritchie58]

FrankenImmunet? I have to admit I got a chuckle or two out of that Frank!

That's an interesting analogy considering the fact that you don't know what behavior you'll encounter from one day to the next with the last few builds I'm sorry to say!

Cheers, Ritchie...

[ritchie58]

Oh no master! Don't tell me it's raining again! Igor doesn't like the rain! Lol!

[zombunny2]

This thread gave me a smile (much like the kind of smile you get when you wake up, open your coffin-lid, and see that the moon is full)!

I have been doing a bit of investigating on every Windows machine I can get my hands on.

Update Bug

It seems that when I install Immunet the "normal" way, I get varied results.

Whenever I have installed Immunet via the "Chocolatey" package-manager, it's worked perfectly and as-expected. This could be a coincidence, but it might be worth looking at the Chocolatey install scripts to see how the Immunet installer is called. All my Chocolatey-installed Immunet installations update the ClamAV engine as expected, with no kluges or workarounds necessary.

"Restore from Quarantine Failed" Bug

I think I detailed on another thread elsewhere on this forum, that occasionally, the "restore" feature failed, causing a quarantined file to be lost for good.

I have noticed that this failure only occurs if the machine is under load, especially if you try to restore the file while Immunet is still performing its scan. A workaround is therefore to ensure that any Immunet scan has completed, and the machine is sitting idle, before attempting a restore from quarantine.

This to me implies some sort of "timeout" issue between separate threads of Immunet - for instance the GUI thinking that the service isn't responding because the load on the machine is causing it to take too long. The solution would of course be to increase the relevant timeout value to a few minutes at the minimum.