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.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

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

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

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

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. 


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

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]      Network Associates Laboratories

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to