Date: Wed, 22 Oct 2003 13:33:54 -0000 From: Robert Watson <rwatson@freebsd.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: current@freebsd.org Subject: Re: ethercons: ethernet console driver for 5-current Message-ID: <Pine.NEB.3.96L.1031022092828.36090G-100000@fledge.watson.org> In-Reply-To: <3F963221.F3CB296E@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1031022092828.36090G-100000>