Network tab shows outdated/false information

I’ve just changed the IP addresses of several of the PCs in my home network. They’re all still in the same range they were beforehand ( network), but I just tweaked their addresses to re-order them sequentially the way I’d like.

From my PC where I have Glasswire installed, which is also on the same subnet, but whose IP I haven’t changed, I can successfully ping the other devices by hostname (which resolve to their new IPs) and by their new IP addresses directly.

But in GlassWire if I click ‘Scan’ on the Network tab, after the scan is complete I am still shown the old addresses. The MAC addresses for each network device are shown as being associated with the old IP addresses.

This comes as quite a surprise and a disappointment. It means I can’t trust the information that the Network tab is telling me. I really had thought that after manually initiating a scan, the information would be up-to-date. If I was relying on the information it’s giving me now, without knowing that many of the IP addresses had recently been changed, I’d be in trouble.

The only way I’ve been able to get the IP addresses to update is to quit GlassWire and then restart it. That should not have been necessary.

I’ve tested this again by changing the IP addresses of some more devices, hitting the Scan button in Glasswire, and confirming that the IP addresses don’t update in GlassWire. Then I’ve quit and restarted GlassWire and confirmed that the new IP addresses are then shown.

This is not good. Manually hitting ‘Scan’ (or waiting until the next scan automatically happens) should update the IP addresses. It should never be necessary to quit and restart Glasswire just to get the details to update.

But even after restarting GlassWire and getting the display of the IP addresses to update, the wrong DNS/Hostnames are associated with each device now. There doesn’t seem to be any way to get the mapping of the names to the new IP addresses to update correctly.

What a mess.


Thank you for your report. We’ll investigate and try to recreate this so we can figure out why this happened to you.


Did you restart our user interface or our service? Can you try restarting our service?


I’m finished doing the changes to my IP addresses.

In the cases where I said “quit and restarted”, this means I clicked on the ‘Exit’ menu item in the Glasswire menu. And then I clicked on ‘Glasswire’ in the Windows Start Menu.


Please right click the taskbar and choose “task manager” then “services” then restart the GlassWire Control Service and see if it solves the problem.


What problem are you hoping to help me resolve? Like I said, “I’m finished doing the changes to my IP addresses.” I’m not currently doing any more testing in connection with this issue.

The names eventually updated, but the main concern is the bug concerning the mapping of IP addresses to MAC. I’ve already provided you all the information required to reproduce and confirm the issue. How are you getting on with that?


Have you stopped replying to me? I report bugs in the hopes that the application can be improved and fixed. Am I wasting my time?

After reading the above I thought you no longer wanted replies. Sorry for the confusion. I think the GlassWire control service must have crashed, so your IP addresses would not update.


I really think you’ve totally misunderstood the issue I’m reporting. Please re-read my first 2 posts in this thread, carefully.

After doing that, please perform this test:
1. Take note of the IP address to MAC address mappings on your Network tab.
2. Change the IP addresses of some of those other computers on your network that are visible in your Network tab.
3. Click the ‘Scan’ button in your Network tab.
4. Tell me if the new IP addresses are correctly displayed alongside each of the MAC addresses in your Network tab, i.e. have all of the entries correctly updated, showing the correct new IP addresses associated with each of the MAC addresses. Without needing to restart GlassWire.

I’ve already done the above test sequence multiple times. Thus the reason I said “I’m not currently doing any more testing”. I’m already convinced of the problem. Like I said in my 2nd post, even after I had to restart GlassWire to get it to show the updated addresses, I immediately repeated the test with some additional devices, with the same results. It’s got nothing to do with the local GlassWire service on my PC.

What I’ve been waiting for all this time is for you to do some testing, and for you to confirm that the bug exists, and for you to confirm that the bug will be fixed.


We are unable to recreate this problem on our computers.

I will ask our development team if they have some other ideas on why this happened. They already recommended that your GlassWire service probably crashed and you should try a clean install and see if it solves the problem.

I find that to be a very weak response.

  • The Network tab was still updating as other computers joined and left the network, indicating that the service was running. Everything else in GlassWire was still running and updating too.
  • The GlassWire service doesn’t restart when quitting and restarting the GUI anyway.
  • Each time, after changing the IP addresses on other computers, all I had to do was restart the GUI at which point it then updated those particular entries for those particular computers. I didn’t have to touch the running service.
  • I was able to reliably reproduce the issue multiple times.

So this assertion that the GlassWire service had crashed is complete nonsense. I suspect that you have not actually tested this properly.

I went through the trouble of testing this. I can confirm harkonnen’s findings. This really does seem to be a (small) bug where scanning the network does not flush the cache. I tested it on 4 different PCs and two separate networks. What’s more, some devices initially don’t even show up at all anymore after changing the IP. The IP addresses do update without doing anything at all, but it takes minutes. And that clearly indicates the cache isn’t cleared when scanning the network manually.

Just follow harkonnen’s simple explanation and you’ll surely be able to reproduce the bug. Also, if there’s an adequate developer around, he/she shouldn’t have too many issues clearing the cache by hard coding a few lines right before the scan. So, if I’m right, that’s good news. No need to reinstall anything, no need to restart services (bad practice to do this with any kind of secure layer anyway, as it leaves the system vulnerable).

Having said that; I’m no big fan of the way harkonnen communicates (sorry), but he does have a few very valid points. You could have easily tested this and reproduced the bug. No rocket science here.

Another thing that shouldn’t be advised too often is to reinstall. You guys/girls created a nice piece of software that has great potential. Reinstalling might solve an issue but it destroys an opportunity to find a potential bug, thus it kills an opportunity to create a better product. And a better product is what anyone would prefer, no?

Please try the update we just released this morning and let me know if it solves the problem.


Thanks for the speedy feedback. I think the issue remains. But, just like before, it takes a few minutes before GlassWire clears its cache. Manually scanning doesn’t really make a difference.

The device is reachable (ping) but GlassWire simply doesn’t see it. So, for now we’ll just have to live with waiting a few minutes for the tables to update.


What OS version are you using?

Are you on a WiFi network, or are you connected with Ethernet?

You said you did some detailed testing (thank you for the help). Can you give some details of how exactly we can recreate this? Thanks!

LAN situation #1: (office)

The computers installed with GlassWire are all running Windows 10. One of these is connected through WiFi, and six PCs are connected by Ethernet.

Other devices on the network: iPhone, Android phones (6 and 7) and an Android Tablet (Android 6). Three printers.

LAN situation #2: (home network)

Three PCs rocking Windows 10, with one of those being a laptop. Only the laptop is using WiFi.

Other devices on this network: Android phones (6 and 7), Android Tablet, Google Chromecast, Raspberry Pi (2 and 3), Brother Printer.

In both LAN environments, mobile devices and devices like Chromecast worked wireless.


In both scenarios the LAN uses a Gigabit connection, with Intel Gigabit NICs on the PC end. I installed GlassWire on a PC and a laptop in both scenarios. Every device where you will change the IP, will be registered by the router (or modem), with the correct IP address. All PCs and laptops can be used successfully to ping this address. Using a network scanner, the devices show up correctly as well, with the new IP address.

The Network tab on GlassWire however shows the old information. Clicking on the Scan-button doesn’t fix this. If you wait a few (up to 7) minutes, the information in GlassWire will be updated however. This worked the same on both networks I tested it on, regardless of the device I changed to IP address of. Unplugging, and plugging back in, the ethernet cable didn’t change the result. After plugging back in a PC with a new IP address, showed the PC with the old IP address. In some occasions, it didn’t even show the PC at all anymore. Waiting a few minutes, always fixed the problem however, showing the PC/device and showing the right IP address.

Like I said before, for me this isn’t a big problem. Once you know that you’ll have to wait a few minutes for GlassWire to register the new IP, and new devices on the network, it’s just a matter of patience.

Thanks. I will ask our QA to test and see if we can reproduce this on our end.