Jump to content

dp0mu8zgxl

Members
  • Content Count

    30
  • Joined

  • Last visited

  • Days Won

    1

dp0mu8zgxl last won the day on April 23 2014

dp0mu8zgxl had the most liked content!

Community Reputation

1 Neutral

About dp0mu8zgxl

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  1. Would YOU have the confidence to use or otherwise trust an anti-virus, anti-malware or rootkit detection tool that is no longer current or being developed? Consider your answer against the arrival of the next new or amended zero day exploit! Even against the apparently tricky GameOverZeus thing being promised to hit us all in less than two weeks? Two weeks being the assessed time that the authors are likely to take to renew all the stuff the whatever hats took down so very recently.
  2. Do you mean Development (new/amendments) Support will end very shortly or do you mean that Technical (problems/issues) Support will end very shortly? Assuming you meant the former then the remaining (apparently approximately three million) group of IP3 users will be using or saddled with a non-updated security product that is mothballed. Effectively frozen in time or sealed in aspic - never improved and never ever likely to be properly patched!? Now, do we know a story about that one children? ...think Microsoft XP. I purchased the full 2yr/3pcs package a mere two weeks ago so I am considering whether Cisco/Immunet Plus 3 are likely to honour their apparent 30days cancel promise. To whose email address would I or do I address this?
  3. My thinking EXACTLY. Nothing to do with my license key, either machine or their different mechanisms used to get on-line. So you have an internal comms or updating issue within your own (cloudy?) mechanisms - again nothing to do with me or my stuff here. Agreed. As above. Yes, that's obvious too;-) That doesn't stop it being a bug (in your internal mechanisms). Flawed logic (about the relationship with my updating). I only look at the Immunet panel (and therefore observe the '0' threat scenario) when I manually update. That does not mean it only happens when I'm updating Immunet. Anyway I'm watching the squid log tail (which shows your stuff phoning home for the gzip files) and after all that is done and finished I've still seen the questionably erroneous "0 threats)... So, nothing to do with me, my stuff or anything here. I just happen to be the only one who has observed the issue AND taken the trouble to report it to you (eg for resolution). I'm assuming that everyone sees the same threat counter... So just put in a tiny programme loop that flags when the threat counter shows as being zero and then tally that with the logs of your errant internal inter-communications that precipitates the comms outage? The screenshots just show "0 threats" and they're not important unless you just don't believe me... Bluntly, my very basic problem is getting Immunet's prompt attention the second I see the issue in front of me. So that, presumably, you can then see the common indication that I presume is shown to everybody. Slightly amazed that I'm the ONLY one out of your apparent three million plus sites protected that has ever observed this issue. I repeat my earlier recommendation that you write that tiny programme loop and so get to spot it yourselves;-) The issue is not ON my stuff or even happening HERE, it's on your stuff and happening over there. IOW my logs are irrelevant. You need to check YOUR cloudy logs!? Meanwhile my license needed renewing. This has already been done and, this time, it's on a two year period for 3 machines. My tablet's licensed Immunet Plus uses a different hookup to the internet - as earlier emphasized - and this mechanism is TOTALLY different to that of the workstation's access via its very protective server and router. The tablet still sees the "0 threats" issue though the timings seem slightly different - probably due to the ISP's network and/or proxy etc etc. The main point: it's on your stuff and in your area... My uncle died a few days ago. I have been unexpectedly roped in as the only surviving Executor named on the Will. I am on the road shortly and expect to be otherwise engaged away from site for some time. I'd like to think, by the time I return, that you might've isolated your stuff's comms issue, fixed its repercussions (the "0 threats" irregularity) and had it all wrapped up invisibly to all of us users/customers...
  4. My tablet (on a separate cellular data connection) is now showing "0 threats" and is currently about 60% of its way through downloading the files necessary to protect against ..."0 threats". Has it gone mad, is my eyesight up the pole or possibly... do you have a bug? The workstation is on a broadband connection but is on the same 3 machine license. Currently neither machine is showing the "same" threat count. (2014-05-19 1704hrs local)
  5. A screenshot was taken to corroborate. Now showing "74,782,614 threats" (2014-05-19 1652hrs local) Any idea when it'll ever make up its mind?
  6. "0 threats" showing ...once again:-) Has been for at least the last 5mins. (2014-05-19 1646hrs local)
  7. Real time report: Tablet running rootkit scan OK after downloading updates/definitions. Rotating header banner now showing ~72million threats OK. Well... I tried to help you isolate the issue... Now it's back to a none issue again. Am on some travels shortly, there may be a delay if you need any more data.
  8. PostEdit: photo of the tablet's screen :: @1836hrs local it's still downloading (slowly) but with "0" threats :: @1842hrs local it's now at 92% downloaded but now showing the ~72million threats !? (removed picture as everything is just too slow and the forum code has error reports PostEdit: errors from forum code Warning: Illegal string offset 'edit_post' in /home/immunetc/public_html/admin/applications/forums/sources/classes/post/classPost.php on line 2437 Warning: Illegal string offset 'edit_post' in /home/immunetc/public_html/admin/applications/forums/sources/classes/post/classPost.php on line 2214
  9. Happening again ("0" threats) RIGHT NOW on my tablet connected via cell phone. Workstation connected by broadband is showing OK.
  10. FAQ was useful - I had Immunet32137 port redirecting ONLY UDP but have now amended that to ONLY TCP. Normally I do NOT specifically redirect 443, have now set up a (?temporary?) port redirect Immunet443 for ONLY TCP. Once again these are relevant only to the server/workstation, the tablet would've been and still is unaffected. Almost all clouds are 'filtered' source incoming. This does not usually affect our own masquerading (going out from here returning similarly). So, if your stuff attempts things the other way around then it will fail. In conclusion: Ports you nominate are opened, everything else is likely closed. The explanation of your posting limitations was also helpful and I fully understand. You will likely understand the necessarily severe limitations we put on what clouds can see of us;-)
  11. BTW the custom filter sets are based on the server/workstation, they do not affect the tablet, hence the confirmation that I tried using and seeing this issue on the bare tablet hooked up to the router. The router has filters, yes, but none are 'custom' they are just the ones routinely available to each and anyone using a business class router and your Immunet Plus 3. Whereas the filters in the server protecting the workstation are, yes, 'custom';~) I've only 10 more posts 'available' to me on this forum... Is this level of forum limitation appropriate for me? Am I deemed to be SO unsafe? And it's now 1am ...well past my bedtime.
  12. >>If it's not too large you could archive the file as a zip file and upload... Done. >>Since you mentioned you do have custom filter sets in place I'm wondering if that is indeed the cause of the intermittent loss of the cloud connections. That's why I'm taking the trouble to post this thread:-)
  13. Earlier I took the trouble to run the squid log back to around the time of the anomaly (4pm-ish) and saved it out as plain text. Suggest I email the file to someone - who? Probably not something you (or I) want blathered all over the internet.
  14. @rsmith: The service was stopped and started successfully. During the stop the SCAN NOW and the SETTINGS header bar background colour went from a normal default dark blue to a mid grey colour. The OS also complained about the sudden lack of antivirus protection in a tasktray popup. I think the protected/threats poll stopped but I cannot remember specifically. The protected/threats polling seemed to take its time restarting AFTER the properly coloured headers reappeared but I saw no other popup appear.
  15. @rsmith: standby - I've some things to shut down and otherwise do, it's midnight here, back in 5mins.
×
×
  • Create New...