How should I interpret the various values of NLM_CONNECTIVITY?
The NLM_ flags enumeration describes what types of network connectivity are available, as far as the networking infrastructure can tell.
Mind you, network connectivity is a hazy concept, because whether a particular endpoint can be reached is dependent not only on the configuration of the local system, but also on the configuration of every machine between you and the endpoint, and those configurations can change at any time. A hunter accidentally damages a power line and suddenly you lose connection to a server. The system won’t know about this until you try to contact that server.
Even for the state of the local system, it takes time for the system to re-evaluate the network connectivity after a change in configuration (such as an unplugged network cable), so you have to accept that the values you receive are based on the most recent information available, but that information may be in flux. And of course there are the shenanigans noted above.
The networking folks gave me this breakdown of what the flags mean and how apps should deal with them.
| Flag | Meaning | Recommendation |
|---|---|---|
DISCONNECTED |
No network interface detects any network. | Treat as offline. |
NOTRAFFIC |
An interface is connected, but it cannot send or receive network traffic. | |
SUBNET |
An interface has been configured to send traffic, but the system cannot confirm Internet connectivity. | Make one attempt to contact service. |
LOCALNETWORK |
||
INTERNET |
The system has confirmed access to Microsoft Internet sites. |
Treat as fully online. |
In the case of SUBNET or LOCALNETWORK, you can make one attempt to contact your Internet service even though Windows doesn’t think it’s going to work. This deals with the case where people employ shenanigans to prevent Windows from detecting Internet connectivity, such as blocking access to the msftconnecttest.com site, or to all Microsoft-owned IP addresses.
The IsConnected property considers your network to be connected if it is connected to a LOCALNETWORK or INTERNET. The IsConnectedÂToÂInternet property requires INTERNET.
If the system is trapped behind a captive portal, it will report itself as LOCALNETWORK. To identify the captive portal case specifically, call INetworkÂListÂManager:: and use the IEnumÂNetworks to enumerate all the INetwork objects. Query each INetwork for IPropertyÂBag and check the NA_ and NA_ properties. If either one has the NLM_ flag set, then you are trapped in a captive portal.
Another way to check whether you’re stuck in a captive portal is to call ConnectionÂProfile.GetÂNetworkÂConnectivityÂLevel and check for ConstrainedÂInternetÂAccess, which is the name NetworkÂConnectivityÂLevel gives to being stuck in a captive portal.
(I’m sorry it’s so complicated, but networking is complicated.)
Light
Dark
5 comments
I would imagine if you’re trapped in a captive portal but one that does not trap Microsoft servers that makes things extra fun since the captive portal won’t be detected but connections to any non-MS server will fail.
I’ve seen this happen on some public wifi on Android where Google IPs are unblocked for some reason but everything else goes to the captive portal (I want to say it was McDonald’s but I’m not sure). I can only assume they are trying to force you to use a web browser to navigate to the captive portal so they can dump you on their website after you sign in (Android’s captive portal interface closes itself once it detects the portal is no longer captive), but in practice it just breaks all your non-web browser apps that need server connectivity to work. But more likely they just set up their captive portal wrong somehow.
I would think a more reliable approach would be to try to randomly generate a domain name, try to resolve it, and if it actually resolves, assume you’re in a captive portal. But there must be some reason this is not done (maybe millions of devices polluting DNS server caches with garbage?). Maybe having deterministic randomness so everyone uses the same fake domain and it rotates every day? (I suppose hackers could predict domains, register them, and try to exploit devices which attempt to connect looking for a captive portal.)
One captive portal vendor I’ve seen offers a mode where you can download “security updates” without signing in, which claims to unblock IPs needed to let connected devices download OS and application updates from device vendors. I wouldn’t be surprised if enabling that caused portal detection to fail because it lets you through to the vendor’s IPs (Google, Apple, Microsoft etc) but not to the wider Internet.
> I would think a more reliable approach would be to try to randomly generate a domain name, try to resolve it, and if it actually resolves, assume you’re in a captive portal.
Oh oops this is actually done in Chrome, though not for detecting captive portals.
Go search “chrome dns hijacking detection” for more info.
I just seem to get 0x40 from both NA_InternetÂConnectivityÂV4 and NA_InternetÂConnectivityÂV6 but I suppose I’m doing something wrong.
This has been a huge nightmare at work. I hate apps that actually look at that value. Sometimes at work my PC reports as offline (or maybe subnet local) even though it is perfectly connected.
Most apps ignore the flag and simply work, but Office flatly refuses to function.