Network cable disconnect

[gregory.menke at gsfc.nasa.gov]

Camilo Alejandro Arboleda writes:
 > On 6/20/07, Eric Norum <norume at aps.anl.gov> wrote:
 > >
 > > The original intent of the Internet was to be able to get data
 > > through even in the event of a nuclear attack.  Allowing a minute for
 > > a damaged connection to be cleared or routed around is quite
 > > reasonable under those circumstances.   What is your need to detect a
 > > disconnected cable that quickly?
 > 
 > 
 > Because the packets send before the drivers detect disconnection, appear to
 > be properly transmitted at application layer, but they weren't.
 > 
 > I'm going to enable network driver debug, and see what happens.
 > 


The IP stack is entirely free to accept your packets and discard them
and not tell you in any particular timeframe.  

Relying on an application layer handshake is not a good way to test
specific physical connectivity because there is always the possibility
of multiple interfaces and redundancy in the network which can obscure
the state of a particular link.

You'll have to be specific about what you want.  If you want to ensure
app-to-app connectivity (this is probably of most use), then the
application layer handshake makes sense.  "make the green thing light up
when we're in contact" sort of idea.

If you specifically want to test the link-state of an interface (which
is not necessarily the same as compatible IP stack configurations), then
you'll have to interrogate the PHY chip on the device.  To do that,
probably your best bet would be to modify the driver to pull out PHY
state at suitable points and store it (or put it in a message queue).

Greg