Re: [Netconsole-devel] Re: [patch] netconsole - log kernel messages over the network. 2.4.10.

[H. P. A. <hp...@zy...>]

Ookhoi wrote:

>>
>>more about features and limitations can be found under:
>>
>>	Documentation/networking/netlogging.txt
>>
>>reports, comments, suggestions welcome.
>>
> 
> Somebody more or less asked this already, but, will things like SysRq
> work in the future? That would be great. :-)  Thnx!
> 


SysRq, as well as input in general (think single-user mode), I think it is
an absolute necessity.  As far as the handling of the MAC address is
concerned, I would like to suggest that netconsole asks the conventional
IP stack to ARP the target address for it periodically (in most/many cases
it will be a fait accompli, and will be in the ARP cache) -- until the
first such ARP transaction, using the broadcast address should be just fine.

I don't think there is any reason to support any other network stack than
IP, and UDP is definitely the way to go.  If it wasn't for the fact that
too many networks today are routed to a very low level I would seriously
suggest using raw layer 2 frames, but I don't think that's a practical
option these days.

We should have a default port number for this application.  I would like
to suggest one for source and one for destination, like bootp/dhcp, since
that would avoid having to dynamically assign a port from the normal IP
stack.  It also is necessary to make input possible before the server has
seen any client packets, and helps avoid spoofing.

Until the protocol is better defined we can't submit an IANA request for
an official port number, but I hereby officially suggest (kudos to
/dev/random) that the server (the concentrator) should run on port 4514
and the client (the host being logged) should run on port 4515.

On the input side, I would like to suggest that we, telnet-style, reserve
\xFF as an escape code; \xFF\xFF representing a single \xFF byte.  In the
 spirit of DHCP, I suggest adopting a format \xFF<opcode><len>... for the
special sequences, with \xFF\x00\x01<code> for SysRq-<code> and the rest
for future use.  The length field allows a kernel which gets a code
sequence that it doesn't know to ignore it.

Obviously, such a code sequence should never be broken up between multiple
packets.

	-hpa