Jump to content

Incorrect Ethernet Packet


Recommended Posts

Starting having this issue this morning.  With Unknown devices with incorrect Ethernet Pack.  I did not happen any other day and I did not change anything.  Should I be worried about this?

EsetForum.PNG

Link to comment
Share on other sites

  • Administrators

I would ignore it. Should you continue getting this message, we could check the network communication to confirm that the detection is correct but that's all we will be able to do.

Link to comment
Share on other sites

Here's Eset description:

Quote

Incorrect Ethernet packet – Too short of a packet was received. Packet is too short to contain valid Ethernet or IP/IPv6 header.

https://support.eset.com/kb2958/?locale=en_US&viewlocale=en_US

My best guess is there might be a problem with your router.

Edited by itman
Link to comment
Share on other sites

The only thing I can think of that is triggered these alerts, is the Eset IDS Packet Inspection setting of :

Quote

Verification of incoming/outgoing TCP and UDP packets (checksum validation) – Select this option for testing purposes only. This functionality validates the checksum of incoming/outgoing TCP/UDP packets.

The problem is that this setting no longer exists in ver. 12.1.31. If one is using a prior ver. of Eset and this setting exists and is enabled, disable it and see if that resolves the alerts.

Link to comment
Share on other sites

I "spoke to soon." Just saw it on ver. 12.1.31 and appears related to an Akamai server connection:

Eset_Ethernet.png.cf54609b2b583c9f5c4625fa252ea9bb.png

Edited by itman
Link to comment
Share on other sites

Appears Microsoft might have snuck in some hidden telemetry in the last 1809 cumulative update. Perhaps in regards to upcoming 1903 Feature upgrade?

Link to comment
Share on other sites

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 are extremely slow.  Other network apps that look for the hosting PC listener and resolve the access criteria is still failing.  I have disabled the firewall which did not seem to help. 

Edited by Kurt
Link to comment
Share on other sites

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 comment
Share on other sites

I just checked my Eset Networking Protection log; something I don't do regularly since its usually empty.

This incorrect ethernet packet business started at yesterday's cold boot at 8:29 AM EST. This was prior to the 1809 cumulative update which occurred in mid-afternoon. So it is not related to that. Also there was no Eset module update activity yesterday or prior to that for some time. Did received a module update this morning however which appears to have not resolved the issue.

Very strange activity here I must say.

Link to comment
Share on other sites

17 minutes ago, Kurt said:

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

That depends on what you have installed at the network perimeter. For example If you have a commercial grade router with a stateful firewall, NAT, DoS protection, etc. etc., then Eset IDS would only be protecting your internal network from internal attacks for the most part. On the other hand if you have an infected client/device on the network, you're SOL.

Edited by itman
Link to comment
Share on other sites

Some further info in my case.

All the inbound Akamai traffic is originating from this IP address, 2600:141f:8000:19c::4106. The other inbound traffic is from various Microsoft servers. All traffic is TCP and IPv6.

Definitely looks to me Microsoft is the culprit here.

Edited by itman
Link to comment
Share on other sites

Grrrr …..…… I read the log wrong.

In my case its outbound traffic being block. In other words, the source IP address is my ISP assigned IPv6 address and the target IP address is Akamai or Microsoft.  Since no application is recorded in the Network log, it is almost impossible to what Is the source.  Although it appears at this point, it is anything performing outbound IPv6 Internet traffic. 

Link to comment
Share on other sites

  • Administrators

Please get logs as follows:
- 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 comment
Share on other sites

I have an SR open, do you prefer I place the log file there?  What is the name of the file, there are many generated in the diagnostics folder.

Edited by Kurt
Link to comment
Share on other sites

  • Administrators
1 minute ago, Kurt said:

I have an SR open, do you prefer I place the log file there?

Yes, provide the log to customer care and post the generated archive here as well. It will be accessible only to ESET's staff.

Link to comment
Share on other sites

The update from support was to reinstall ESET.  I have 6 PCs that are exhibiting this behavior, sounds a little silly to reinstall.

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.

 

Link to comment
Share on other sites

A bit of an update.

Did the ipconfig /release6 and /renew6 bit which didn't help. What is a bit strange is /release6 or /release, did that also, did not terminate my network connection as always occurred in the past.

Upon signing on again after resume from standby mode had a slew of Network log entries, 19 in total, all attempting to connect to  IP address, 2600:141f:8000:19c::4106 and Microsoft server associated IP addresses as stated previously.  No further Ethernet packets log entries after that point so far. One of the first things Win 10 does at boot/resume time is dial out for Win Store updates. I suspect Microsoft pushed a borked or possibly malicious Store update yesterday or late evening before that. Now to find the "bad guy." 

Edited by itman
Link to comment
Share on other sites

Well, so much for the Win Store app update theory. None on 4/8 and first update on 4/9 was at 10:30 AM. As noted previously, the Ethernet packet log entries started at boot time on 4/9; i.e. approx. 8 AM.

However, it is obvious to me this issue is in regards to the servers hosting Win Store updates. Why is "my gut telling me" Microsoft is using some new tunneling protocol crap that Eset is "hiccupping" on.

Link to comment
Share on other sites

Latest theory is Microsoft is using some new ICMPv6 Type Code that is not defined in the Eset default "Allow essential outgoing ICMPv6 communication" firewall rule.

In any case, starting to believe this is related to Eset firewall rules and not IDS.

Also the Eset blocking is bogus since its only supposed to manifest on inbound traffic which not the case per logged Eset Network entries.

Edited by itman
Link to comment
Share on other sites

Thank you for the info.  - A point of clarification,  I tried disabling the firewall and the ESET Network Protection errors still occur.

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.

Link to comment
Share on other sites

This is definitely related to Win 10 Store updating. Connected to the Store and performed a manual update. Ended up with a bunch of new Eset Network Protection log entries.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...