No, I mean svchost.exe. Its traffic level is more than 12 MB!
I have seen something similar once before, that when there were two network cards in a box on which CIS was installed.
I think this is just another ‘feature’ of the Active Connections viewer in CIS, there are a few! Personally, I wouldn’t put to much faith in the information displayed in this viewer, it seldom bears much resemblance to the real world.
I have only one network card.
Ok, but I saw this connection as constant traffic animation in the tray, and it was very uncomfortable.
What makes you believe the traffic animation was related to the svchost entry? Moreover, what makes you believe the animation is accurate?
Because I didn’t have any other active network connections about 15 minutes (I watched it in TCPView) but all this time I saw permanent animation in the tray and svchost activity in Comodo viewer.
There are no connections shown in TCPView in the image either, but there’s plenty of network activity.
[attachment deleted by admin]
But Comodo is not sniffer…
The point I’m making is, even when there are no apparent network connections, there can, on occasions still tray animation and sometimes when there is traffic, there’s no animation. You don’t need wireshark to see the difference, use WMI or Procmon, maybe Networx or even Rainmeter.
Ок, but in my specific case is it not a bug if I can see in Comodo Viewer and tray animation DHCP activity of another computers in my local network, but can’t see IPTV activity with traffic level about some GB. Or it’s by design?
How long is that system up and running? What’s the DHCP lease-time for the connection?
Can you run a packet capture with e.g. Wireshark to see what’s really flowing over he network…
If the application is placed into the TFL then we don’t get any alerts from Comodo even with Proactive Security. That is because of: Comodo allows the Trusted Files to access to the Protected Files and Folders(including \Device\Afd\Endpoint). That’s why my topic Smart TVL. 2 TVLs instead of one is more than important now!
would be interesting to see what the developers forgot to implement the CIS versions 3,4,5. XXX Version 2 of Comodo Firewall Pro 2 with respect to the firewall :-TU
I’m having this activity in Comodo immediately after I have connected a network cable, and it may continue very long.
You seem to be on a LAN/Cable network with a subnet x.y.z.0/24 with a pretty short Lease-Time hence the enormous amount of DHCP Informs.
I removed the Images from your post as they seem to contain your Public IP/Range.
Probably a bit of both. As I said earlier, the Active Connections viewer only tells part of the story. In the image you can see there’s no mention of VLC, in Active Connections viewer, listening or otherwise, yet it’s receiving a stream and is obviously quite active. The only guess I can make, in this scenario, is that the Active Connections viewer doesn’t display unconnected endpoints, but that’s not the only ‘problem’ Really, if you want to know what’s happening on your network, don’t rely on the information displayed in CIS.
[attachment deleted by admin]
With regard to the DHCPInform packets, these are usually sent when a client is looking for additional options either not supplied by the DHCP server or incorrectly supplied. You’d have to look at the details of the packet to see which options are being requested. If there are excessive numbers of these packets being generated, it could mean the DHCP server is responding incorrectly or not at all. Looking at your screenshot, it would appear the each client is sending two DHCPInform requests, but because of the filter you’ve applied we can’t see the response from the server.
Radaghast, Ronny, thanks for your answers and explanations.
Radaghast, as I can see, you use VLC media player for Internet Protocol Television. As I have understood, VLC, as well as IP-TV Player, opens 1234 port and receives inbound connections on it via loopback interface, but Comodo doesn’t filter this incoming requests to loopback zone, as comfireuser wrote above. Is it correct?
Not quite. The stream still has an origin and a destination, so you’ll still need firewall rules to support this. Depending on your configuration, you may need both Global and Application rules. In my case I have the following:
Global rule:
Action - Allow
Protocol - UDP
Direction - In
Source Address - The address block my ISP uses for IPTV
Destination Address - The PC IP address
Source Port - Dynamic Ports
Destination Port - 1234
Application Rule
Application Name - vlc.exe
Action - Allow
Direction - Out
Protocol - TCP
Source Address - The PC IP Address
Destination Address - The Address of the EPG server
Source Port - Any
Destination Port - 80
Application Name - vlc.exe
Action - Allow
Protocol - UDP
Direction - In
Source Address - The address block my ISP uses for IPTV
Destination Address - The PC IP address
Source Port - Dynamic Ports
Destination Port - 1234
Rather bizarrely, when I was playing with things again today, for no apparent reason the vlc connection suddenly appeared in Active Connections viewer. Alas, it only appeared once, even though the connection was opened and closed numerous times.
In case you’re wondering about the ‘malware’ alert, it’s probably because I use nightly builds of vlc.
[attachment deleted by admin]
I have a different situation. I have the same Global rule as you, but in Application Rule for vlc I allow only TCP OUT and block all other IN and OUT. But despite this vlc works well, and I’ve never seen the alert for UDP IN without blocking rules.
[attachment deleted by admin]
Perhaps your IPTV service works differently to mine, although I notice you’re also using IP-TV Player, which I also get from my ISP, I seldom use it, however. The reason I allow outbound connections is so that the Electronic Program Guide can be updated. I also have rules not shown above, these are to allow various streams from Internet radio.