Jump to content
zombunny2

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?

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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.

Share this post


Link to post
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...

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Immunet 7.3.2, what a disappointment!

ClamAV Engine is out of date! How often do I have to repeat this in this forum?
Installed ClamAV Engine is 0.102.1.76

Current ClamAv Engine is clamav-0.103.0
Download:
https://www.clamav.net/downloads#otherversions
https://www.clamav.net/downloads/production/clamav-0.103.0-win-x64-portable.zip
https://www.clamav.net/downloads/production/clamav-0.103.0-win-x64-portable.zip.sig

Update does not work, the updater downloads the daily.cvd but is unable to apply the update.
Shame!!! Read this: https://support.immunet.com/topic/7500-not-updated/

After the manual update of the CLAMAV engine I get the message after pressing Update that Immunet is up to date. However, there is no current CVD file. The update of the CVD files only starts when you press Update button again. Now, thanks to the new engine, successful.
You are really bunglers, if one may say that. Really!

Edit:
The problem could be solved by integrating the update of the CLAMAV engine into the updater and executing it before the update of the CVD files.
For this "idea" I would now like to be rewarded with $ 25 from Cisco.

Edit Part 2:
I also miss in the options "Monitor Network Connections" is this function removed or always ON now???

 

Immunet UI:
The UI is very outdated, just right for a 14 "monitor with a resolution of 800x600, but with today's screens, over 40 you need a microscope .

Thank You

lastupd update.log

Edited by Frank_

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
25 minutes ago, zombunny2 said:

...

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

...

Did you overwrite the old files in the folder %programfiles%\Immunet\clamav\[version] ???
Immunet use the old engine if you create a new folder with the new version of the engine in %programfiles%\Immunet\clamav\.
This folder is set in the configuration files of Immunet and you cant edit this cofiguration file about protection functions of Immunet. (If you edit the file, Immunet cant start and stop protection od the system)
So you have to stop the Immunet service and overwrite the old files i. e. in ...\Immunet\clamav\0.102.1.76
Start the Immunet service and try again the update 2-3 times.
 

This is not a Problem or Bug.
ClamAV doesent Update the CVD Files if Engine is outdated. This is not a bug, it is a security feature.
The update Button in Immunet only check for a Update of Immunet it self and runs freshclam.exe (from ClamAV) to update the CVD files.
Thats all.
So if the Engine is outdated freshclam.exe cancel the update. You can check this also if you run freshclam.exe in CMD.

Edited by Frank_
  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

Don't forget to delete the files lastupd and update.log (a lastupd file can make trouble).
During tests, I always rename the cvd files to see if fresh cvd's are being downloaded.

FrankenImmunet, sounds good.
FrankenImmunet with IgorCloud. 😉

 

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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...

×
×
  • Create New...