I have finally had a chance to think through the network console concept and I come up with a few thoughts.
First when you start talking to a network the problem is different enough that a replacing everything by one protocol is silly. There are two major uses of a console. - Status reporting (primarily for bootup) - Control by a trusted operator. Status reporting is the easier problem and all LinuxBIOS uses so far, so I won't even touch control. Further the status reporting information is designed for human consumption, and not for automatic consumption. So a free form string is all we need. And the content will never be standardized. Basically you should transmit everything just you would transmit over serial console, with the possible except of pacet transmission information... For status reporting you want it to work in the most minimal enviroment possible that can transmit a network packet. Further as a network console protocol should be useful on headless machines it is reliable enough if a valid packet gets out the network interface and a cross over cable can be connected on another machine to get the information. Reliability in any other situation is not useful. Specifics: 1) Network Address There is very little standardization right now, there may never be so an implementation should be able to select a mac address, and a ip address at compile time. I would suggest a multicast ip and the corresponding multicast mac address be used. As it allows any client on your local network to receive the packet. This is flexibility with the switch doing the work instead of the client. 2) Packet encapsulation Everything beyond raw string data is simply a convinience to make the data easier for an client to pick up. So ip and udp headers look like a good choice. Very simple and small to add. But make it possible to pick up the packet easily. And are the natural canidates so multiple implementations will work together by accident. 3) Security Adding encryption to the data during boot time adds no value as the data is predictable. And knowing the timing and the size of the packet is enough to know what it says. Not allowing a control channel adds minimum risk, and adds a lot of convinience. 4) Control. Using existing network control mechanisms telnet, ssh, etc. Look like the right solution in 99% of the cases. For the case of the fully trusted network (A cross over cable) I suggest simply listening for udp datagrams to any ip, but directly aimed at your mac address. This may be a problem with out of order packets but otherwise it is good. And I doubt out of order packets are a realistic scenario. Since packets may be easily faked any kind of filtering is useless. This includes filtering on mac, ip, or signature. If someone cannot generate a valid control packet on the fly it is easy enough to log one and replay it at unfortunate times. 5) Non Ethernet Connections. Virtually every interconnect has an IP mapping so mapping so it should be a simple matter of matter of mapping ethernet concepts to their equivilants. And following the ip mapping should help. This is all compatible with Ingo's suggested kernel interface, and can easily implemented elsewhere. So thinking this through I'm on board with the concept, and even willing to put some small amount of work into implementing it. Suggest? Comments? I'd like to debug the concept before we go to far. Eric
