2

I have noticed a distinct difference in Windows (10) between administratively disabling a network interface, and physically unplugging the connection. I am not exactly sure how to describe the difference, but I can illustrate it with two continuous pings:

First, administratively disabling the interface and then enabling it:

>ping -t 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=12ms TTL=112
Reply from 8.8.8.8: bytes=32 time=12ms TTL=112
No resources.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
Reply from 8.8.8.8: bytes=32 time=11ms TTL=112
Reply from 8.8.8.8: bytes=32 time=11ms TTL=112

Physically unplugging the connection and then plugging it back in:

>ping -t 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=12ms TTL=112
Reply from 8.8.8.8: bytes=32 time=12ms TTL=112
Request timed out.
General failure.
General failure.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=11ms TTL=112
Reply from 8.8.8.8: bytes=32 time=11ms TTL=112

My specific question is, can I perform some action in Windows which will have the same effect as physically unplugging the connection (preferably through the command line). Second, I would actually like to know what the difference is here, in terms of the Windows network stack implementation.

In the network engineering world, we have the concept of being physically up but administratively down, which I assume is the same here, but I would like to know how the networking stack inside of Windows propagates that situation up, so that software actually behaves differently, and can actually tell a difference between the two situations described.

lampwins
  • 185
  • 2
  • 7
  • The software behaves differently because routes associated with that interface are deleted when interface goes down, ARP cache entries removed, local IP address is removed and so sockets bound to that address are closed, and so on. – Nikita Kipriyanov Feb 09 '21 at 06:54

1 Answers1

0

The different states of a network adapter + connection are:

  1. The adapter is disabled by the OS. In that state no network functions are ever executed on the adapter. It is as if the adapter is not present in the network, only a device in the system without function.
  2. The adapter is enabled, but the cable is removed. The system (network stack) waits for a cable to be plugged in.
  3. The cable is plugged in. The system tries to enable a physical connection with the other side by detecting speed and duplex settings of the physical connection. (See also this question)
  4. Once this is done, the OS knows a cable is plugged in and starts to assign an address to the network interface (which is bound to that adapter, it could be more than one). This could be done by static assignment or by DHCP (IPv4 and IPv6) or by SLAAC (IPv6) or by APIPA (IPv4). All of those have the intent to give an IP address (and routing information) to the network interface, which is understood by the other participants of the network (specifically that segment), to be able to communicate.
  5. The IP address was assigned. Now the interface is up, connections can be made.

So a logical answer to your specific question is: Yes. But the "physical" answer is: No.

  • Disabling the adapter in the administrative interface (or via command line) is moving the adapter to state 0 (from any other state). Enabling it moves to state 1.

  • Pulling the cable (while the adapter is enabled) moves to state 1 (not 0).

That is the main difference. Both drop all connections and state of the ARP caches etc., so logically it does the same. But physically it does not. I also never found a way to move to state 1 (from "higher" states) by software means (OS command), probably because that is a physical thing not influenced by the OS.

nix
  • 426
  • 4
  • 5