Jump to content

Recommended Posts

16 minutes ago, Kurt said:

I am also required to disable the IDS to allow access to my hosting machine for an internal app which I still have not received an answer to why that is happening.

Leave Firewall and IDS alone for the time being.

Refer to the below screen shot. Right click on one of the related Network log entries and select "Don't block similar events in the future." This should create an IDS exception for this activity. See if that stops your logging and corresponding network share performance issues. I am not going to do so presently since I not getting that many log entries; only for Win Store related activity.

Eset_Ethernet.thumb.png.3aab190314c371a5a46817203d95a8a9.png

Edited by itman
Link to post
Share on other sites
  • Replies 92
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I am also having this issue and now I am unable to share files on the network.  This occurred after the most recent windows 10 update on 4-9-19.

Unblocking these "Incorrect ethernet packet" errors (and there were many, DNS, DHCP, Microsoft Publication Service (there were multiple of these), and  Akami) the network file share works, but they ar

Disabling Network Attack Protections (IDS) on the PC being accessed has addressed the issue of accessing the fileshare quickly and allowing access to the app hosting machine (screenshot reflects my PC

Posted Images

59 minutes ago, itman said:

Connected to the Store and performed a manual update. Ended up with a bunch of new Eset Network Protection log entries. 

Can you share steps to accomplish this?

Link to post
Share on other sites
16 minutes ago, Kurt said:

I got it, I am seeing the same additional log entries.

Forgot to mention that when the IDS exception is created, it will only create the exception for the IP address associated with the log event. Refer to the below screen shot. Open IDS Exceptions in the Network Attack Protection section of the Eset GUI  . Then edit the existing exception removing the existing Remote IP address. This will then apply the exception to all IP addresses. 

Eset_Exceptions.thumb.png.46839a180d29b3000a0a36c4e5e4129e.png 

Edited by itman
Link to post
Share on other sites
32 minutes ago, Kurt said:

Can you share steps to accomplish this?

https://www.thewindowsclub.com/check-for-windows-store-app-updates

-EDIT- Another way to do so: https://support.microsoft.com/en-us/help/4026259/microsoft-store-check-updates-for-apps-and-games

Edited by itman
Link to post
Share on other sites

I also noticed something else odd.

For some reason, "Filtering" was enabled on my Eset Network protection log. I know I didn't manually do so. I have since disabled it and will wait if that somehow has something to do with this unexpected protocol data issue.

-EDIT- Nope. No relation to this very odd Eset behavior.

Edited by itman
Link to post
Share on other sites

Damn it - another Eset bug.

I just noticed the IDS exception created by right clicking on the Network log entry is not the correct one! It created an "Unexpected Network Protocol" exception instead of an "Incorrect Ethernet Packet" exception. So you will have to manual delete the "Unexpected Network Protocol" exception and add an "Incorrect Ethernet Packet" exception.

Now see if the blocked network activity stops.

Link to post
Share on other sites

I finally got "Incorrect Ethernet Packet" IDS exception to work. I had to set the Direction in the rule to "Both" and presently doing it by detected IP address; after verifying the IP address is associated with a Win Store connection.

Sure hope Eset figures out what the problem here is proto. 

-EDIT- Forget any exceptions. When I set direction to Both I started seeing blocked Google server connections appearing whose IP addresses were never seen before.

Appears to me something serious is borked in IDS detection.

Edited by itman
Link to post
Share on other sites
  • Administrators

If possible, please provide logs generated as follows. Until then we cannot carry on and check what is causing the error:

- enable advanced logging under Help and support -> Details for technical support
- reboot Windows
- reproduce the error
- stop logging
- gather logs with ESET Log Collector and provide the generated archive.

Link to post
Share on other sites

again, how is this done?  What is the log file name?  Your instructions do not properly  allow me to generate what you are looking for.

Please provide better instructions on how to provide the log files you are looking for.

Link to post
Share on other sites
17 hours ago, Kurt said:

I need guidance on what disabling the IDS affects and what is my risk if I leave it disabled.  Doing this solves my issues other than Incorrect "Ethernet packet errors" on all machines. 

Once again.

Link to post
Share on other sites

Thanks Itman.

I appreciate your troubleshooting help.  I think your initial thoughts that the router is bad may have some merit.  I think the firmware on my modem/router maybe outdated and not correctly passing and/or sharing IPv6 addresses correctly confusing ESET and blocking the communications.  I am working with my internet provider to check the firmware and possibly replace the modem to remove that piece of the puzzle.

I have built my internal routing table to address intrAnet communications so PC to PC communication is now working.

Thanks again.

 

 

Link to post
Share on other sites

A new update today.

Observed Eset Networking log activity at today's first cold boot. It's not just Win Store network activity causing the Eset IDS detection logging, but all outbound activity to Microsoft. For example, BackgroundTaskHost.exe, etc.. In total, 45 event log entries created.

I also did a hard reset on my router last night to no avail. All Eset has to do to duplicate this on a Win 10 1809 build is to reboot the device.

The question now is only Win 10 1809 affected or are prior Win 10 versions also?

Link to post
Share on other sites
18 minutes ago, Kurt said:

I think your initial thoughts that the router is bad may have some merit. 

I don't believe that is the problem since multiple Eset users are having the issue.

Microsoft has changed something on at least Win 10 1809 in regards to its server communication and that is what Eset needs to concentrate on.

Also why when an IDS exception for an "Incorrect Ethernet Packet" log event is created, does Eset generate an "Unexpected Network Protocol" exception? Note the Eset definition for this:

Quote

Detected unexpected data in protocol – Improperly formatted ARP, DNS or ICMP echo packets. Or zero port in TCP/UDP/.

"My money" at this point is on Microsoft has changed something in their DNS protocol requests and Eset can't handle it.

Edited by itman
Link to post
Share on other sites

@Marcos these are the IP addresses connections from Microsoft related Windows processes running at boot time. None are domain routable addresses from what I can determine:

2600:141f:8000:195::4106

Akamai Aggregate 
location - United States 
ptr - g2600-141f-8000-0195-0000-0000-0000-4106.deploy.static.akamaitechnologies.com

2a01:111:200a:8::ff04 - Microsoft V6

2a01:111:f330:1790::a01 - Microsoft V6

Edited by itman
Link to post
Share on other sites
On 4/10/2019 at 10:06 AM, Kurt said:

Disabling Network Attack Protections (IDS) on the PC being accessed has addressed the issue of accessing the fileshare quickly and allowing access to the app hosting machine (screenshot reflects my PC which has IDS still enabled, but is initiating the access).

I need guidance what disabling the IDS affects and what is my risk if I leave it disabled.

IDS.png

 

Link to post
Share on other sites

I disabled the Network Attach Protection on the pc hosting the data and it resolved the issue completely. Thank you.  And Thank  you Microsoft.....grrrrrrrr.

What is still baffling me though is that I have another  pc in the office that similarly has mapped drives on the same pc's as above and there was NEVER any slow down.  Access to pc-A was always  good while access to pc-E was bad.   I checked and both of these pc's (A and E) that have drives mapped TO THEM had the same update on 4/9 (KB4493509).  Does anyone have  an idea  of  why this occurred this  way?

Link to post
Share on other sites
7 hours ago, Kurt said:

I need guidance on what disabling the IDS affects and what is my risk if I leave it disabled.  Doing this solves my issues other than Incorrect "Ethernet packet errors" on all machines. 

Anything yet?

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.
Note: Your post will require moderator approval before it will be visible.

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.

  • Recently Browsing   0 members

    No registered users viewing this page.


×
×
  • Create New...