ethercons: ethernet console driver for 5-current

I had a fair amount of time over the last week running in disconnected
operation, and realized I had too many cables under my desk, so I spent a
bit of time exploring the FreeBSD console code.  After reading a FREENIX
paper this summer on a Linux ethernet console driver, I took a pass at
implementing ethernet console support for FreeBSD.  This driver is similar
to the Linux driver, although not binary-compatible on the wire, as this
driver supports both input and output, while the Linux driver supports
only output monitoring (and the protocol can't represent bi-directional
communication well).  There are some potential work-arounds for this,
which I'll explore at some point.  In general, the wire protocol is
probably the weakest part of the endeavor, but I'm having trouble finding
documentation for a decent wire console protocol that doesn't come with an
entire network stack attached.

As with the Linux driver, communication happens at the ethernet link
layer, using protocol number 0x0666 (entertaining choice).  The contents
consist of a little meta-data (not found in Linux), and a nul-terminated
string, although the kernel code currently generates only single
characters due to the nature of the console code.  ethercons implements
both a low level putc() console interface, and a high-level pseudo-tty
appropriate for /dev/console redirection and getty/login.  Unlike the
other low-level console drivers, ethercons does not implement low-level
input checkc/getc, as ethercons is interrupt driven, and that interface is
a polled interface that conflicts with the tty code.  I'm considering
adopting a timeout-driven model as done in ofw_console, but haven't
convinced myself that is entirely desirable.  In addition, the ethercons
device is not available for I/O when in the debugger context, due to its
use of the network stack.  To support this, I recently added a flags field
to the console definition, and a NODEBUGGER flag.

To enable support for ethercons, add "options ETHERCONS" to your kernel
configuration.  A series of tunables and sysctls is available to tune the
behavior of ethercons:

kern.ethercons.ifnet_raise	"ifconfig up" the interface prior to
				reaching init so that ethercons may be
				used in single usermode.  Otherwise,
				ethercons only becomes available when the
				interface is brought up later by
				dhclient/ifconfig/...  Alternatively, for
				network booted environments, the interface
				may already be up.

kern.ethercons.interface_preference	Interface name preference, if any.
					Otherwise, the default is the first
					ethernet interface.  The most
					recently used interface is
					available read-only via
					kern.ethercons.interface.

kern.ethercons.target	Target ethernet address for the console target.
			Otherwise, the default is ff:ff:ff:ff:ff:ff. 

The ethercons client uses bpf; it's a fairly limited tool in its current
form.  It has several modes of operation:

log		Follow the console output of all ethernet consoles,
		logging the output to various log files, named by the
		source ethernet address of the messages (specified by
		interface).

miniterm	A minimalist interactive terminal program to be pointed
		at a specific ethernet interface and hardware address.

send		Send a string to a remote console as input (specified
		by interface, target address).

sendcr		Send a string to the remote console as input, along
		with a carriage return (specified by interface, target
		address).

tail		Follow the console output of a particular ethernet console
		(specified by interface and source address).

tailall		Follow the console output of all ethernet consoles, even
		though the results are potentially messy (specified by
		interface).

It should be possible to create a more complete client for easier
interactive use; alternatively, the firewire console code binds a socket
for use with a telnet client, which could be done for ethercons, which
might be a better approach than writing more interactive code of that
sort. 

You can set up a getty/login session on /dev/ethercons using /etc/ttys:

  ethercons       "/usr/libexec/getty Pc" xterm   on secure

The changes consist of three parts: two new kernel files
(src/sys/dev/{ethercons.c, ethercons.h}), a kernel patch (ethercons.diff),
and a userland tool for monitoring/logging/communicating with the ethernet
console (src/usr.sbin/ethercons/{ethercons.c,ethercons.h}).  Note that to
build the userland ethercons tool, the updated ethernet.h must be in
/usr/include/net due to its reliance on the new constant. 

  http://www.watson.org/~robert/freebsd/ethercons-0.2.tgz

I believe I have merged all the necessary patches to support ethercons
into the base tree, wich the exception of the tweaks to net/ethernet.h to
allocate a new ethernet protocol number.

I have no immediate plans to commit this code, but would appreciate
feedback.  It appears to work fairly well for me, but it highlighted some
limitations to the FreeBSD networking and console code:

(1) Unless you use netgraph, it is "hard" to extended the set of ethernet
    protocol handlers.  Introducing dynamicism in the protocol switches
    will introduce additional locking costs.

(2) Two levels of support are present in the console driver: first,
    low-level console support provides a simple getc/checkc/putc interface
    for kernel output and input.  However, to support user process
    interaction with the console, such as syslogd writing to the console,
    or single-user mode, you need a tty.  The two interfaces are fairly
    incompatible due to the polled vs. interrupt-driven model.  To
    support the polled interface, the console driver needs to own the
    buffer memory.  To support the tty interface, the tty driver needs to
    own the memory.  The open firmware console works around this by
    having timeouts that transfer data from a console-owned buffer to a
    tty-owned buffer at intervals.  The low-level console code races with
    the timeout to "get there first" and extract data for the low-level
    console when it is required.  All in all, this puts console/tty driver
    writers in a sticky situation if the underlying medium doesn't support
    polled access naturally, and behaves in an interrupt-driven fashion.

So, the quick summary: it appears to work, it has limitations, and the
wire protocol sucks.  I'd like to find a better wire protocol (without too
much overhead), and figure out a better answer for low-level console
interactions.  The client is also pretty limited, and could do with some
improvement.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Network Associates Laboratories