Re: ethercons: ethernet console driver for 5-current

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_at_fledge.watson.org      Network Associates Laboratories