itman

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

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.

Let's analyze in more detail logically; something Eset developers appear to be incapable of doing. The above quote implies that Network Inspector is directly linked to Connected Home Monitor functionality. Next is Eset adequately warns that Connected Home Monitor should only be used when the Home/Office profile is the active network connection profile. By default, Eset installs with the "use Windows settings" option. Again by default, the Win 10 firewall uses the Public profile. Therefore the network connection established by Eset is using the Public profile. Since Connected Home Monitor use is N/A in regards Public profile use, by default Network Inspector should be disabled. It should only be auto re-enabled when one switches the active network connection profile to the Home/Office profile.

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 guess I should give a complete network picture associated with the above posted network bindings. This being done so that Eset never attempts to perform Network Inspector activities in this situation. At system restart time which is the only time Win 10 performs full network initialization activities, the router performs the following activities: 1. The router attempts to establish connectivity with a dedicated external AT&T IPv6 DHCP/DNS server with an IP addresses of 2600:xxxx:xxxx:2421::1. The important point to note at this point is that this IP address is not within my assigned fe80:: IPv6 gateway range of 2600:xxxx:xxxx:2420::/60 but within my allocated Ethernet range of 2600:xxxx:xxxx:2420::/64. 2. If connectivity can be established to the 2600:xxxx:xxxx:2421::1 server, this is assigned as Win 10 primary IPv6 DNS server. If this is activity is fully successful, I am assigned an IPv6 lease and my complete IPv6 network subnet is established. I will discuss later what happens if this activity is not successful. 3. Next, the router will try establish connectivity between the 2600:xxxx:xxxx:2421::1 external server and pre-allocated local subnet IPv6 DNS server 2600:xxxx:xxxx:2420::1 address. It does this via ICMPv6 with two necessary types being blocked by default Eset firewall walls upon installation. This specific connectivity many times takes a minute or two after system startup to succeed. If successful, then the router assigns 2600:xxxx:xxxx:2420::1 as my Win 10 IPv6 secondary DNS server; a fact never recorded in Eset DNS server settings in regards to active Network connection status. At this point my IPv6 network is fully initialized and operational. In regards to point 3). connectivity failure that happens on rare occasions: 1. The router will establish limited IPv6 functionality. I have full external IPv6 connectivity but no IPv6 lease is issued nor is my IPv6 local network established. My local subnet DNS dedicated IPv6 address of 2600:xxxx:xxxx:2420::1 is assigned as the primary IPv6 DNS server address. Eset Network Inspector totally borked this processing. 2. After the next system restart activity; usually upon resume from sleep after prior system sign-off, full IPv6 network initialization is completed with lease assigned and local subnet established. At this point, primary IPv6 DNS server address is 2600:xxxx:xxxx:2421::1 and secondary address is 2600:xxxx:xxxx:2420::1.

With Network Inspector no longer interfering with proper configuration of my local network, let's talk about the correct bindings being established. @Marcos, you should find this of interest. I won't talk about the ipv4only.arpa; i.e. DNS64, binding since that one was always being established. First up in the IPv4 binding. Nothing unusual here: Next up is the IPv6 binding: Err, what ..........? Well, not really. The only hardware based gateway on my router is an IPv4 one. Again, this is a Pace IPv4 router that AT&T hacked the firmware to support IPv6. I suspect this assignment of an IPv6 DNS server to an IPv4 gateway is what is causing Eset Network Inspector to go bonkers.

In order to do this, it has to establish a local network "baseline" of legit devices that exist at system startup time.

Since Eset N.A. is located in California, let's review that law. At face value, it appears Eset is violating the law. However, I believe the eStore web site has wording in effect stating by purchasing from the web site, you are agreeing to auto renewal. In other words, implicit affirmation which is a favorite Internet web site tactic. Probably the best way to stop this baloney is no one purchase a license from the Eset N.A. store until an explicit web page opt-out option is provided.

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.

I could reproduce on Firefox using EIS 14.2.24:

As I recollect, the way the Eset N.A. eStore site works is you are informed somewhere on the site web pages displayed that you will be set up for auto renewal. It also states that you can opt-out of this after the purchase by deactivating the auto renewal option via accessing your existing eStore account. Assumed this notification is shown in small print and as such, can be easily overlooked. Also there is no way to opt-out of auto renewal at license purchase time other than terminating the purchase transaction. Such auto renewal practices are not unique to Eset and done by a number of software vendors. What is needed is for individuals to contact their state and federal representatives that laws are needed to force opt-out renewal option at purchase time.

Review this article: https://www.bleepingcomputer.com/forums/t/744537/cannot-remove-browser-assistant-even-w-frst-eset-adwcleaner/ . Toward the end of the article, note the only way to get rid of this bugger extension was to delete the reg. key associated with it. Malwarebytes, AdwCleaner, and like apps are "tuned" to detect this type of crud-ware and eliminate them. And in some cases, it is necessary to resort to Farber Recovery Scan Tool (FRST) with expert assistance to get rid of the stuff.

I will again mention that if my router contained a DHCPv6 server, there probably would be no issue with Eset Network Inspection Inspector processing. It appears Eset is relying of DHCP initialization activities to identify network elements. This router is internally via communication with the AT&T network setting up the IPv6 local network and its related DNS servers.

No, from all the web articles written about it. Refer to this: https://www.pcrisk.com/removal-guides/18544-web-protection-for-chrome-browser-hijacker for further details and how to remove it from Chrome. Note: Do not use the Combo Cleaner mentioned in this article to remove this extension. If you can't remove it manually, Malwarebytes (trial mode) with real-time protection disabled should be able to do so. It appears Eset detects the extension when Chrome starts up and the alert being generated will remove it for the current current browser session only. You need to remove this extension from Chrome to eliminate the Eset alerts.