Starting from Vista, the PC seemed to have the magically ability to correctly detect network and internet connection information, and whether more information was required to authenticate; usually when connecting via a public wifi hotspot which redirects to an intermediate login page.
This was achieved via a service introduced in Windows Vista called Network Connectivity Status Indicator (NCSI).
NCSI examines network connectivity in a variety of ways to give the most accurate state of connectivity. It does this attempting to connect to a special webpage hosted by Microsoft.
According to a SuperUser Blog post the checks are performed as the following:
There are a few variations of the connection checking process:
- NCSI performs a DNS lookup on
www.msftncsi.com, then requests http://www.msftncsi.com/ncsi.txt. This file is a plain-text file and contains only the text
- NCSI sends a DNS lookup request for
dns.msftncsi.com. This DNS address should resolve to 22.214.171.124. If the address does not match, then it is assumed that the internet connection is not functioning correctly.
The exact sequence of when which test is run is not documented; however, a little bit of digging around with a packet sniffing tool like Wireshark reveals some info. It appears that on any connection, the first thing NCSI does is requests the text file (step 1 above). NCSI expects a 200 OK response header with the proper text returned. If the response is never received, or if there is a redirect, then a DNS request for dns.msftncsi.com is made. If DNS resolves properly but the page is inaccessible, then it is assumed that there is a working internet connection, but an in-browser authentication page is blocking access to the file. This results in the pop-up balloon above. If DNS resolution fails or returns the wrong address, then it is assumed that the internet connection is completely unsuccessful, and the “no internet access” error is shown.
Now we know how Microsoft performs connection checking in Vista & Windows 7, we can port this over to C# for a ‘correct’ and ‘accurate’ method of checking connection which should give the same response.
Most internet connection checkers attempt to download a webpage that they believe should never fail, eg. www.google.com and either respond with a valid connection if they receive a 200 OK response or the page successfully downloads. This has the problem if the DNS redirects the page; in the case of public wifi.
You can download my implementation of the NCSI checks in C# from here