NetBSD Problem Report #26939

Received: (qmail 2640 invoked by uid 605); 13 Sep 2004 20:09:28 -0000
Message-Id: <20040913200925.E66D31A91B2@castrovalva.Ivy.NET>
Date: Mon, 13 Sep 2004 16:09:25 -0400 (EDT)
From: carton@Ivy.NET
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: carton@Ivy.NET
To: gnats-bugs@gnats.NetBSD.org
Subject: some network drivers don't generate an RTM_IFINFO route(4) message when link-detect changes
X-Send-Pr-Version: 3.95

>Number:         26939
>Category:       kern
>Synopsis:       some network drivers don't generate an RTM_IFINFO route(4) message when link-detect changes
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 13 20:10:00 +0000 2004
>Closed-Date:    
>Last-Modified:  Mon Sep 13 20:24:01 +0000 2004
>Originator:     Miles Nordin
>Release:        NetBSD 2.0_BETA
>Organization:
Le fascisme est la dictature ouverte de la bourgeoisie.
		-- Georg Dimitrov
>Environment:


System: NetBSD castrovalva 2.0_BETA NetBSD 2.0_BETA (CASTROVALVA-$Revision: 1.7 $) #0: Mon Sep 13 01:45:01 EDT 2004 carton@castrovalva:/scratch/src/sys/arch/alpha/compile/CASTROVALVA alpha
Architecture: alpha
Machine: alpha
>Description:
_______
Problem

There is an interface for userland program to query the link-detect of 
a network interface.  On Ethernet, this is the little green light next 
to the jack.  Routing programs like quagga/zebra can use this information 
to do a better job.  They need to be able to

  (1) poll for the information at startup.
  (2) get asynchronous PF_ROUTE messages when link state changes.

Right now (1) works for more network chip drivers than (2).  I think the 
set of supported cards should be identical for (1) and (2) since it's 
just a logic problem, not support or capability of hardware.

__________
Background

route(4) documents a type of routing message RTM_IFINFO that comes out of 
the PF_ROUTE socket as a struct if_msghdr defined in <net/if.h>

struct if_msghdr ifm;
/* your interface link state is in ifm.ifm_data.ifi_link_state */

______
Detail

Many network drivers will update the link state in this kernel structure, 
but will not call the kernel function rt_ifmsg() to generate a routing 
message.  It's still possible to retrieve the link state of these problem 
drivers using sysctl(), but routing software like quagga needs this 
information to come as routing messages, not poll for it.  Otherwise it 
can't keep its interface lists synchronized with the kernel.

Here is a code fragment to poll for link state, taken from quagga's 
zebra/if_sysctl.c (abbreviated):

-----8<-----
  caddr_t ref, buf, end;
  size_t bufsiz;
  struct if_msghdr *ifm;
  struct interface *ifp;

#define MIBSIZ 6
  int mib[MIBSIZ] =
  { 
    CTL_NET,
    PF_ROUTE,
    0,
    0, /*  AF_INET & AF_INET6 */
    NET_RT_IFLIST,
    0 
  };

  sysctl (mib, MIBSIZ, NULL, &bufsiz, NULL, 0);

  ref = buf = malloc(bufsiz);

  /* Fetch interface informations into allocated buffer. */
  sysctl (mib, MIBSIZ, buf, &bufsiz, NULL, 0);

  /* Parse both interfaces and addresses. */
  for (end = buf + bufsiz; buf < end; buf += ifm->ifm_msglen) 
    {
      ifm = (struct if_msghdr *) buf;
      if (ifm->ifm_type == RTM_IFINFO)
        {
	/* ifm->ifm_data.ifi_link_state is what the PR is about */
        }
    }
-----8<-----

__________
Experience

I find that gem on a sparc64 Netra T1 200 works.  tlp on an alpha DS10 
doesn't generate route messages.  

The tlp in this alpha is a 21143, a 100Mbit/s chip that works without 
an MII.  grepping in sys/dev kernel sources for rt_ifmsg I find one 
call factored out to mii_physubr.c, and another in wi.c.  From this I 
expect all cards with MII and also wi(4) will generate the RTM_IFINFO 
messages, but no other cards.  I've tested only the two interfaces I 
mention above.

>How-To-Repeat:
Here is an example of an interface that properly generates the 
RTM_IFINFO messages when I unplug and replug its Ethernet cable:

$ sudo route monitor
Password:
got message of size 152 on Mon Sep 13 19:32:23 2004
RTM_IFINFO: iface status change: len 152, if# 2, carrier: no carrier, flags:<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
got message of size 152 on Mon Sep 13 19:32:27 2004
RTM_IFINFO: iface status change: len 152, if# 2, carrier: active, flags:<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>

An interface that doesn't generate them will be silent.

>Fix:
>Release-Note:
>Audit-Trail:

From: Martin Husemann <martin@duskware.de>
To: carton@Ivy.NET
Cc: gnats-bugs@gnats.NetBSD.org
Subject: Re: kern/26939: some network drivers don't generate an RTM_IFINFO route(4) message when link-detect changes
Date: Mon, 13 Sep 2004 22:23:23 +0200

 PR kern/26829 describes another instance of this same problem.

 Martin
>Unformatted:

Home	PR Database Search