Something else that can be looked into is the DEC LAT protocol used for communication to clients, servers, terminal servers, and other devices as if it were a terminal connecting. There is a Linux DECnet project with LAT being worked on.
http://prdownloads.sourceforge.net/linux-decnet/latd-1.14.tar.gz Also NetBSD has real good DECnet support too. Might be too complicated for what we need but I use to manage a lot of different devices all from a single terminal but that was with the OS up and running. GO On Monday 25 March 2002 23:33, Eric W. Biederman wrote: > Peter Lister <[EMAIL PROTECTED]> writes: > > IP multicast has the advantage that some switches (e.g. Cisco, see > > URL) know what it is, so they limit traffic to ports they know (by > > snooping the IGMP packets) to be listening. Using a group MAC address > > with a frame type that switches don't know mean it is forwarded > > everywhere (like a broadcast) unless the switch can talk be told to > > set a multicast group with GMRP. > > Nice point. This makes a good argument in favor of an ip based > solution then. Though I still wonder if the switch can see enough of > the data to keep this from happening. I'll have to look into that > some more. > > > There's also the distinct advantage > > that IP can be routed. How hard is it to get an official IP multicast > > address somewhat like the NTP address? Presumably a (draft) RFC is > > needed. With an official address, hardcoding is OK. > > We need some experience with a proof of concept implementation first. > > > Although the actual traffic volume probably isn't that great, there > > may be an inflationary effect in that if it becomes easy to manage and > > store console logs, then there's more motivation to generate info. :) > > "Keystroke" traffic in the other direction should be unicast, but if > > it is essentially just keystrokes it really *is* minimal. The payload > > protocol would need to have a system identifier to connect to the > > "right" machine, and preferably crypto authentication, as one normally > > wants to keep consoles in a locked room. > > Encryption doesn't buy anything if the data is predictable. And boot > messages are very predictable. > > Also be very clear there are 2 cases. > 1) Having console over ethernet where the normal console assumptions > apply (i.e. you have a crossover cable plugged into your ethernet > port and plugged into a machine you trust) > > 2) Using a console over ethernet protocol in a normal network situation. > You have to lock it down at least to remove being able to send > any characters. And possibly disable it all together. > > > But... this gets me thinking. Why just reproduce a TTY? > > For quick debugging. For a trivial model that is generally useful. > > > Better, surely, > > to encapsulate the things we actually want to do in a protocol like DHCP > > or SNMP with which one can actually express the concept of e.g. > > shutdown. There's still definitely a place for ordinary console output > > for the foreseeable future, but it's worth considering whether we could > > do something better. > > Totally agreed. If you are doing anything repeatable over a console > protocol you should replace it with DHCP, SNMP or something similiar. > But for debugging, especially when all you have is a lan connection a > network console protocol looks to be quite useful. > > > At Sychron, we use our own frame type (not for consoles) and send > > quite a lot of multicasts (actually, we need something which doesn't > > have a name, a sort of hybrid multicast/anycast). We've had many > > debates internally about how much broadcast / multicast traffic we > > can put onto a LAN without frightening the horses. > > > > Cisco on L2 multicasts... > > http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/mcst_ovr >.htm > > Eric
