> > 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.
Not everyone has multicast support in their switches, but this is nice, so you get redundant logging etc. The only question is whether you want to hard code or have an arp type interface to get the address. If you dont use multicast, the address is more likely to change, so you may need a discovery protocol. Broadcast, as discussed before is not very friendly. > 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. yes, udp is nice, as there are easy tools (ie you can use netcat as a simple client, which raw ether wont let you). > 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. agreed. > 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. You probably want to filter by port too, all sorts of udp packets are probably flying around if you are not using a dedicated network (you might have a trusted switched network). The only time that ssh etc tend to break is when networking breaks, or if you fail to boot. My current thought though is (if you are using DoC or have space) to always boot off DoC, and then you can rivot_root onto a disk or whatever if you want to, so there is a failsafe boot. > 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 > Justin
