GlassWire service and the NetBios

I’m sorry you feel the answer is generic. We aren’t a big company who puts out generic answers to our users.

Do you see these Netbios requests when GlassWire is not installed and your computer is rebooted?

I think Windows 10 sends out a lot of user data for its “Asimov” feature http://windowsitpro.com/windows-10/microsoft-not-tracking-your-every-waking-moment-windows-10 so maybe that’s what you are seeing with Windows 10. With Windows 8.1 I don’t know.

Possible a thing of name resolution via NetBIOS?

Theoretically it’s possible that IP to DNS resolving could produce Netbios activity but we checked all our machines here and we were unable to reproduce this.

I’m noticing this on two 2008R2 servers as well! Are you guys sure there’s nothing to cause this behavior in Glasswire?

@evan2 We could never recreate this on our end. Maybe it has something to do with Windows 2008 server? We just released an update, please upgrade https://blog.glasswire.com/2016/08/05/glasswire-1-2-73-now-available/ and see if it goes away.

This looks related to the issue I raised about the NetBIOS Name Service:

At the time I remember doing some investigating and this is the most relevant part of what I found.

The short story: Get rid of legacy NetBIOS devices/configurations

Windows NetBIOS Name Service broadcasts because there is a legacy device or configuration setting for NetBIOS over TCP/IP but there is no longer a WINS (Windows Internet Naming Service) server running to resolve the names. In this situation NetBIOS broadcasts are a fallback mechanism for resolving names.

When you have a device with a NetBIOS name then that name needs to be resolved to an IP address. See Is WINS Still Needed? for more info - I added the bold emphasis :

Be aware however that decommissioning WINS doesn’t just mean pulling the plug on all your WINS servers. To properly decommission WINS in your environment, you will also need to remove any WINS settings in the TCP/IP configuration of clients and servers on your network. …
If you have any legacy hardware like NAS devices that are hardcoded to use NetBIOS for registering themselves on the network, and you can’t or won’t replace these devices, then you will need to implement some workarounds so they can continue working properly once your WINS servers have been removed. Typically this will mean creating static DNS records for such devices to register them with your DNS servers.

That article has links to Microsoft articles on resolving the issue.

It is likely that GlassWire developers cannot replicate the issue because they have a modern network without legacy issues. That is not the case for my network.

More background on NetBIOS over TCP/IP

When you have a device with a NetBIOS name then that name needs to be resolved to an IP address.

Older versions of Windows, pre Win-NT, use a WINS (Windows Internet Naming Service) server to resolve it.

WINS primarily supports clients that run early versions of the Windows operating system and applications that require NetBIOS. Later versions of Windows including Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012, Windows 2000, Windows XP, Windows Vista, Windows 7, Windows 8 use Domain Name System (DNS) names in addition to NetBIOS names. Environments that include older computers that continue to use NetBIOS names on the same network as computers that use DNS names must use WINS servers in addition to the DNS servers.

If WINS is not running then NetBIOS name resolution proceeds as if there is no WINS entry for that NetBIOS name - see bold emphasis below. NetBIOS over TCP/IP Name Resolution and WINS:

  • Check to see if it is the local machine name.
  • Check its cache of remote names. Any name that is resolved is placed in a cache where it will remain for 10 minutes.
  • Try the WINS Server.
  • Try broadcasting.
  • Check the LMHOSTS file, if the system is configured to use the LMHOSTS file.
  • Try the HOSTS file and then a DNS, if so configured.

Understanding NetBIOS Name Resolution provides more info on this process. See Do I need NetBIOS for more info on SAMBA/SMB and legacy apps.

It is easy to see if NetBIOS broadcasting is happening. In GlassWire Usage view by selecting Traffic and then the NetBIOS Name Service:

Use nbtstat:

Nbtstat is designed to help troubleshoot NetBIOS name resolution problems. When a network is functioning normally, NetBIOS over TCP/IP (NetBT) resolves NetBIOS names to IP addresses. It does this through several options for NetBIOS name resolution, including local cache lookup, WINS server query, broadcast, LMHOSTS lookup, Hosts lookup, and DNS server query.

Here I use nbtstat to see broadcast stats:

C:\Users\Me>nbtstat -r

NetBIOS Names Resolution and Registration Statistics
----------------------------------------------------
Resolved By Broadcast     = 47
Resolved By Name Server   = 0
Registered By Broadcast   = 118
Registered By Name Server = 0
NetBIOS Names Resolved By Broadcast

       HPLJ4650-A4    <00>
       JOHN           <00>
2 Likes

Hey guys, reporting that I too am having the same problem / bug.
Open your task manager and click on the performance tab as
an alternate way to check your network connections.
Here is a short video that can assist you with work arounds:

I just created an account to bump this, THIS HAS TO BE FIXED!

I noticed this issue after “System” started spamming a ton of different gameservers with NetBIOS traffic that were automatically pinged in the server list for latency tests for a game, even long after I closed it.

The data usage might not be big but it adds up, GlassWire is literally spamming IPs with garbage traffic.

I just disabled NetBIOS and it stopped now.

By the way, I am not sure how exactly NetBIOS works but there is often talk of security issues with it, is this a concern with queries like this?

GlassWire does not spam anything.

Our software does nslookups on hosts you connect to so inside GlassWire you can see when you connect to an IP, it resolves to Google.com for example. This is a popular feature of our software and it uses no noticeable resources.

However, if an nslookup on a host is upsetting to you for some reason you can disable nslookups so you can no longer resolve hosts you connect to.

  • stop the GlassWire service;
  • open C:\ProgramData\GlassWire\service\glasswire.conf as admin;
  • change the value to hostname_enable_nslookup to false;
  • save the changes and restart the GlassWire service.

I think you don’t understand what we are talking about here, especially since you renamed the thread from “NetBIOS” to “BIOS”, something unrelated.

When I disable NetBIOS in Windows, the “spam” from GlassWire stops, but the host names are still resolved. This can be confirmed by doing nslookups manually, these two things are completely unrelated.

NetBIOS is a different type of name resolution, due to a weird thing in Windows, it tries to do it before the normal DNS lookup if certain network conditions are present (legacy devices or bad router config, which is common in ISP routers). This also likes to get stuck and do other weird stuff.

While it technically “isn’t your job to fix” as it is partly a Windows issue, considering how common this is, you should look into providing a workaround, possibly in the form of a setting to prevent this from happening.

It is also a privacy issue as this NetBIOS spam occasionally continues for a while after the connection has stopped which may be an issue for VPN users.

Edit: Just to be clear: “System” (probably on behalf of GlassWIre) sends NetBIOS requests to hosts for multiple minutes after the initial connection, there is no way that is intended behavior.

GlassWire doesn’t do anything on the network besides check for updates (software and malicious host list) once per day, and do nslookups on hosts. Instructions on how to disable nslookups are above in this thread.

If you don’t want GlassWire to check for updates you can make it block itself under its own firewall.

GlassWire does not do anything with the NetBios.

Maybe you are just looking at traffic between our service and our UI on your own PC or something like that? If that’s the case, then this is local traffic between our service and UI and it does not use the network at all.

Again, this is 100% a NetBIOS related issue, disabling NetBIOS over TCP/IP removes this traffic. Someone in this thread also said that this occurs due to the lookup order in Windows.

Frankly, I suspect that unless you write your own nslookup this will remain an issue.

Wouldn’t just using the DNS cache make nslookups unnecessary?

Thanks for your feedback.

GlassWire itself is just a network monitor and it doesn’t really use any significant network resources, besides doing some simple nslookups and software update checks. And as I posted previously you can make GlassWire block itself with its own firewall, and instructions on how to disable nslookups are above.

Also, please note our Android app has no ability to access the network at all.

I will submit this thread to our team and see if they have any comments.

Our team asked if you tried the nslookup disable option as suggested above, and if that made the NetBios traffic you are seeing go away or not? Thanks.

I just tested it and it made the traffic successfully go away (I made sure to turn NetBIOS back on during the test).

It’s still something that should be addressed, considering it seems to be an issue with nslookup looking up NetBIOS instead of directly jumping to DNS/hostfile it shouldn’t be necessary to completely disable that functionality (If you can’t just disable NetBIOS).

Just adding that when checking the network traffic in my PC (Win10 Pro) I saw NetBIOS traffic as well (didn’t check if it was GlassWire related) but I’ve turned off the NetBIOS for my network adapter so it would stop

@Thinking

If you have our nslookup feature on, but your PC is in “Block All” mode and you don’t see any network activity in GlassWire, do you see NetBios activity?

I’m asking because if it’s the nslookups somehow, then if GlassWire is NOT doing any nslookups (due to no network activity) then perhaps there should be no NetBIOS activity?

Also if GlassWire’s service is killed do you see NetBios activity? Thanks.

The NetBIOS traffic stops when Block all is on. (And it resumes when it’s off, I just tested it)

I am not set up to check if it stops when the service stops (GlassWire obviously doesn’t record activity when it’s stopped) but considering the nslookup feature is clearly the culprit here as disabling it fixed the issue it has to be an issue with GlassWire.

The way to know if the nslookups are the issue would be to stop our service, then watch the NetBios traffic. We’re unable to recreate this on our end.

Please let us know if you’re able to check and what you find. Thanks.

If you guys go to Control Panel -> Network and Internet -> Network Connections (adapters) -> Right Click the adapter you use -> Properties -> IPv4 (click Properties when selected) -> Advanced… -> WINS -> Enable NetBIOS over TCP/IP (it should force it on without router config) and then turn on nslookup in GlassWire config and go to websites (websites with CDN like youtube or twitch are the best) do you see NetBIOS traffic from “System”?

Doing this should to my knowledge replicate what is happening for me and the other users. If this doesn’t work for you please let me know because I can try something but it might be a bit difficult and I don’t want to waste time figuring it out if this replicates it for you guys.