From owner-freebsd-current@FreeBSD.ORG Wed Oct 22 06:33:54 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A81216A4B3 for ; Wed, 22 Oct 2003 06:33:54 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9B8743FBF for ; Wed, 22 Oct 2003 06:33:52 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id h9MDX0Mg041705; Wed, 22 Oct 2003 09:33:00 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h9MDWxEw041702; Wed, 22 Oct 2003 09:33:00 -0400 (EDT) (envelope-from robert@fledge.watson.org) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert In-Reply-To: <3F963221.F3CB296E@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Peter Jeremy cc: current@freebsd.org Subject: Re: ethercons: ethernet console driver for 5-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 22 Oct 2003 13:33:54 -0000 X-Original-Date: Wed, 22 Oct 2003 09:32:59 -0400 (EDT) X-List-Received-Date: Wed, 22 Oct 2003 13:33:54 -0000 On Wed, 22 Oct 2003, Terry Lambert wrote: > Peter Jeremy wrote: > > >As with the Linux driver, communication happens at the ethernet link > > >layer, using protocol number 0x0666 (entertaining choice). > > > > If Linux is using 0x0666, we should probably pick a different number > > since we're not wire compatible. Though coming up with a common > > protocol would be even better. > > 0x666 hex is 1638 decimal, and it's taken: > > cnip 1638/tcp CableNet Info Protocol > cnip 1638/udp CableNet Info Protocol > > Basically, this is just an experimental protocol that's being played > with here, and if it ever becomes real, then it will need an IANA > protocol number assignment before it's widely deployed. Actually, we're talking link-layer 802.1. The reason for this is that I wanted to be able to use the console before IP-layer configuration, and to be able to recover from IP-layer misconfiguration or other problems. I'm not sure of the allocation process for a link layer protocol number, but I will investigate. One of the biggest advantages to selecting an existing protocol to implement (MOPRC, et al) would be avoiding this whole issue. It's worth noting life would be a lot easier in the world of IPv6: you can establish a link layer address usable by applications and services without configuration (automated or otherwise). This would be particularly nice from a client perspective: right now, to interact with a link layer service requires BPF privileges or a special kernel driver (not written). With IPv6, it would be pretty straight forward to do a simple IPv6/UDP encapsulation that would work from the moment the interface was raised. I did think about doing a simple UDP/IPv4 encapsulation for ethercons, but that requires a selection of IP addresses. Perhaps output to a multicast address, and sourced from a reserved address of some sort (or 0.0.0.0), but that would make input difficult. Alternative, sourced and addressed to specific multicast addresses, with additional filtering for the MAC address at the application layer. All of these answers have significant problems, so in the current pass, it's literally "Console over ethernet". Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories