Eric Van Hensbergen <[EMAIL PROTECTED]> writes: > We actually have two console over ethernet systems that we are playinga round > with. One operates completely over raw ethernet using broadcast and a special > Frame ID which is discarded by systems that don't care. We then run a modified > syslog catcher which prepends the MAC Address of the sender to the message. You > > can then use typical Syslog filter mechanisms to get rid of what you don't want > to see. You can also do MAC->IP->Hostname translation.
Is there a reason for not using for a multicast destination mac address, instead of broadcast? > The other system is a bit more complicated and is more for use in the kernel. > It uses a modified Java telnet client and a UDP protocol. It opens up a new > "tab"bed frame for each host connected and gives you two way communicaiton. The > > IP address of the console "server" (where the Java application is running" is > passed via DHCP or as a kernel argument. > > The first method is really light-weight, but implicitly one way. It's usefull > for logging and seeing what the hell is wrong with a system that's not booting. > We have versions running in LinuxBIOS and in the kernel. The second method is > more of a KVM replacement, but doesn't handle things like panics very will (when > > you TCP/IP stack may go out to lunch). It's also pretty heavy weight to put in > the BIOS. > > Some middle ground between the two is probably the most usefull. If there's > general interest, I'll see about including our raw-ethernet console in our > open-source submission to LinuxBIOS (along with Sis635 support). * There is definentily interest.. Eric
