Printable View
Hi,
I want to force an Update of my soft, but some people obliviously stop/disable internet access.
Is there a way to detect internet connection, even if your app has been blocked by an antivirus/firewall ?
So that you can warn the user and say you've blocked internet access to this software?
Thanks
When you try to connect to an invalid site you will get an error in the Winsock1.Error (or whatever name you use to connect) routine.
Try this control http://vb.mvps.org/samples/NetGrab/ it is by Karl Peterson. With this you can point it to any URL of your choice and if you get a result then you are connected to the Internet. You can easily use it for downloading updates to a users PC. The control mentioned is asynchronous meaning it will not stop your program whilst trying to connect to the internet.
There are quite a few API calls for testing connection status but I have found they are never completely accurate. Also search in the codebank for SNTPClient by our own Dilettante. This can be used for updating the time on your PC but also is asynchronous and another good choice for internet testing.
Guys, thanks but the problem here is not detecting for a valid / invalid site to determine the status. I'm already detecting this.
The question is: AntiVirus / Firewall softwares show a popup saying XXX Software is trying to connect to XXX... Allow/Block. Many users see this as a thread and BLOCK access to the software.
Is there a way to detect internet connection, even if your app has been blocked by an antivirus/firewall ?
So that you can warn the user and say you've blocked internet access to this software?
You keep asking if there a way to detect internet connection and of course according to you are already detecting this.
Your program can determine if you made a connection or not but whether it can determine if the other end is being blocked by antivirus/firewall I don't think so.
It isn't entirely clear what you are after. It might not even be practical.
Typically even with notification turned on for Windows Firewall (and 3rd party firewalls that "plug into" the Windows firewall infrastructure properly) attempts to connect outward don't trigger anything. However if they do, this might still help some.
It also doesn't address what antivirus suites might do on top of this, for example even when I disable listening by this demo program in Windows Firewall, AVG Free triggers an alert and requires a separate exception or else it will try to "clean" my program as malware even though blocked already.
See Windows Firewall Tools and Settings for some documentation. There might be more in MSDN but I don't have a link handy.
So this demo tries to open a listening TCP socket, and I have blocked it when the popup from Windows Firewall came up. As far as Winsock is concerned the Bind and Listen have succeeded, but I have checked the Firewall status of the program. Note that it shows as having a rule, and within the rule it has been disabled:
As noted in the program's comments this may have to be done using late binding to get portability. I tested on Vista SP2, other versions of Windows may not have maintained binary compatibility with this because they seem to treat this library's COM interfaces as "for scripting use" and of course nearly all scripting is dumb and can only use late binding.
It should work using late binding on XP SP2 or later, and almost certainly on Windows 7 too. I haven't had to either try this or investigate it for Windows 8 or later and I can't recall whether or not Windows 2000 supports these Firewall libraries (FirewallAPI.dll, hnetcfg.dll, etc.). These objects and interfaces seem to move around from version to version of Windows.
This topic hasn't been discussed or explored by knowledgeable folks in the VB6 community too much. So many of the Big Dogs have left us for greener pastures long before it became much of a thing with Windows XP. The .Net Great Destruction was a major blow to the hopes of so many.
You may have a lot of exploring and cutting and trying ahead of you. Good hunting!
BTW:
The demo above is likely to operate in a confusing manner when run in the IDE.
At least the first run should be done with the compiled EXE, if necessary with the call to CheckFirewall commented out. Otherwise the firewall dialog will be asking about the disposition of the VB6 IDE's network usage, which you might already have granted a carte blanche exception to anyway for testing programs.
Once you do that first run then further testing via IDE runs will probably make a little more sense.
Another note:
It makes little sense to check for a firewall rule until after the program has already tried to listen (or connect). If there is no rule all you know is that there is no rule yet. Listening (in this case) before checking probably makes the most sense then.
And as I said above the firewall is normally set up to permit outgoing connections without prompting. You might need to fiddle with firewall settings if you need to test for outgoing scenarios. I'm not sure that Windows Firewall even has an option for blocking outgoing connections, so that might only apply to 3rd party firewalls installed by the user - assuming anyone does that anymore.
One more thing:
Unless you are only dealing with home and small-office scenarios the resident software firewall may be the least of your worries. Most networks of any real size also involve hardware firewalling within the network, at least at the periphery where they connect to an ISP.
This was one of the main drivers behind the move to so-called web services. Client connections via HTTP/HTTPS using the standard ports are generally far more tolerated by network security folks than most alternatives. The firewall-hostile FTP protocol is probably the worst choice one could make. Standard mode operation requires a listening ad-hoc port, a no-no, and even PASV mode FTP may be blocked by corporate firewalls as a general risk. However you can't even count on web services all the time, since some network security devices examine HTTP/HTTPS traffic as well and reject anything that doesn't look like human-driven browsing and isn't on a list of authorized web services.