Jump to content

Immunet 7.3.2 update error


Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

"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...

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...