Rufus not connecting to internet

[ghost]

Checklist

• I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• I performed a search in the issue tracker for similar issues using keywords relevant to my problem, such as the error message I got from the log.
• I clicked the 'Log' button or pressed Ctrl-L in Rufus, and copy/pasted the log into the line that says <FULL LOG> below.
• The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• I ran a bad blocks check, by clicking Show advanced format options then Check device for bad blocks, and confirmed that my USB is not defective.
• I also tried one or more of the following:
  • Using a different USB drive.
  • Plugging the USB into a different port.
  • Running Rufus on a different computer.
• If using an image, I clicked on the (✓) button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.

Issue description

Rufus says cannot connect to internet even though internet is working on PC.

Log

Rufus x86 v3.16.1836
Windows version: Windows 10 Pro, 64-bit (Build 16299.15)
Syslinux versions: 4.07/2013-07-25, 6.04/pre1
Grub versions: 0.4.6a, 2.06
System locale ID: 0x0809 (en-GB)
Will use default UI locale 0x0809
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
0 devices found
Could not open Internet session: Internet is disconnected.
Checking for Rufus updates...
Updates: Unable to connect to the internet
Checking for Rufus updates...
Updates: Unable to connect to the internet

[pbatard]

Either you are using a proxy, or you have multiple network interfaces and only one is connected to the internet (though IIRC Windows always defaults to using the interface that has connectivity) or something on your system is preventing the default internet library from working.

Be very mindful that it's not because a browser like Chrome or Firefox is working that the native Windows APIs can connect to the internet. Obviously, because it is not a browser and it expects the default library to work, Rufus uses the Windows APIs to connect to the internet, and I'm afraid it's going to be up to you to find out why it doesn't work, because I have no insight on what's so special about your system, compared to other Windows 10 platforms, that it is preventing it to work.

You may want to see if Internet Explorer (not Edge) manages to connect to the Internet.

At any rate, if you get Could not open Internet session: Internet is disconnected, your issue is either that INetworkListManager::GetConnectivity() is returning NLM_CONNECTIVITY_DISCONNECTED or that we can't create a NetworkListManager instance to check the network connection. But that's about as much help as I can provide with that issue, because this is clearly an environmental issue with your system, and it's not possible for me to "guess" why your Windows 10 system doesn't work when every other Windows 10 system appears to have no such issue.

[Redundanz]

hi pete!

for completeness sake i wanted to add that i also experienced this behaviour with the latest 3.17p.exe and since it worked with 3.12p.exe for me all the time - i tested around a little and found out that the "issue" was introduced in v3.14 which could correlate to

"Improve network connectivity detection"

changelog entry.

so this might have introduced an additional dependency that is not a necessary condition for identifying a working internet connection? or some kind of sanity check that assumes network is down via some kind of circumstantial criterion?
for full clarification i am using a fully static IP configuration on windows with DHCP and DNS service disabled (which are all taken care of by static entries in the ipv4 protocol options...). which doesn't mean it has to do with the latter settings of course...
rufus (3.14+) has been the first 3rd application on my end that would identify the internet as being down while it isn't.

regardless if you see reason to change the behaviour maybe this information is helpful to anybody encountering the problem.

cheers,
red

[pbatard]

Then this was most likely introduced in b249290 where we switched to the more modern INetworkListManager::GetConnectivity() call to detect network connectivity.

The problem I have however is that when using the old method, ARM64 platforms would not detect network connectivity when a standard DHCP connection was active (#1691), and Microsoft themselves recommend not to use the InternetGetConnectedState() method we used prior to Rufus 3.14.

From what I can tell, your configuration is such that INetworkListManager::GetConnectivity() reports NLM_CONNECTIVITY_DISCONNECTED, since that's the only value we really check in the code.

Either that, or your system configuration is preventing us from accessing INetworkListManager altogether, in which case the default is also to consider that there is no connectivity. Can you tell if the system you are running Rufus on has been restricted in any way?

If I can replicate the issue by setting a static IP, I'll see if I can work something out (but I have to state that I am reluctant to add a check for both INetworkListManager::GetConnectivity() and InternetGetConnectedState() if that's what it takes to detect a specific case, as if INetworkListManager::GetConnectivity() doesn't report the expected result, then it's really a Windows issue).

[Redundanz]

thanks for getting back so quickly!

so i'll be brief about it :) . the network list service is not running because the network location awareness service is not running because the DHCP client service is not running. what a nice dependency chain we have here.
and it seems that somewhere along the lines of windows 10 build version progression these dependencies have been (for no sane reason) instated by micros..... especially the dependency of the network location awareness service to have DHCP running. which was never a requirement in the majority of windows 10 builds, neither was it ever a requirement in windows 7, windows 8...

to me it is perfectly obvious that MS is doing changes without thinking of consequences and get away with it, because it is what it is... so i am not directing any anger towards you here, or expect you to workaround f*ed up MS implementation decisions.

but that is the reason it happens. and it should be perfectly fine to disable a DHCP client service if it is not needed without breaking the whole network management api via strangely enforced service dependencies.

it's just sad that it annoys users the same as it rightly annoys 3rd party devs. and the only things to do would be either

user perspective:
1.) use old version
2.) dont ever personalize/individualize your windows install

dev perspective:
1.) waste time by writing a robust network check for all eventualities - which ms obviously failed to do by making it dependent on the DHCP service through creating a dependency chain , probably out of completely accidental secondary reasons.
2.) use different in-built methods of windows to check for connection - deprecated, not "future proof"/"best practice"

ms perspective:
... sit on their lousy... and work on the next hurdles for users

well, at least it has become a less obscure issue now :P

cheers

ps: i myself wouldn't know what's the best to do here. wait (until eternity) until ms properly differentiates their service landscape - yeah right.
or - as a dev - not rely on too deeply integrated / abstract api calls for such simple checks anymore (when it comes to ms products). i really don't know.

[pbatard]

Just a quick note to indicate that I finally got around testing Rufus on a vanilla version of Windows 10 with a static IP, but I wasn't able to replicate this issue (which I more or less expected, as I expect a lot of users out there to run Rufus on machines with static IPs, and if this was a general issue with static IP, I'd have heard about it by now).

I must therefore conclude that besides the static IP assignment, there must have been some other configuration changes on your system that are causing this issue, and that not that many people are likely to run into. Therefore, unless I eventually get some details on what exactly these system configuration changes are, I'm afraid that I am not planning to look into this issue further, since I won't be able to understand where exactly the problem lies, and whether a potential fix would work or not.

[Redundanz]

as per my previous post: the precondition for this to happen is a DHCP disabled environment (DHCP Client service in windows disabled and stopped, requires reboot) which of course necessitates a manual entry of a static IP .
not the assigning of a static IP itself alone causes it as you saw from testing. that is merely a consequence of not using DHCP within your network. which is absolutely valid practice and should not indicate a "not connected to the internet".

[pbatard]

@Redundanz, thanks, I had forgotten that you also had DHCP disabled.
I was able to replicate your issue and it looks like the INetworkListManager methods fail with HRESULT_FROM_WIN32(ERROR_SERVICE_DEPENDENCY_FAIL) when DHCP and corollary services are disabled, which of course is all kind of stupid on Microsoft's part. I guess that's probably also why you get Access Denied when you try to stop the DHCP service manually on a standard installation of Windows, as Microsoft really doesn't want you to stop these underlying networking dependencies.

I'm going to add a fallback to using InternetGetConnectedState() when ERROR_SERVICE_DEPENDENCY_FAIL is returned, which, from my testing, should do the job. I will therefore reopen this issue and close it with the relevant patch.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.