Detecting a cable disconnect in user-mode

On a machine running multiple NICs and at least NDIS 6.0, can a C# program detect a disconnect and to which NIC it has happened? The program is using WinSock to communicate with various data gathering devices on locomotives. How does WinSock communicate a disconnect to a program? Does the programmer need to have a thread checking for disconnects every second, or is it some other means? Can the programmer supply a human troubleshooter the card ID to look at to aid in checking the Ethernet cable for damage?

Thanks,
Paul

xxxxx@gmail.com wrote:

On a machine running multiple NICs and at least NDIS 6.0, can a C# program detect a disconnect and to which NIC it has happened? The program is using WinSock to communicate with various data gathering devices on locomotives. How does WinSock communicate a disconnect to a program? Does the programmer need to have a thread checking for disconnects every second, or is it some other means? Can the programmer supply a human troubleshooter the card ID to look at to aid in checking the Ethernet cable for damage?

You can do a lot of experiments with this on your desktop and get a
pretty good picture of what actually happens.

Remember that TCP/IP and friends are designed to be resilient. If you
unplug a cable, the socket connection doesn’t necessarily die
immediately. The stack operates under the assumption that connectivity
will return, and the communication ought to be able to continue without
interruption. If you need to know about a loss of communication
immediately, then it’s really up to you to provide a heartbeat in your
protocols. If you stop getting your heartbeat, then you need to start
diagnosis.

Each IP is typically routed through one NIC, so the mapping isn’t
usually very hard, although that doesn’t give you the physical plug
location.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

You can monitor NIC media connect state with a WMI event subscription.

Dave Cattley

Sent from my Windows Phone


From: xxxxx@gmail.commailto:xxxxx
Sent: ‎5/‎11/‎2015 2:30 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] Detecting a cable disconnect in user-mode

On a machine running multiple NICs and at least NDIS 6.0, can a C# program detect a disconnect and to which NIC it has happened? The program is using WinSock to communicate with various data gathering devices on locomotives. How does WinSock communicate a disconnect to a program? Does the programmer need to have a thread checking for disconnects every second, or is it some other means? Can the programmer supply a human troubleshooter the card ID to look at to aid in checking the Ethernet cable for damage?

Thanks,
Paul


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

Thanks to both of you. The task has been redefined to not worry about this at this point. This was for another programmer and I will forward your responses for future plans.
Paul

Dave Cattley wrote:

You can monitor NIC media connect state with a WMI event subscription.

I figured I would back out of this thread once the net experts chimed
in, but my user-mode network experience leads me to wonder where this
line of thinking is going.

A locally disconnected cable is not the only reason for network
connectivity issues. Indeed, I’m not sure I’d even call it the most
common reason. It’s quite possible for the local network cable to be
electrically connected, but still have packets going nowhere, because of
some interruption or router restart down the line.

If I were writing deadman timer code to detect loss of connectivity with
a set of remote telemetry sources, I’m not sure that a media disconnect
monitor would be in my first line of defense.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> If I were writing deadman timer code to detect loss of connectivity with

a set of remote telemetry sources, I’m not sure that a media disconnect
monitor would be in my first line of defense.

I could not agree more Tim. But the title was “detecting cable disconnect” not “detecting if a network path exists”.

I neglected to ask the OP “Question 0”: What are you trying to accomplish?

So, OP, do you really want to know the cable state or some higher level of ‘connectivity’?

Cheers,
Dave Cattley

> From: paulsan71@

Can the programmer
supply a human troubleshooter the card ID to look at to aid in checking
the Ethernet cable for damage?

And for detecting cable damage - there are ways to check this too.
Some people on this list certainly remember these vintage Intel netcards
from coaxial Ethernet era which had built-in TDR
(time domain reflectometer) function.
Tools exist for vehicle and avionic cabling as well though they are
not necessarily integrated with the adapters.

– pa

On 13-May-2015 01:22, Marion Bond wrote:

Given that he asked about 'data gathering devices on locomotives’ we can
expect a very simple network topology where cable disconnect is probably
the primary reason for a failure of connectivity.

The netcard maybe won’t see cable disconnect at all if it
is connected thru a hub. So, Mr. Roberts is right, as he usually is.
Though a smart range extender or medium converter may propagate
disconnect to the eth. port.


Sent from Bottom Amateur

> The netcard maybe won’t see cable disconnect at all if it

is connected thru a hub.

Ok, so let me just point out that the NIC is *not* disconnected from the cable in this case. So if your point is that the scheme cannot detect a cable disconnect of a cable that is not the one connected to the NIC you are absolutely right.

There are connectivity mapping solutions that can query the connected state of switch ports for reachable devices but I fear we are just expanding the problem domain without the OP actually indicating the relevance. Something we list members are pretty good at :slight_smile:

Cheers,
Dave Cattley