Ping, traceroute etc. in Firewall view

#1

When I do stuff in cmd.exe, I can see for example when I’m downloading with wget.exe. GlassWire’s Firewall view clearly shows network activity on the process wget.exe. However, if I use ping.exe or traceroute.exe, even they work (they clearly connect), GlassWire shows absolutely nothing. Those executables won’t show in the Firewall view at all. Why don’t they show? Are there more processes that GlassWire doesn’t show? How to get everything to show?

1 Like

#2

@jhoy

While developing GlassWire we found blocking ICMP https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol was not useful, and sometimes harmful so we do not block ICMP.

Also Windows blocks pings by default, but you can unblock it if you want. https://www.howtogeek.com/howto/windows-vista/allow-pings-icmp-echo-request-through-your-windows-vista-firewall/

0 Likes

#3

@Ken_GlassWire, I think that you have misunderstand what @jhoy is saying. I’ll rephrase the first question as follows: Why doesn’t the Glasswire Firewall view show the System application which is used for traceroute commands and the like?

I’ll illustrate what happens when I perform traceroute (tracert in Windows) in a command window. I can see the traffic recorded in GlassWire’s Usage view. The following screenshot shows at the bottom a tracert command with a list of IP addresses for the route. The top of the screenshot shows GlassWire’s record of network usage for the highlighted System application and IP addresses matching those in the traceroute:

Just for completeness, I can see that the traceroute traffic is categorized as NetBIOS Name Service

But when I am in GlassWire’s Firewall view, I cannot see the traceroute traffic. The System application is not shown in the Firewall. See how System doesn’t appear in the list in the following screenshot:

P.S. I remember others asking about this before so I searched and found:

0 Likes

#4

Thanks Remah for the clarification. Also would be nice to understand how it works for cmd.exe. I never see cmd.exe in the lists either. (Although, I do not see NetBIOS Name Service anywhere either. Not in Usage, not in Firewall.) I don’t mind if cmd.exe doesn’t show up, but it would be nice if it also did, if I could block all network activity that is launched from within cmd.exe.

0 Likes

#5

We found in our beta testing of GlassWire many years ago users would block “system” traffic and screw up their network activity and blame this on GlassWire. Since we removed this “system” block ability around 4 years ago nobody has ever asked about it until now.

GlassWire still shows the “system” network activity but it does not appear on the firewall. Would you think it would be useful to see it on the firewall, but not have the ability to block it? We can do that.

2 Likes

#6

We decided we will show “System” on the firewall on the next update.

3 Likes

#7

@jhoy

I played around with cmd.exe and I could not make it connect to the Internet. If you have a way to make cmd.exe legitimately connect to the network itself and it’s not showing up in GlassWire let me know.

0 Likes

#8

cmd.exe is a Windows shell that provides access to the Windows operating system through the command-line. It has some internal commands (dir, cd, rd, etc.) that it processes itself but these are generally not network related I remember that there are a couple of exceptions, one of which is using network shares.

I’m not going to test it but if you changed the current directory (called a folder in Windows Explorer) to a network share then there should be some network traffic.

Most of the commands that produce network traffic are external commands that will show up as themselves in GlassWire. Here’s an example using Name Server Lookup - I chose this for the example because, unlike most network commands, the nslookup process stays resident until I exit it:

2 Likes