Re: ethercons: ethernet console driver for 5-current
Robert Watson wrote: 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. Robert, I just tried this out (version 0.4) and I like it!! Thanks for the great work. Couple of things I noticed, (sorry if you are aware of them), When logged on via miniterm the 'w' command doesn't show the ethercons user. 'Who' does. The output from top is a bit jumbled. I would definitely like to see this functionality added to the base system, once it is ready. Cheers, Cameron PS I tried logging into the same machine twice and the two miniterm's mirror each other! Not sure if that is intended but it is fun :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ethercons: ethernet console driver for 5-current
Terry Lambert writes: 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: cnip1638/tcp CableNet Info Protocol cnip1638/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. Sure you're not mistaking tcp port numbers for ip protocol numbers now? ;) - arnvid - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ethercons: ethernet console driver for 5-current
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: cnip1638/tcp CableNet Info Protocol cnip1638/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. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ethercons: ethernet console driver for 5-current
On Wed, Oct 22, 2003 at 12:30:41AM -0700, 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: cnip1638/tcp CableNet Info Protocol cnip1638/udp CableNet Info Protocol That would be relevant if this protocol used TCP or UDP. My understanding is that it doesn't, in which case those port assignments are quite irrelevant. Looking at the protocol types listed in /usr/include/net/ethernet.h seems more relevant, unless I have misunderstood something. 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. Are you sure that IANA would be the right organisation, since AIUI this isn't a protocol running on top of IP ? -- Terry -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ethercons: ethernet console driver for 5-current
Robert Watson wrote: On Mon, 20 Oct 2003, Steve Kargl wrote: This looks very interesting! Can we run ddb over the ethercon to debug a wedged machine? [ ... ] To support ethernet debugging, the debugger would need to be able to drive polling of the network interface in an interrupt-thread-free environment, and reproduce more of the lower level network code (i.e., not use mbufs, etc). This is feasible to do, but would probably require adding new interfaces to the ethernet driver, and supporting only ethernet cards that had these additional debugging interfaces. Compared to serial console, you'd also have a lot more situations where the driver/hardware state would be sufficiently inconsistent as to make debugging network-related crashes difficult. On the other hand, Darwin runs quite well with a network debugger; I believe they have a fairly complex UDP/IP implementation in the network debugger, although I haven't inspected it. Apple has the advantage, though, of providing very few ethernet drivers. It's pretty nifty. It's very infrequent that a hang results in something that can't be debugged remotely. The only cases are when an IP address and default route are unknown to the machine at the time of the crash. This can be overridden by providing Open Firmware values, up front, to avoid the need to wait until DHCP is up enough to get the IP (the DHCP implementation is very low level, and happens very early on). Assuming the bug reproduces. You're right about the card support: it's a polled mode driver; on the other hand, it's not really that difficult, even though many ethernet drivers are loaded into the kernel as kext's (Kernel Extensions); FreeBSD boot code can do similar magic up front, in loading drivers as kernel modules. So this actually should not be very hard to put into any/all drivers. It could go in slowly, like multicast, soft interrupt coelescing, or DEVICE_POLLING did, so it's not that big an issue (IMO): at least it's not all or nothing. So I'm happy to look at it, but the level of time investment to get to network debugging from the current (and pretty simple) ethercons device will be fairly high. I know Jonathan Lemon was looking at network console and debugging code previously, but I don't have copies of his patches. If I had to guess, I'd assume he had modified the if_fxp driver, and perhaps others, to provide an appropriate polled interface for use with a debugger, but I don't know for sure. If someone has copies of these patches, I'd be happy to take a look at them. The Darwin code is available, and isn't much changed in that area from Jaguar to Panther, so the sources should still be good (FWIW), if you wanted to look there. If anything gets done, I'd dearly love it to get done so that there was binary compatability enough to be able to cross-debug systems, but of course, that would be up to whoever had the time to invest in doing the work. A neat feature of Panther is the ability to actually do system dumps over the wire, if you enable them (and set the magic values). The graduate student who did the original network kernel debugging code in Darwin did that work over the past summer (I did the code for integrating the sysctl's for him). This might be more valuable to FreeBSD than actually running a source debugger (or not), but it's a lot of fun to play with (it uses a dumping protocol based on a modified TFTP). It would at least be useful in shops with 10 or more BSD working machines and one monitoring box, which have the occasional crash. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ethercons: ethernet console driver for 5-current
FYI, for those who expressed interest, the URL has changed slightly, and I've posted some minor bugfixes and updates: http://www.watson.org/~robert/freebsd/ethercons/ I'm also investigating the MOPRC protocol, and alternative ethernet address choices. I did take a look at the Panasas ipgdb patches for FreeBSD, but it looks like they wouldn't apply well in 5.x without substantial modification (and a bit of evolution of our MP-handling in device drivers). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ethercons: ethernet console driver for 5-current
On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote: After reading a FREENIX paper this summer on a Linux ethernet console driver, I took a pass at implementing ethernet console support for FreeBSD. A very worthy cause. I'm sure this has come up before but I think you're the first person to produce actual code. Something that you don't seem to address is security - which surprised me. This driver is similar to the Linux driver, although not binary-compatible on the wire, ... 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. 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. MOP (as you point out later) or LAT have the advantage of being more standard, but I'm not sure how well documented they are. A series of tunables and sysctls is available to tune the behavior of ethercons: kern.ethercons.ifnet_raise kern.ethercons.interface_preference kern.ethercons.target Is there any way to specify ifconfig options? media and mediaopts in particular may need to be specified to get the interface to talk to the associated switch. I presume kern.ethercons.target only specifies the MAC address inserted into transmitted packets. Is there any way to restrict the src address(es) of received packets? Does ethercons have any concept of a current session or will it accept incoming packets from anywhere at any time? The latter case would seem undesirable as (IMHO) it makes it too easy to accidently send a command to the wrong system Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ethercons: ethernet console driver for 5-current
Date: Wed, 22 Oct 2003 06:26:18 +1000 From: Peter Jeremy [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] MOP (as you point out later) or LAT have the advantage of being more standard, but I'm not sure how well documented they are. MOP is well documented. It is actually two protocols, one for download (MOP/DL similar to bootp) and one for remote console (MOP/RC). Both are very well and openly documented, but I left all of my documentation at a former job thinking that I was unlikely to ever care about MOP again. But I'm sure some of my old DECnet buddies still have it. (Note that while MOP was included under the DECnet umberella, it is really totally separate from anything else in DECnet and I think pre-existed DECnet Phase II. LAT was officially a proprietary protocol and, while quite efficient, makes several assumptions about network characteristics that make it poorly suited to general use. (I assume HP now owns LAT.) I'd vote for MOP/RC as a simple protocol that is designed for exactly this purpose. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ethercons: ethernet console driver for 5-current
On Wed, 22 Oct 2003, Peter Jeremy wrote: On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote: After reading a FREENIX paper this summer on a Linux ethernet console driver, I took a pass at implementing ethernet console support for FreeBSD. A very worthy cause. I'm sure this has come up before but I think you're the first person to produce actual code. Something that you don't seem to address is security - which surprised me. Well, in a sense I did: the environment I use the ethernet console in is one of trust of the link layer. I use DHCP, PXE, and NFS roots on the boxes in question. That said, I should have more carefully documented the security assumptions: that there will be no malicious attackers on the wire, and because it's a link layer protocol, there will be no routing of the packets in question from untrusted segments. I did look at introducing cryptographic protections, but there are a number of problems with this: (1) I wanted to minimize the amount of transient protocol state. The current implementation does not make any reliable transmission guarantees. In order to prevent replay attacks, we would need to rely on reliable timestamps or sequence numbers. In order to establish sequence number legitimacy, we'd need to have a protocol component that establishes freshness. (2) It introduces the issue of key management. In my environment, since the system configuration is shipped in the clear anyway, the keying material would also get transfered in the clear, which would make the whole arrangement somewhat moot. The minimalist solution would introduce just keyed integrity, perhaps using HMAC-MD5 and a shared secret. The problem does come back to sequencing: if you assume the LAN is subject to replay and monitoring, timestamps aren't sufficient, you actually need sequencing and freshness. This means doing a Needham-Schroeder shared key exchange or a related notion to get a session key. This requires the client and server to detect and handle reboots, for example. I am willing to do the implementation, but without a wire protocol worth committing to yet, I was unwilling to invest the time. This driver is similar to the Linux driver, although not binary-compatible on the wire, ... 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. The problem with the Linux protocol was that it had no concept of direction. I'm still hopeful I'll find a better wire protocol to model the implementation on. 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. MOP (as you point out later) or LAT have the advantage of being more standard, but I'm not sure how well documented they are. I have found some documentation of MOP and LAT, although it's not clear to me there's enough information to do an independent implementation without referencing an existing one. There is a Linux implementation, so I'll take a look at that. One of my concerns here is that it could be these protocols require a fairly deep DECnet stack, and I'm not all that interested in building big protocol stacks. However, until I'm done with the reading, I can't commit myself either way :-). A series of tunables and sysctls is available to tune the behavior of ethercons: kern.ethercons.ifnet_raise kern.ethercons.interface_preference kern.ethercons.target Is there any way to specify ifconfig options? media and mediaopts in particular may need to be specified to get the interface to talk to the associated switch. Currently, no. If we do want to add this sort of infrastructure, we might want to provide common infrastructure for both the diskless booting environment, which also attempts to raise the interface before getting to the userland configuration. I presume kern.ethercons.target only specifies the MAC address inserted into transmitted packets. Is there any way to restrict the src address(es) of received packets? Does ethercons have any concept of a current session or will it accept incoming packets from anywhere at any time? The latter case would seem undesirable as (IMHO) it makes it too easy to accidently send a command to the wrong system Right now, ethercons defaults to a broadcast for outgoing, and accepts any locally destined packet on the inbound. There is no notion of session. This is both an upside and a downside: I've actually taken advantage of this behavior to monitor using a common monitoring host, and then used an interactive session simultaenously from another host. However, my hosts all have fairly different
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).
minitermA minimalist interactive terminal program to be pointed
at a specific ethernet interface and hardware address.
sendSend 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).
tailFollow 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
Re: ethercons: ethernet console driver for 5-current
On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote: 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. Robert, This looks very interesting! Can we run ddb over the ethercon to debug a wedged machine? -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ethercons: ethernet console driver for 5-current
On Mon, Oct 20, 2003 at 10:03:52AM -0700, Steve Kargl wrote: On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote: 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. Robert, This looks very interesting! Can we run ddb over the ethercon to debug a wedged machine? No..that was addressd in Robert's mail. Kris pgp0.pgp Description: PGP signature
Re: ethercons: ethernet console driver for 5-current
On Mon, 20 Oct 2003, Steve Kargl wrote: On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote: 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 looks very interesting! Can we run ddb over the ethercon to debug a wedged machine? Not currently. In the current implementation, the ethernet console picks up its input, and generates output, using the ethernet layer of the network stack. Since the debugger suspends scheduling, this means interrupt threads, netisrs, etc, aren't running, so for now, ethercons is disabled when in the debugger (db_active != 0). This permits other console devices, such as serial console, to be used for the debugger, however, at the same time. To support ethernet debugging, the debugger would need to be able to drive polling of the network interface in an interrupt-thread-free environment, and reproduce more of the lower level network code (i.e., not use mbufs, etc). This is feasible to do, but would probably require adding new interfaces to the ethernet driver, and supporting only ethernet cards that had these additional debugging interfaces. Compared to serial console, you'd also have a lot more situations where the driver/hardware state would be sufficiently inconsistent as to make debugging network-related crashes difficult. On the other hand, Darwin runs quite well with a network debugger; I believe they have a fairly complex UDP/IP implementation in the network debugger, although I haven't inspected it. Apple has the advantage, though, of providing very few ethernet drivers. So I'm happy to look at it, but the level of time investment to get to network debugging from the current (and pretty simple) ethercons device will be fairly high. I know Jonathan Lemon was looking at network console and debugging code previously, but I don't have copies of his patches. If I had to guess, I'd assume he had modified the if_fxp driver, and perhaps others, to provide an appropriate polled interface for use with a debugger, but I don't know for sure. If someone has copies of these patches, I'd be happy to take a look at them. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
