SlashRose

Good advice. I am tired of wasting my time in this forum reporting Eset problems that ultimately get dismissed.

itman can't explain that to him, he's always right, he's not true, but he believes it, so let's let him believe in it. 

I will again reiterate what happens on my EIS installation when Network Inspector is enabled.
At system restart time, a half dozen ekrn.exe UDP and UPDv6 are established along with an ekrn.exe port 138 connection. These remain for a couple of mins. and are then dropped. In the past, one ekrn.exe UDP and UDPv6 remained. On ver. 17, the UDPv6 connection is usually permanent dropped and not later reestablished.
Upon resume from Win 10 sleep mode, a dozen ekrn.exe UDP and UPDv6 are established along with an ekrn.exe port 138 connection. These remain for a a couple of mins. are then dropped. In almost every instance on ver. 17, the UDPv6 connection is usually permanent dropped and not later reestablished.
In regards to the ekrn.exe UDPv6 connection when dropped. If I perform anything related to current network status such as ipconfig /all or view network settings in Win 10, the ekrn.exe UDPv6 connection is reestablished and remains in effect until system shutdown/sleep mode.
With Network Inspector disabled, I have no borked Eset firewall activity where my normal outbound network traffic is being interpreted as inbound traffic and being blocked upon resume from sleep mode. Although there have been two incidents where this occurred for a couple of port 53 DNS connections.
Now really, is this passive behavior?
Network Inspector stays permanently disabled on my device.
-EDIT- BTW the same above behavior occurs the minute the Network Wizard is opened with the result being the ekrn.exe UDPv6 connection being permanently dropped.

Err, what? I posted previously that it resolved all my IPv6 connectivity issues and Eset recognizing that an IPv6 exists via establishment of an ekrn.exe connection monitoring UDPv6.
All of them. There never has been an issue with the Win 10 firewall properly recognizing my IPv6 connection or interfering with any aspect of it connectivity processing.
I have previously posted Eset needs to provide an option to only use its firewall for outbound network traffic of user custom rules. All other network traffic would be handled by the Win firewall.
This, I 100% disagree with. If everything I have posted in this thread hasn't  effectively communicated there is an issue with Network Inspector, nothing I posted further would do so and would be a waste of my time.

I need to correct my prior postings in regards to Eset Network Inspector and network inspection processing.
Eset's network inspection processing is a critical security mechanism used to inspect IPv4 and IPv6 network traffic via proxy mechanism. It is "baked" into Eset and there is no way to disable it. Nor should you ever want to do so. Its malfunction in regards to monitoring of IPv6 network traffic in ver. 14 is the primary reason I embarked on this long resolution quest.
Eset Network Inspector is the newer feature Eset introduced to monitor router tampering activities. It however does deploy Eset network inspection processing to do so. Besides Network Inspector borking my router's IPv6 configuration activities at system startup time, it was also failing to initialize the network inspection IPv6 network connection.
BTW - disabling Network Inspector doesn't appear to fully disable its processing. Another Eset feature that uses it is the Network Wizard. The difference being when the Wizard is deployed is after system startup time. Since my router would be fully initialized at this time, it causes no adverse activities to occur against it.

Interesting.
My ISP router has an excellent stateful firewall plus IDS protection. Hence, external network attacks like these are dropped on the WAN side of the router. Also, more reason to disable Eset Network Inspector if there are suspicions it might be tampering with any internal router mechanisms.

It sort of says it "helps" with identifying open ports and vulnerabilities, but doesn't seem to indicate it has any protective role. So how is it a critical security mechanism?  And on a side note, now I have to/should post about updates hanging again, this product is a mess. 
 

Correct.
It also resolved a more serious issue that manifested on ver. 17. Upon resume from sleep mode, it appears the Eset firewall wasn't initializing itself properly; or not fast enough. Note this didn't happen upon every system startup from sleep mode, but it happened enough to be disconcerting.
Network Wizard showed blocked svchost.exe inbound traffic to ports 53, 137, 1900, 3702, 5353, and 5355. The "rub" is the remote IPv4 address shown was my device assigned IPv4 address. In other words, Eset firewall; or more likely Network Inspector, wasn't initializing properly and was interpreting legit outbound traffic from my device as inbound traffic and blocking it!

I, like you itman and others, no longer see Eset as trustworthy and where since Corona the attacks have increased a few times. This is not a fine kind of Eset.

Well, it didn't take AT&T long to detect my Cloudflare IPv6 DNS server usage and start interfering with that. So I am now back to using their auto assigned DNS servers and Eset's networking resultant borking of those connections.
But I have finally confirmed the Eset culprit. It is the Network Inspection feature. Disabling that not only solved the auto IPv6 configuration by my router problems but most importantly, the totally spastic Eset firewall behavior upon resume from sleep mode.
I also question the use of Network Inspection processing when the Public profile is deployed. Its applicable Eset firewall rules only allow Trusted network device communication. When using the Public profile, no local network devices are trusted.

But in the case of updating the end user is only half the equation. The company should be logging updates as well and trying to find a solution. Turning users into trouble shooters is not the answer. All this constant drone to submit logs is driving users away. 

Kind of ridiculous putting all the work on the end user. 

What are you talking about I totally agree, you are correct in your opinion this away from the users.
I am finding that ANTIVIRUS ESET does not have TELEMETRY to identify all these problems.
The worst thing is that the updates of the product problem fixes take a long time to get out to the END user, that's because we pay dearly for the product, so much so that competitors like KASPERSKY products are very cheap and have several promotions and even more has FREE antivirus.
I am finding that ESET is unable to work faster.

By default, Eset network Profile selection is "use Windows settings." As I previously posted, Win 10 firewall default network Profile setting is Public. Therefore if using default settings on both, Eset's Network profile would always be set to Public.
-EDIT- Some additional detail here.
Win 10 firewall defaults to the Public profile for a reason. It auto disables Network Discovery. The way you're supposed to securely do file sharing on a Win 10 device is to right mouse click on the file to be shared on the network and select the "Give Access" option.
This also brings up why Eset has the "Home or Office networking" profile option in the first place since it in effect, overrides Win 10 built-in network security. The most damning aspect of the Home or Office networking Eset profile is it enables NetBIOS access by default.

This error has been around for quite a while, namely since the Windows 10 May Update.  
I find it really, very strange that the Eset developers/coders do not notice this and this error is taken over by Eset from build to build, as well as other bugs and all this moved me to stop constantly sending logs etc. and not to engage me so much anymore, 

What I am observing is there is a bigger issue. Appears Eset is not properly initializing coming out of Win 10 fast startup mode. I am having issues with Eset Network Protection; namely Network Inspection not working properly.

It's a new day. I have discovered a new networking feature, And of course, Eset networking support borked it!
The new and important find is if you are using an IPv6 only network which is the case for my ISP, AT&T Unverse, and using third party IPv6 DNS servers, you should be using DNS servers that fully support DNS64. Again, DNS64 is used to convert IPv4 addresses to IPv6 addresses in a 4-6-4 tunnel on the ISP network. The new find is Cloudflare has such dedicated servers. You can read about this here: https://developers.cloudflare.com/1.1.1.1/ipv6-networks . Great! Set my network connection to those IPv6 addresses and modified Eset's connected network setting likewise.
Now for the Eset bork of this capability. The first thing I noticed was it appeared Eset was having trouble establishing a connection on port 8888 likewise on port 443 which is what Push Notifications falls back to. Sure enough, after a half hour Eset displayed the dreaded could not establish a connection to its Push Notifications server. So what is the friggin problem?
Eset Push Notifications uses the MQTT protocol designed to create machine-to-machine; i.e. tunnel, connections to IoT devices. It appears this protocol is not compatible with DNS64 which makes sense if you think about it. So once again Eset implements something without thoroughly testing its compatibility with established networking features.  @MarcosEset needs to be sending Push Notification traffic via IPv6 to resolve this issue. Assume Eset will have to provide a GUI setting option to receive Push Notifications via IPv6 or IPv4 connection. Or better, if Eset sees an IPv6 connection is established, prefer that over IPv4 for Push Notifications communication.

This sounds like the same issue I had, which I added to the posts on here 
 
I had noticed the updates generally had been quicker as of lately, and didn't notice much system issue. However while this update occurred, the PC was very sluggish, with Google Chrome for example taking a while just to open, and browsing seemed very slow, like Eset was causing it to be slow. However I did download a test download from https://www.thinkbroadband.com/download, using the 512MB one which was a lot bigger than Eset's update. I was able to download that in about a 1-2 minutes while as Eset took well over half an hour and even crashed at the end and had to restart. 
The thing is I can't remember any update issues before the updates where designed to use less resources. I don't know if this feature is any good because if anything it seems to be causing more resource issues/slowdowns, like everything is waiting for Eset to finish

itman is almost always right, is here the best man on forum.

I feel the same itman, especially because rarely anything comes out of it!

The bug is Eset known and is not only since the current build!

Same never-ending product update happens on one of my machines.  Real PITA.  Rebooting is the only thing that gets ESET out of update stuck mode.  Happens periodically.  Probably happens to a great many users and they don't see the sys tray icon spinning and realize the sluggishness is due to ESET.

A while back I recall seeing an answer to the problem of continually spinning ESET icon showing update in progress when it isn't.   The solution that worked for me was:   Open ESET>Setup>Advanced Setup (lower right corner)>Update>Under Basic - clear the update cache>click OK>Restart your computer and all should be well.   Hopefullly!

100% there is no problem of my system, there are one or more Eset problems and these are already running through several builds as confirmed by me and other users here!

I too have this problem, with optic internet, solid notebook, yet it still keeps on updating every time i boot the computer and spend hours on it, it never stops.