This is just a curiosity for me at the moment, but might be important to someone.
Normally when I select a different one of my Wi-Fi access points, (or “Mobile Hotspot” on 172.20…) GlassWire shows a DNS Server change to my Surface Book’s default IPv6 address, and then to the other Wi-Fi AP - all of them ancient and v4 only (my WISP here in “Northwest Nowhere” doesn’t provide v6 connectivity and the max bandwidth fits easily in Wi-Fi G, so silly to upgrade them.)
Yesterday I was in the city, where the SB automatically connected to my 5 GHz Wi-Fi ac system with full IPv6 connectivity - and GlassWire 1.2.64b apparently didn’t notice! In the screenshot, there are no DNS Change notifications for 21 June. Looking back in the list, it has never noticed this server, all the way back to 1.2.53 in March.
So does it miss Windows “Connect automatically” network changes? Connections to 5GHz ac instead of 2.4 G? IPv6 servers? Maybe this is yet another Surface Book mystery? The 2.4 and 5 GHz support in the SB show completely different MAC addresses, and the ac AP log often shows the 2.4 MAC is connected when Windows says it is using the 5G adapter, so something is confused there.
Just noticed that when it changes from anywhere to 10.1.1.1, which is the local “Connect automatically” AP, it does not report going through the default v6 DNS. But it still notices the change. That change is not actually automatic, like going to the city. I have to manually tell it to let go of the other local AP and connect back to the default one.
Can anyone explain this? Maybe it intentionally doesn’t report a change when the system wakes up in a new location?
The two Wi-Fi G APs that always get logged when I switch between them both point to the same OpenDNS servers. But unless you’re tracerouting them you wouldn’t know that - they show the router IP, 10.1.1.1 and 10.1.2.1, for DNS as far as clients inside my networks know.
The one that doesn’t show up in the DNS Change log identifies as 10.1.10.1 (or fe80::fa1a:67ff:feca:8584%10), and internally points to Comcast for DNS. So again if you’re just asking Windows you wouldn’t know that.
I did solve one bit of mystery… The MAC the ac AP once suggested was the Surface Book’s 5GHz adapter (and that’s how I faithfully recorded it) turns out to be a friend’s iPhone! As I’d expect, the SB presents the same MAC on 2.4 GHz as it does on 5 GHz. Nothing to do with DNS Change logs, but less confusion in the world!
Hope these answers help you. P.S. I didn’t see your previous reply so you’ve actually answered one of the questions yourself.
No alert for “DNS server settings changed” when change access points (AP) @Ken_GlassWire has probably pinpointed the most obvious reason why there is no alert for change of DNS server because there is no change when both APs use the same DNS server IP address.
You can tell if GlassWire has registered the change of AP by checking the Network view.
No alert when change WiFi band
Multi-band WiFi can be configured in several ways. Some configurations will produce alerts in GlassWire but the most common configurations will not because there is no change to the DNS address and even the IP address.
GlassWire is looking at the logical details which does not include the wireless band. In your case, the wireless bands correspond to separate devices with different MAC addresses so GlassWire shows this in the Network view. But there is no alert to show a changed MAC address unless the IP address also changes.
It would be good if GlassWire did show changes to the type of Internet connection, e.g. cabled versus wireless, 2.4GHz versus 5GHz wireless. That would avoid some of the absurdities like being told a remote host is not connected when it is. In the screenshot, GlassWire tells me that the same host has connected twice then it has disconnected. I had actually connected the remote computer through Ethernet and WiFi at the same time. The network adapters had different IP addresses (Ethernet 192.168.1.63 and WiFi 192.168.1.73) but GlassWire doesn’t pick that up:
Alert for “DNS server settings changed” shows IPv6 address when only using IPv4
Why do you get an alert showing the default IPv6 local-host address which is prefixed with fe80::? Technically we should say fe80::/64. The address prefix you see, fec0::, is an old standard.
My understanding is that the assigning of the default local-host results from the auto-configuration capability of IPv6. It assigns a default IPv6 address in the absence of a DHCP server. GlassWire picks this up before you get an authorized connection to the new AP and are assigned an IP address by the DHCP server for that AP. The correct IPv4 address is then assigned
FYI, fec0:: is the deprecated and therefore superseded local-host address equivalent to fe80::. The old address usually means that you are using an old version of Windows, probably Windows XP because I think the behavior changed with Vista. An IPv6 local-host is assigned to ensure that when only IPv4 is being configured manually then IPv6 DNS queries are not generated. It used to be the case, and probably still is, that if both the IPv4 and IPv6 DNS addresses are local-host then only an IPv4 DNS query (record A) is generated and no IPv6 DNS query (record AAAA).
Thank you for another view of this! There are still some things I don’t understand…
I’m only using the free version, so my Network view is blank. But under Usage -> Traffic I can separate out DNS activity, and it only shows the Wi-Fi AP’s address. When Windows believes that is the DNS server address, I think that’s all GlassWire knows. When I switch between two different APs with different IP addresses, I get the GW notification, even though they both point to OpenDNS externally.
It is when I switch to an AP that truly does point to a different external DNS source that I don’t get notified!
My reports and screenshots are all from a new Surface Book with the latest Win 10. No idea why they would show an obsolete form, but lots of things are odd about this system. I agree with you that Windows jumps to the default v6 address for the moment between actual v4 connections. And GW nicely reports it. I can’t imagine why it misses my actual v6 connections…
I just went back to that v6 visit day in Usage -> Traffic, and can’t find any hint of a v6 address. Everything is saved as a text URL, and (at least now, while I’m limited to only a v4 connection) is resolved to a v4 address. I didn’t actually verify I was connected via v6 that day, but last I checked it was working. (The v6 AP logs accesses according to the client’s v4 IP, so it is no help.) Next visit I’ll do more checking, inside GlassWire and out.
Thanks for the questions. You’ve made me look at what happens in more detail:
Actually I do get an alert when the APs use the same IPv4 address and the same DNS server addresses. I’m alerted because of the automatic default IPv6 configuration. This only happens the first time that adapter is used after my system starts. Later connections to the same AP give me no alerts. The same applies to cabled/Ethernet connections - I get an alert the first time I use that network adapter.
That appears to be a bug, @Ken_GlassWire. I haven’t had that problem but I will try to replicate it,
IPv6 local-host addresses
I learn something new everyday: the old prefix fec0:: still exists on Windows 10.
Windows 10 network connections (Ethernet and WiFi) correctly use fe80:: It is only the default DNS servers that use the old addresses prefixed with fec0::. This is not really a problem because, even if it was changed to fe80::, GlassWire would still report the default configuration. Also, this is not a security concern where someone could create a fake DNS server with that address on the Internet because, in this situation, only IPv4 DNS queries get out of the local network.