Inconsistent Ekrn.exe Network Connection Behavior

[itman 1,659]

Through prior testing and network connection behavior observation using a network connection monitor such as TCPView, normal ekrn.exe behavior is to maintain two persistent internal UDP network connections. One which shows as a 0.0.0.0 connection is used for polling LiveGrid servers for connectivity status. The other is a localhost connection to 127.0.0.1. The inconsistency I am observing is for the localhost connection.

Normal ekrn.exe behavior is to establish the localhost connection at boot time and the LiveGrid connection shortly thereafter. However, this is not always the case on my Eset installation. For example, today upon first cold boot, the localhost connection was never established. Upon a later system restart, it was. However for the prior two days at least, the localhost connection was established at cold boot time. Such is inconsistent ekrn.exe UDP connection behavior observed.

As best as I can determine, this inconsistent behavior doesn't appear to affect base Eset proxy activities such as SSL protocol filtering. Not so sure as to LiveGrid download activities since from prior observation, ekrn.exe UDP proxying is used for DNS connectivity purposes.

This inconsistent behavior appears to be more pronounced since upgrading to ver. 11.1.54 although I believe it did occasionally occur in prior Eset versions.

Once possible source of conflict could be Win 10's IP Helper service which also establishes connectivity on 127.0.0.1 for UDP. The service is set to Automatic by default. Will experiment with setting the service to Manual to see if that helps.

Wonder if Eset starting using a different UDP localhost address such as 127.0.0.2 as a possible mitigation? 

Edited June 20, 2018 by itman

[itman 1,659]

Well, manual startup for iphlpsvc is not the way to go. It never started. That is a bit strange since when I was having issues a while back with LiveGrid, it forced me to do a "deep dive" into this service functionality. At that time, I swore that service started up from manual mode.

Anyway, It became obvious in short order that a bunch of Windows IP-HTTPS tunnel traffic and I assume likewise Eset traffic was being blocked without this service running. So I changed the service startup to Automatic - delayed and so far that seems to be working out OK. Eset's localhost connection is immediately established at boot time and it appears most of Win's IP-HTTPS traffic is not being blocked prior to the service startup.

Edited June 21, 2018 by itman