Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g31M5Cj01026 for netdev-outgoing; Mon, 1 Apr 2002 14:05:12 -0800 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g31M52o00986 for ; Mon, 1 Apr 2002 14:05:03 -0800 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07306 for ; Mon, 1 Apr 2002 12:35:58 -0800 (PST) mail_from (david-b@pacbell.net) Received: from krypton ([206.170.6.194]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GTW00NG7P4Q15@mta6.snfc21.pbi.net> for netdev@oss.sgi.com; Mon, 01 Apr 2002 12:34:03 -0800 (PST) Date: Mon, 01 Apr 2002 12:31:43 -0800 From: David Brownell Subject: Re: Patch: Device operative state notification against 2.5.7 To: jamal , Stefan Rompf Cc: netdev@oss.sgi.com Message-id: <080d01c1d9bc$3d4510a0$6800000a@brownell.org> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-netdev@oss.sgi.com Precedence: bulk Two comments on this stuff: (A) I skimmed the 3.1.13 descriptions in RFC 2863. If RUNNING is to correspond to ifAdminStatus, and NO_CARRIER is inverted up/down ifOperStatus, this starts to make sense. For example, it defines the set/set state in Jamal's table as a fault condition. That doesn't quite seem like a complete match though, and not only because one can't map N-ary ifOperStatus (up, down, unknown, testing, dormant, notPresent, and maybe more) to single bits like NO_CARRIER. (B) In Jamal's table I'm thinking about how IP-over-USB stacks would work. Those tend to be point-to-point links with Ethernet framing (easier to bridge :). The devices themselves are all hotplugged, so their interface names won't exist unless there's hardware (maybe it's in the process of being unplugged). But that means there are three meaningful modes: - Only "my" end connected ... nobody on the other end (treated as NO_CARRIER) so IFF_RUNNING can't _ever_ usefully be set - Both ends connected (!NO_CARRIER) so IFF_RUNNING could be set or not. - "Indeterminate" ... some cables might not be able to report whether someone's on the other end. Driver would necessarily treat as if both ends were always connected. So eventually some linkwatch patch could be solving a problem there: no network hotplug events appear for "carrier on" and "carrier off", which are the only events that really matter here (not "register device" and "unregister device") for ifup/ifdown/... calls. - Dave > NO_CARRIER | IFF_RUNNING | meaning > -----------|-------------|------------------------------------ > !set | !set | There is carrier, but no cable > | | no sense for ethernet; but may be useful > | | for PPP (for example line protocol is not up) > -----------|-------------|---------------------------------------- > !set | set | operational up > | | > | | > -----------|-------------|-------------------------------------- > set | !set | operational down > | | > | | > -----------|-------------|-------------------------------------- > set | set | carrier off, cable on; not sure what this > | | means (may make sense for host scope) > | | > -----------|-------------|--------------------------------------