Re: Non-MII card link detection

[Paul Ionescu <i_p_a_u_l yahoo com>]

Hi Dan,

On Sun, 06 Feb 2005 00:07:08 -0500, Dan Williams wrote:
> Hi,
> 
> Ok, so I did non-MII link detection as follows:
> 
> Every wired device has a timout function running in the device thread,
> that every 2s checks the numbers in:
> 
> /sys/class/net/<dev>/statistics/rx_packets
> /sys/class/net/<dev>/statistics/collisions
> 
> If the numbers have changed within the last 10s, then the code sets link
> status to TRUE.  If they have not changed, it sets link status to FALSE.
> 
> While this works great at the office, where there are a lot of broadcast
> packets around, this works badly for my home network with 1 server and
> just the laptop, using a Belkin F5D5020 that doesn't support either MII or
> ethtool.  There just isn't enough traffic to update the statistics within
> 10s necessarily.
> 
> So I'm not quite sure what to do... NetworkManager doesn't work really
> well with non-carrier-detecting cards right now.  About the only way we
> can figure out whether or not the card has carrier-detection is to check
> both MII ioctl()s and ethtool ioctl()s.  Even then, we're not necessarily
> sure it doesn't support carrier detection, but it'll have to do.
> 
> If we don't support carrier detection, we have a few options:
> 
> 1) Figure out some improvement or other algorithm for the traffic-checking
> method.  I've looked at broadcast pings, but that wouldn't endear us to
> network administrators at all.  I don't know of another method to force
> devices to talk to us.
> 
> 2) Just disable non-carrier-detect devices from automatic device
> selection. They will still appear in the menu and can be used by the user,
> but they will never be switched to automatically.
> 
> I think at the moment, #2 is probably the best option unless we can come
> up with some better version of #1 for these devices.
> 
> Dan

I have a suggestion, but I don't really know if we can do this in NM, or
if it will work as expected, because I never tried it.

Every X seconds we send a special frame on the wire, the destination
address is our own MAC address of that interface, which means that we are
the end destination of that packet. The ether-type can be 0x9000 which is
 registered for loopback packets.
If the link is up, we should receive this packet because it has our own
mac address as destination, which will be reflected in rx_packets counter.
Now, if we miss Y packet in a row, we could assume the link is off.

X is a user configurable interval, and have a sane
default, like 5 or 10 secs, and Y is the number of replies we are allow to
loose before we declare the link down.

What do you think about it ?
If you like the idea, we should ask the opinion of a linux networking guy,
to see if this is feasible/working or not with linux networking stack.

Best regards,
Paul