All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Cantu <list@tux.cs.ou.edu>
To: linux-kernel@vger.kernel.org
Subject: Re: Question: Etherenet Link Detection
Date: Thu, 27 Sep 2001 09:58:53 -0500	[thread overview]
Message-ID: <3BB33EAD.9030107@tux.ou.edu> (raw)
In-Reply-To: <CIEJKOKMAIAHDBBLFGFFEEOPCGAA.peter@zaphod.nu> <3BB26D72.69E02ED0@candelatech.com>

Ben Greear wrote:

> Peter Sandstrom wrote:
> 
>>I know for sure that the Intel 82559 Fast Ethernet embedded controller
>>has a register where it's possible to read out if the link led is active
>>or not. It seems quite likely that this would be available on other
>>controllers as well.
>>
>>Is there any functionality in the current kernel that enables a userland
>>program to read this? I mostly turn my machines on and and let them do
>>their thing until the hardware fails :)
>>
>>/Peter
>>
> 
> You can get this information out of any NIC that supports
> the mii-diag protocols.  The two I've used are the eepro100
> and tulip drivers...
> 
> You can read Becker's mii-diag source for the gory details!
> 
> Ben
> 
> 

Thaniks, all who replied.

A little clarification on my project:

I'm going to try to build a userland app that manages several different 
network profiles and watches the ethernet port and notifies the user of 
a disconnect. If the user wishes, it will be configured to unload the 
network profile upon disconnect (to avoid long timeouts) and upon 
reconnction, reload that profile. A few simple subnet detection 
algorithms would try to intelligently load the correct profile. This is 
mainly a useful solution for mobile users who have to have different 
set-ups for networking. It looks like the mii-diag from Becker is going 
to work great (thanks, all who pointed me there), and is the last 
component I needed to get started. I may put the project up on 
sourceforge as my coding skills are new and weak. Thanks for the info.

As a side note, any chance such monitoring tools/interfaces might go 
into a later 2.4 or 2.5 kernel and be available in the /proc fs? That 
would be a much more elegant solution, from a user's standpoint. Again, 
thanks, all!

Cheers,
Robert Cantu
robert@tux.ou.edu


      reply	other threads:[~2001-09-27 15:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-26 21:41 Question: Etherenet Link Detection Robert Cantu
2001-09-27 23:36 ` Peter Sandstrom
2001-09-26 23:39   ` Matthew Dharm
2001-09-26 23:49     ` Randy.Dunlap
2001-09-26 23:49       ` Tim Hockin
2001-09-27  0:10         ` Randy.Dunlap
2001-09-27  0:06   ` Ben Greear
2001-09-27 14:58     ` Robert Cantu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BB33EAD.9030107@tux.ou.edu \
    --to=list@tux.cs.ou.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.