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

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

[Marcelo Tosatti]

Ingo, 

Don't you think it would be useful to have some reserved memory for the
netconsole use ?

It would be nice to have a guarantee that messages are sent over network
even if the system is under real OOM. 

On Wed, 26 Sep 2001, Ingo Molnar wrote:

> 
> this is the first public release of the 'netconsole patch', a debugging
> patch that implements kernel-level network logging via UDP packets.
> 
> the special thing about this approach is the ability to send 'emergency'
> network packets even from IRQ handlers. This enables the netconsole to
> send enough info even if we crash in init or in an interrupt handler.
> 
> another property of netconsole is that it's able to share the networking
> device with other kernel subsystems, like the TCP/IP stack. So the
> networking device is not dedicated for netconsole use, it's transparently
> shared.
> 
> netconsole is also designed to be robust, it goes straight to the network
> driver, so it does not depend on the networking stack to log messages.
> 
> kernel-level netlogging is useful in a number of scenarios:
> 
>  - if remotely managed systems with no serial cable logging keep crashing
>    without any trace of an oops message in the userspace log. (the patch
>    was written to debug such a crash. Original idea of sending an
>    emergency packet from IRQ handlers comes from Daniel Veillard who's
>    system produced the crash - thanks Daniel!)
> 
>  - if for whatever reason the amount of logging is so high that a serial
>    console cannot hold it and disks can not keep up - or in cases where
>    logged messages disturb the debugged subsystem. I'm sure fellow VM
>    hackers will find this useful :-)
> 
>  - the netconsole can be used to emit crashdumps over the network, without
>    any delay between the point of crash and start of netlogging.
> 
> the kernel patch (against 2.4.10 or 2.4.9-ac), and a simple user-space
> tool to display netconsole messages can be found at:
> 
> 	http://redhat.com/~mingo/netconsole-patches/
> 
> sample startup of the netconsole on the server:
> 
>      insmod netconsole dev=eth1 target_ip=0x0a000701 \
>                   source_port=6666 \
>                   target_port=6666 \
>                   target_eth_byte0=0x00 \
>                   target_eth_byte1=0x90\
>                   target_eth_byte2=0x27 \
>                   target_eth_byte3=0x8C \
>                   target_eth_byte4=0xA0 \
>                   target_eth_byte5=0xA8
> 
> and on the client:
> 
> 	# ./netconsole-client -server 10.0.7.5 -client 10.0.7.1 -port 6666
>         [...network console startup...]
>         netconsole: network logging started up successfully!
>         SysRq : Loglevel set to 9
> 
> more about features and limitations can be found under:
> 
> 	Documentation/networking/netlogging.txt
> 
> reports, comments, suggestions welcome.
> 
> 	Ingo
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

[patch] netconsole - log kernel messages over the network. 2.4.10.

[Ingo Molnar]

this is the first public release of the 'netconsole patch', a debugging
patch that implements kernel-level network logging via UDP packets.

the special thing about this approach is the ability to send 'emergency'
network packets even from IRQ handlers. This enables the netconsole to
send enough info even if we crash in init or in an interrupt handler.

another property of netconsole is that it's able to share the networking
device with other kernel subsystems, like the TCP/IP stack. So the
networking device is not dedicated for netconsole use, it's transparently
shared.

netconsole is also designed to be robust, it goes straight to the network
driver, so it does not depend on the networking stack to log messages.

kernel-level netlogging is useful in a number of scenarios:

 - if remotely managed systems with no serial cable logging keep crashing
   without any trace of an oops message in the userspace log. (the patch
   was written to debug such a crash. Original idea of sending an
   emergency packet from IRQ handlers comes from Daniel Veillard who's
   system produced the crash - thanks Daniel!)

 - if for whatever reason the amount of logging is so high that a serial
   console cannot hold it and disks can not keep up - or in cases where
   logged messages disturb the debugged subsystem. I'm sure fellow VM
   hackers will find this useful :-)

 - the netconsole can be used to emit crashdumps over the network, without
   any delay between the point of crash and start of netlogging.

the kernel patch (against 2.4.10 or 2.4.9-ac), and a simple user-space
tool to display netconsole messages can be found at:

	http://redhat.com/~mingo/netconsole-patches/

sample startup of the netconsole on the server:

     insmod netconsole dev=eth1 target_ip=0x0a000701 \
                  source_port=6666 \
                  target_port=6666 \
                  target_eth_byte0=0x00 \
                  target_eth_byte1=0x90\
                  target_eth_byte2=0x27 \
                  target_eth_byte3=0x8C \
                  target_eth_byte4=0xA0 \
                  target_eth_byte5=0xA8

and on the client:

	# ./netconsole-client -server 10.0.7.5 -client 10.0.7.1 -port 6666
        [...network console startup...]
        netconsole: network logging started up successfully!
        SysRq : Loglevel set to 9

more about features and limitations can be found under:

	Documentation/networking/netlogging.txt

reports, comments, suggestions welcome.

	Ingo

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

[jamal]

Is there any reason you are not using dev_queue_xmit()?
(side benefits, you could hack this into using scatter gather schemes etc)

cheers,
jamal

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

[Andreas Dilger]

On Wed, 26 Sep 2001, Ingo Molnar wrote:
> sample startup of the netconsole on the server:
> 
>      insmod netconsole dev=eth1 target_ip=0x0a000701 \
>                   source_port=6666 \
>                   target_port=6666 \
>                   target_eth_byte0=0x00 \
>                   target_eth_byte1=0x90\
>                   target_eth_byte2=0x27 \
>                   target_eth_byte3=0x8C \
>                   target_eth_byte4=0xA0 \
>                   target_eth_byte5=0xA8

Ugh.  Maybe a wrapper script (netconsole-server) which automates this is
in order?  I imagine the eth_byteX is a MAC address (or at least that this
is in the documentation)?

> > and on the client:
> > 
> > 	# ./netconsole-client -server 10.0.7.5 -client 10.0.7.1 -port 6666
> >         [...network console startup...]
> >         netconsole: network logging started up successfully!
> >         SysRq : Loglevel set to 9

<wishlist>
Any chance the netconsole-client can be set up to listen for multiple hosts
and log to the local syslog?  This would allow you to run netconsole-client
on your normal syslog host and add timestamps, clean up old logs, etc.

I take it that this is only a one-way interface (i.e. logs sent from the
server to the client), and not a real serial-console replacement?
</wishlist>

In any case, this will be EXTREMELY useful for me, as a lot of new machines
do not have serial ports and are a PITA to debug in case of a crash.  Thanks.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

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

[Andreas Dilger]

On Sep 26, 2001  15:29 -0600, adilger wrote:
> On Wed, 26 Sep 2001, Ingo Molnar wrote:
> > sample startup of the netconsole on the server:
> > 
> >      insmod netconsole dev=eth1 target_ip=0x0a000701 \
> >                   source_port=6666 \
> >                   target_port=6666 \
> >                   target_eth_byte0=0x00 \
> >                   target_eth_byte1=0x90\
> >                   target_eth_byte2=0x27 \
> >                   target_eth_byte3=0x8C \
> >                   target_eth_byte4=0xA0 \
> >                   target_eth_byte5=0xA8
> 
> Ugh.  Maybe a wrapper script (netconsole-server) which automates this is
> in order?  I imagine the eth_byteX is a MAC address (or at least that this
> is in the documentation)?

Ok, I read the docs, and this is indeed a target MAC address.  It may still
be easier to accept a regular MAC address like target_mac=XX:XX:XX:XX:XX:XX
as the module parameter (and a target_ip=A.B.C.D).  In any case, here is a
script to automate this (ugly because of the conversions needed).

=========================================================================
#!/bin/sh
prog=netconsole-server
#
# initialize the netconsole using reasonable defaults (normally just the
# client IP address, and possibly the port.  We can determine the MAC
# address of the client system, IP address, the correct device, and verify
# that we are using an ethernet interface (required for netconsole to work).
#
# Andreas Dilger <adilger@turbolinux.com>  Sep 26, 2001

usage()
{
	cat - <<- EOF 1>&2

	Initialize a network message console over UDP.

	usage: $prog [-b] [-d dev] [-m mac] [-p port] target[:port]
		-b       - use broadcast ethernet MAC address
		-m       - specify remote system MAC address (default: detect)
		-p       - local port to use for message traffic (default: 6666)
		-d       - ethernet device to use for messages (default: detect)
		target   - hostname/IP address of remote netconsole-client
		:port    - port on target netconsole-client (default: like -p)
	EOF
	exit 1
}

PATH=$PATH:/sbin:/usr/sbin
PORT=6666

while [ $# -ge 1 ]; do case $1 in
	-b) NOMAC=1 ;;
	-d) DEV=$2; shift ;;
	-m) MAC=$2; shift ;;
	-p) PORT=$2; shift ;;
	*:*) TGT=`echo $1 | sed "s/:.*//"`; TPORT=`echo $1 | sed "s/.*://"` ;;
	*) TGT=$1 ;;
	esac
	shift
done

[ -z "$TGT" ] && usage
[ -z "$TPORT" ] && TPORT=$PORT

ping -c 1 $TGT > /dev/null 2>&1
[ $? -ne 0 ] && echo "$prog: can't ping $TGT" 1>&2 && usage

dquad_to_hex()
{
	echo $1 | sed -e "s/[()]//g" -e "s/\./ /g" | while read I0 I1 I2 I3 ; do
		printf "0x%02X%02X%02X%02X" $I0 $I1 $I2 $I3
	done
}

# output from arp -a of the form:
# good: host.domain (A.B.C.D) at 00:50:BF:06:48:C1 [ether] on eth0
# bad:  ? (A.B.C.D) at <incomplete> on eth0
arp -a | grep $TGT | { read HOSTNAME IPADDR AT MACADDR TYPE ON IFACE;
	[ "$HOSTNAME" = "?" -a -z "$MAC" -a -z "$NOMAC" ] && \
		echo "$prog: can't resolve $TGT MAC" 1>&2 && usage

	[ -z "$MAC" ] && MAC=$MACADDR
	[ -z "$DEV" ] && DEV=$IFACE
	[ "$DEV" = "$IFACE" -a "$TYPE" != "[ether]" ] && \
		echo "$prog: $DEV must be an ethernet interface" 1>&2 && usage
		
	IPHEX=`dquad_to_hex $IPADDR`
	echo $MAC | sed "s/:/ /g" | { read M0 M1 M2 M3 M4 M5;
		if [ -z "$NOMAC" ]; then
			TGTMAC="target_eth_byte0=0x$M0 target_eth_byte1=0x$M1 \
				target_eth_byte2=0x$M2 target_eth_byte3=0x$M3 \
				target_eth_byte4=0x$M4 target_eth_byte5=0x$M5"
		fi
		#insmod netconsole dev=$DEV target_ip=$IPHEX \
		echo dev=$DEV target_ip=$IPHEX \
			source_port=$PORT target_port=$TPORT $TGTMAC
	}
}

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

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

[Ingo Molnar]

On Wed, 26 Sep 2001, Andreas Dilger wrote:

> Ok, I read the docs, and this is indeed a target MAC address.  It may
> still be easier to accept a regular MAC address like
> target_mac=XX:XX:XX:XX:XX:XX as the module parameter (and a
> target_ip=A.B.C.D).  In any case, here is a script to automate this
> (ugly because of the conversions needed).

thanks - i've put this script into the userspace tarball.

	Ingo

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

[Ingo Molnar]

On Wed, 26 Sep 2001, jamal wrote:

> Is there any reason you are not using dev_queue_xmit()? (side
> benefits, you could hack this into using scatter gather schemes etc)

the reason is latency of messages, and reliability of sends. If we are in
the middle of a *nasty* crash that takes down the system down 10
microseconds later, then i wanted to make 100% sure the message gets out
and the bug can be debugged. The VGA console and the serial logging
console have such properties - messages are instantaneous. Networking is
very asynchron in nature, so a new network driver extension was needed to
achieve this goal.

There are crashes where there are no new IRQs processed after the crash,
so there is no chance for dev_queue_xmit to do any useful send. We must be
able to send packets even if the output interface's hardware queues are
full - and dev_queue_xmit relies on future device interrupts to send
queued packets.

this is not just theory - about 10% of the crashes i experience (during
development...) are such, and the majority of the 'hard to fix' crashes
have such properties, especially on busy remote servers.

	Ingo

[patch] netconsole-2.4.10-B1

[Ingo Molnar]

On Wed, 26 Sep 2001, Marcelo Tosatti wrote:

> Don't you think it would be useful to have some reserved memory for
> the netconsole use ?
> It would be nice to have a guarantee that messages are sent over
> network even if the system is under real OOM.

yep, that is very useful indeed.

i've implemented a private emergency pool of 32 packets that we try to
keep filled as much as possible, and which one we use only if GFP_ATOMIC
fails. The new patch can downloaded from:

   http://redhat.com/~mingo/netconsole-patches/netconsole-2.4.10-B1

the patch also includes Andrew Morton's suggestion to add the
HAVE_POLL_CONTROLLER define for easier network-driver integration. The
eepro100.c changes now use this define.

the new utilities-tarball is at:

   http://redhat.com/~mingo/netconsole-patches/netconsole-client-20010927.tar.gz

this includes Andreas Dilger's netconsole-server script. (i've done a
minor modification to the script, it insmods the netconsole module with
the parameters.)

there is one more thing we could do: we could also allocate the skb on
stack in extreme cases. This adds noticeable latency though, since the skb
xmit has to be polled for completion as well [this can be done with the
current ->poll_controller() method], but this way the netconsole could be
self-sufficient and would be completely independent of the VM.

reports, suggestions, comments welcome,

	Ingo

Re: [patch] netconsole-2.4.10-B1

[Andreas Dilger]

On Sep 27, 2001  08:38 +0200, Ingo Molnar wrote:
> the patch also includes Andrew Morton's suggestion to add the
> HAVE_POLL_CONTROLLER define for easier network-driver integration. The
> eepro100.c changes now use this define.
> 
> the new utilities-tarball is at:
> 
> http://redhat.com/~mingo/netconsole-patches/netconsole-client-20010927.tar.gz

A few minor changes to the code, after testing it a bit locally (note that I
am using kernel patch C1):

First, a patch to change the MAC address kernel parameter to be in the
standard XX:XX:XX:XX:XX:XX form, instead of separate bytes.  It also
fixes the output of the IP addresses to be unsigned ints.  Isn't there
a function in the kernel to format IP addresses for output already?

Next, a patch to netconsole-server to use the target_mac parameter
instead of the target_eth_byteX parameters.  I thought about keeping
these around for compatibility, but since this is a relatively new
tool there is no point in keeping the extra baggage.

TODO: figure out what "offset" is really supposed to be useful for.  Maybe
      it should be aligned properly, and we add the message priority into
      one of the free bytes?

Finally, a patch to netconsole-client.c which does a few things:
- remove "offset" from output, it appears meaningless and screws formatting.
- allow the client to receive messages from multiple servers, unless a
  single server is specified.
- log to syslog (this is a bit complex because of the desire to write full
  lines into the syslog as opposed to chunks of the size sent by printk().
- (minor) change parameters to use "--" long option names in preparation
  for using getopt-long to do CLI parsing.
- (minor) don't require the --port option (use 6666 as default)
- (minor) don't require the --server option (accept all messages by default)

TODO: don't require the --client option (get ipaddress from interface and/or
      listen on all interfaces by default)
TODO: add getopt_long parsing of options to avoid ordered option requirement
TODO: make syslog and stdout logging optional (need one or the other obviously)
TODO: print server IP/hostname in syslog/stdout output in case we are getting
      messages from multiple servers
TODO: figure out why LOG_KERN does not show up in kernel log, while klogd does
TODO: add timeout for messages in syslog output buffer.
TODO: allow client/server to be specified by both hostname/IP
TODO: allow different client/server port numbers?  Do we care?

As an added bonus, a patch for 8139too.c which adds poll support (Jeff CC'd).

Cheers, Andreas
======================= netconsole-2.4.8-mac.diff =====================
--- linux/drivers/net/netconsole.c.orig	Thu Sep 27 10:11:27 2001
+++ linux/drivers/net/netconsole.c	Thu Sep 27 17:13:24 2001
@@ -219,20 +219,10 @@
 }
 
 static char *dev;
-static int target_eth_byte0 = 255;
-static int target_eth_byte1 = 255;
-static int target_eth_byte2 = 255;
-static int target_eth_byte3 = 255;
-static int target_eth_byte4 = 255;
-static int target_eth_byte5 = 255;
+static char *target_mac;
 
 MODULE_PARM(target_ip, "i");
-MODULE_PARM(target_eth_byte0, "i");
-MODULE_PARM(target_eth_byte1, "i");
-MODULE_PARM(target_eth_byte2, "i");
-MODULE_PARM(target_eth_byte3, "i");
-MODULE_PARM(target_eth_byte4, "i");
-MODULE_PARM(target_eth_byte5, "i");
+MODULE_PARM(target_mac, "s");
 MODULE_PARM(source_port, "h");
 MODULE_PARM(target_port, "h");
 MODULE_PARM(dev, "s");
@@ -267,8 +257,8 @@
 		printk(KERN_ERR "netconsole: network device %s has no local address, aborting.\n", dev);
 		return -1;
 	}
-#define IP(x) ((char *)&source_ip)[x]
-	printk(KERN_INFO "netconsole: using source IP %i.%i.%i.%i\n",
+#define IP(x) ((unsigned char *)&source_ip)[x]
+	printk(KERN_INFO "netconsole: using source IP %u.%u.%u.%u\n",
 		IP(3), IP(2), IP(1), IP(0));
 #undef IP
 	source_ip = htonl(source_ip);
@@ -276,8 +266,8 @@
 		printk(KERN_ERR "netconsole: target_ip parameter not specified, aborting.\n");
 		return -1;
 	}
-#define IP(x) ((char *)&target_ip)[x]
-	printk(KERN_INFO "netconsole: using target IP %i.%i.%i.%i\n",
+#define IP(x) ((unsigned char *)&target_ip)[x]
+	printk(KERN_INFO "netconsole: using target IP %u.%u.%u.%u\n",
 		IP(3), IP(2), IP(1), IP(0));
 #undef IP
 	target_ip = htonl(target_ip);
@@ -294,18 +284,26 @@
 	printk(KERN_INFO "netconsole: using target UDP port: %i\n", target_port);
 	target_port = htons(target_port);
 
-	daddr[0] = target_eth_byte0;
-	daddr[1] = target_eth_byte1;
-	daddr[2] = target_eth_byte2;
-	daddr[3] = target_eth_byte3;
-	daddr[4] = target_eth_byte4;
-	daddr[5] = target_eth_byte5;
-
-	if ((daddr[0] & daddr[1] & daddr[2] & daddr[3] & daddr[4] & daddr[5]) == 255)
-		printk(KERN_INFO "netconsole: using broadcast ethernet frames to send packets.\n");
-	else
-		printk(KERN_INFO "netconsole: using target ethernet address %02x:%02x:%02x:%02x:%02x:%02x.\n", daddr[0], daddr[1], daddr[2], daddr[3], daddr[4], daddr[5]);
-		
+	if (target_mac) {
+		char *ptr = target_mac;
+		int i;
+
+		printk(KERN_INFO "netconsole: using target ethernet MAC: %s\n",
+		       target_mac);
+		for (i = 0; i < 6 && ptr; i++) {
+			int val;
+			char *sep;
+			val = simple_strtoul(ptr, &sep, 16);
+			if (sep != ptr) {
+				daddr[i] = val;
+				ptr = *sep ? sep + 1 : NULL;
+			}
+		}
+	} else
+		printk(KERN_INFO "netconsole: using broadcast ethernet MAC.\n");
+
 	netconsole_dev = ndev;
 #define STARTUP_MSG "[...network console startup...]\n"
 	write_netconsole_msg(NULL, STARTUP_MSG, strlen(STARTUP_MSG));
===================== netconsole-server.diff =============================
--- netconsole-client/netconsole-server.orig	Thu Sep 27 00:32:50 2001
+++ netconsole-client/netconsole-server	Thu Sep 27 17:22:55 2001
@@ -30,9 +30,11 @@
 
 while [ $# -ge 1 ]; do case $1 in
 	-b) NOMAC=1 ;;
-	-d) DEV=$2; shift ;;
-	-m) MAC=$2; shift ;;
-	-p) PORT=$2; shift ;;
+	-d|--device) DEV=$2; shift ;;
+	-m|--mac) MAC=$2; shift ;;
+	-p|--port) PORT=$2; shift ;;
+	--client) TGT=`echo $2| sed "s/:.*//"`;
+		TPORT=`echo $2 | sed "s/.*://"`; shift ;;
 	*:*) TGT=`echo $1 | sed "s/:.*//"`; TPORT=`echo $1 | sed "s/.*://"` ;;
 	*) TGT=$1 ;;
 	esac
@@ -65,16 +67,9 @@
 		echo "$prog: $DEV must be an ethernet interface" 1>&2 && usage
 		
 	IPHEX=`dquad_to_hex $IPADDR`
-	echo $MAC | sed "s/:/ /g" | { read M0 M1 M2 M3 M4 M5;
-		if [ -z "$NOMAC" ]; then
-			TGTMAC="target_eth_byte0=0x$M0 target_eth_byte1=0x$M1 \
-				target_eth_byte2=0x$M2 target_eth_byte3=0x$M3 \
-				target_eth_byte4=0x$M4 target_eth_byte5=0x$M5"
-		fi
-		echo dev=$DEV target_ip=$IPHEX \
-			source_port=$PORT target_port=$TPORT $TGTMAC
-		/sbin/insmod netconsole dev=$DEV target_ip=$IPHEX \
-			source_port=$PORT target_port=$TPORT $TGTMAC
-	}
+	[ -z "$NOMAC" ] && TGTMAC="target_mac=$MAC"
+	echo dev=$DEV target_ip=$IPHEX \
+		source_port=$PORT target_port=$TPORT $TGTMAC
+	insmod netconsole dev=$DEV target_ip=$IPHEX \
+		source_port=$PORT target_port=$TPORT $TGTMAC
 }
-
===================== netconsole-client.diff =============================
--- netconsole-client/netconsole-client.c.orig	Thu Sep 27 08:32:31 2001
+++ netconsole-client/netconsole-client.c	Thu Sep 27 16:07:39 2001
@@ -17,47 +17,59 @@
 #include <sys/socket.h>
 #include <netinet/in.h>
 #include <arpa/inet.h>
+#include <syslog.h>
 
 #define NETCONSOLE_VERSION 0x01
 
 #define BUFLEN 10000
 
+#ifndef min
+#define min(a,b) ((a) < (b) ? (a) : (b))
+#endif
+
 int main (int argc, char **argv)
 {
 	struct sockaddr_in saddr, caddr;
 	int udp_socket;
-	unsigned char buf[BUFLEN];
-	int len, port;
+	unsigned char buf[BUFLEN], sysbuf[BUFLEN];
+	unsigned int sysoff = 0;
+	int len, port = 6666;
 	struct sockaddr_in addr;
 	int addr_len = sizeof(addr);
+	int noserver = 1;
 
 	memset(&addr, 0, addr_len);
 	memset(&saddr, 0, addr_len);
 	memset(&caddr, 0, addr_len);
 
-	if (argc != 7) {
-		fprintf(stderr, "usage: netconsole-client -server <IP> -client <IP> -port <port>\n");
+	if (argc != 3 && argc != 5 && argc != 7) {
+		fprintf(stderr, "usage: netconsole-client --client <IP> [--port <port> [--server <IP>]]\n");
 		exit(-1);
 	}
-	port = atol(argv[6]);
-	printf("displaying netconsole output from server %s, client %s, UDP port %d.\n", argv[2], argv[4], port);
+	if (argc > 4)
+		port = atol(argv[4]);
+	printf("listening on interface %s:%d for server %s:%d.\n", argv[2], port, argc > 6 ? argv[6] : "ANY", port);
 
 
 	udp_socket = socket(PF_INET, SOCK_DGRAM, 0);
 
-	saddr.sin_family = AF_INET;
-	saddr.sin_port = htons(port);
-	saddr.sin_addr.s_addr = inet_addr(argv[2]);
-
 	caddr.sin_family = AF_INET;
 	caddr.sin_port = htons(port);
-	caddr.sin_addr.s_addr = inet_addr(argv[4]);
+	caddr.sin_addr.s_addr = inet_addr(argv[2]);
+
+	if (argc > 5) {
+		saddr.sin_family = AF_INET;
+		saddr.sin_port = htons(port);
+		saddr.sin_addr.s_addr = inet_addr(argv[6]);
+		noserver = 0;
+	}
 
 	if (bind(udp_socket, (struct sockaddr *)&caddr, sizeof(caddr))) {
 		perror("could not bind UDP socket!\n");
 		exit(-1);
 	}
 
+	openlog("netconsole", 0, LOG_KERN);
 	while (1) {
 		len = recvfrom(udp_socket, buf, BUFLEN, 0, (struct sockaddr *)&addr, &addr_len);
 		if (len <= 0) {
@@ -65,10 +77,15 @@
 			exit(-1);
 		}
 		buf[len] = 0;
-		if (!memcmp(&addr, &saddr, addr_len)) {
-			unsigned int offset;
+		if (noserver || !memcmp(&addr, &saddr, addr_len)) {
+			unsigned int offset, skip;
+			unsigned int priority = LOG_WARNING, new_priority;
+			unsigned char *nl;
+
 			if (buf[0] != NETCONSOLE_VERSION) {
-				printf("[netconsole server has version %d, client supports only version %d! exiting.]\n", buf[0], NETCONSOLE_VERSION);
+				printf("[netconsole server has version %d, "
+				       "client supports only version %d! "
+				       "exiting.]\n", *buf, NETCONSOLE_VERSION);
 				exit(-1);
 			}
 
@@ -76,10 +93,42 @@
 			offset = (offset << 8) | buf[2];
 			offset = (offset << 8) | buf[3];
 			offset = (offset << 8) | buf[4];
+			skip = 5;
 
-			printf("(%d): %s", offset, buf+5);
+			printf("%s", buf + skip);
 			fflush(stdout);
+			if (sysoff == 0 &&
+			    sscanf(buf + skip, "<%d>", &new_priority) == 1) {
+				if (new_priority <= LOG_DEBUG) {
+					priority = new_priority;
+					skip += 3;
+				}
+			}
+			while ((nl = strchr(buf + skip, '\n'))) {
+				int used, left;
+
+				used = (nl - (buf + skip)) + 1;
+				left = sizeof(sysbuf) - sysoff - 1;
+
+				strncat(sysbuf + sysoff, buf + skip,
+					min(used, left));
+				/* FIXME: need to print source hostname/IP */
+				syslog(priority, "%s", sysbuf);
+				sysbuf[(sysoff = 0)] = '\0';
+				skip += min(used, left);
+			}
+			if (buf[skip]) {
+				strncat(sysbuf + sysoff, buf + skip,
+					 sizeof(sysbuf) - sysoff - 1);
+				sysoff += strlen(buf + skip);
+				if (sysoff >= sizeof(sysbuf)) {
+					syslog(priority, "%s", sysbuf);
+					sysbuf[(sysoff = 0)] = '\0';
+				}
+			}
+
 		}
 	}
+	closelog();
 	return 0;
 }
========================= 8139too-poll.diff ==============================
--- linux/drivers/net/8139too.c.orig	Tue Jul 31 15:15:28 2001
+++ linux/drivers/net/8139too.c	Thu Sep 27 10:15:59 2001
@@ -619,6 +619,9 @@
 static void rtl8139_init_ring (struct net_device *dev);
 static int rtl8139_start_xmit (struct sk_buff *skb,
 			       struct net_device *dev);
+#ifdef HAVE_POLL_CONTROLLER
+static void rtl8139_poll (struct net_device *dev);
+#endif
 static void rtl8139_interrupt (int irq, void *dev_instance,
 			       struct pt_regs *regs);
 static int rtl8139_close (struct net_device *dev);
@@ -965,6 +968,9 @@
 	dev->get_stats = rtl8139_get_stats;
 	dev->set_multicast_list = rtl8139_set_rx_mode;
 	dev->do_ioctl = netdev_ioctl;
+#ifdef HAVE_POLL_CONTROLLER
+	dev->poll_controller = rtl8139_poll;
+#endif
 	dev->tx_timeout = rtl8139_tx_timeout;
 	dev->watchdog_timeo = TX_TIMEOUT;
 
@@ -2201,6 +2207,20 @@
 	return 0;
 }
 
+
+#ifdef HAVE_POLL_CONTROLLER
+/*
+ * Polling 'interrupt' - used by things like netconsole to send skbs
+ * without having to re-enable interrupts. It's not called while
+ * the interrupt routine is executing.
+ */
+static void rtl8139_poll(struct net_device *dev)
+{
+	disable_irq(dev->irq);
+	rtl8139_interrupt(dev->irq, dev, NULL);
+	enable_irq(dev->irq);
+}
+#endif
 
 static int netdev_ethtool_ioctl (struct net_device *dev, void *useraddr)
 {
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

[patch] netconsole-2.4.10-C2

[Ingo Molnar]

On Thu, 27 Sep 2001, Albert Cranford wrote:

> Great tool Ingo thanks.  Below is a tested tulip patch.
> Thanks Andrew for the the inspiration.

thanks Albert - i've added it to the patch, and the latest
netconsole-2.4.10-C2 version can be downloaded from:

	http://redhat.com/~mingo/netconsole-patches/

NOTE: new client-side utilities are needed as well.

other changes:

 - netconsole-server fix from Andreas Dilger

 - introduced versioning and offsetting of output, to display messages in
   the correct order even if interim routers reorder packets. Future
   netconsole-clients should reliably detect the right protocol version.

 - small cleanups.

	Ingo

Re: [patch] netconsole-2.4.10-B1

[Randy.Dunlap]

Andreas Dilger wrote:
> 
> On Sep 27, 2001  08:38 +0200, Ingo Molnar wrote:
> > the patch also includes Andrew Morton's suggestion to add the
> > HAVE_POLL_CONTROLLER define for easier network-driver integration. The
> > eepro100.c changes now use this define.
> >
> > the new utilities-tarball is at:
> >
> > http://redhat.com/~mingo/netconsole-patches/netconsole-client-20010927.tar.gz
> 
> A few minor changes to the code, after testing it a bit locally (note that I
> am using kernel patch C1):

[snip]

> Finally, a patch to netconsole-client.c which does a few things:
> - remove "offset" from output, it appears meaningless and screws formatting.
> - allow the client to receive messages from multiple servers, unless a
>   single server is specified.

> TODO: allow client/server to be specified by both hostname/IP
> TODO: allow different client/server port numbers?  Do we care?

Hi,

I hope to be able to use this, but...

I must admit that I'm confused by the terms server, client, and
target.

1.  This is what I first thought:

server = the logging machine, client = machine under test,
and that "target" = client?

2.  Then I was told this:
target == the machine to log to (== logging server)

so I thought that if the target is the server, then the client
must run on the machine under test.  But the client program
won't be started early enough during boot for that to help me.

3.  Then I was told this:
netconsole-client is the server
and
mingo should rename it ;-)

4.  And finally this:
netconsole-client == target
kernel == source


WHOA!  Stop the presses.  Can someone say this more clearly,
and I'd suggest not using 3 names when 2 will do (probably
get rid of "target" and use client/server, or use some
other terminology).

~Randy

Re: [patch] netconsole-2.4.10-B1

[Ingo Molnar]

sorry :-) definitions of netconsole-terms:

'server': the host that is the source of the messages. Ie. the box that
          runs the netconsole.o module. It serves log messages to the
          client.

'client': the host that receives the messages. This box is running the
          netconsole-client.c program.

'target': the host that gets the messages sent - ie. the client.

'target IP address': the IP address of the 'target'.

'target ethernet address': the local-net host or first-hop router that
                           gets the netconsole UDP packets sent. Ie. it
                           does not necesserily match the MAC address of
                           the 'target'.

(i can see where the confusion comes from, 'syslog servers' are ones that
receieve syslogs. It's a backwards term i think. 'netconsole servers' are
the ones that produce the messages.)

does it make more sense now? :)

	Ingo

Re: [patch] netconsole-2.4.10-B1

[John Alvord]

On Sat, 29 Sep 2001, Ingo Molnar wrote:

> 
> sorry :-) definitions of netconsole-terms:
> 
> 'server': the host that is the source of the messages. Ie. the box that
>           runs the netconsole.o module. It serves log messages to the
>           client.
> 
> 'client': the host that receives the messages. This box is running the
>           netconsole-client.c program.
> 
> 'target': the host that gets the messages sent - ie. the client.
> 
> 'target IP address': the IP address of the 'target'.
> 
> 'target ethernet address': the local-net host or first-hop router that
>                            gets the netconsole UDP packets sent. Ie. it
>                            does not necesserily match the MAC address of
>                            the 'target'.
> 
> (i can see where the confusion comes from, 'syslog servers' are ones that
> receieve syslogs. It's a backwards term i think. 'netconsole servers' are
> the ones that produce the messages.)
> 
> does it make more sense now? :)

Would this scheme work for crash dump capturing?

john

Re: [patch] netconsole-2.4.10-B1

[Pekka Savola]

On Sat, 29 Sep 2001, Ingo Molnar wrote:
> (i can see where the confusion comes from, 'syslog servers' are ones that
> receieve syslogs. It's a backwards term i think. 'netconsole servers' are
> the ones that produce the messages.)

Speaking of which, would it be too big a burden (or is it supported
already), that the oopses or dumps would be sent off to an off-link syslog
server?

This would ease the use in occasions where you don't expect a crash (ie:
no listener in local network), but do log on remote syslogd's
considerably.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

Re: [patch] netconsole-2.4.10-B1

[Andreas Dilger]

On Sep 29, 2001  19:40 +0300, Pekka Savola wrote:
> Speaking of which, would it be too big a burden (or is it supported
> already), that the oopses or dumps would be sent off to an off-link syslog
> server?
> 
> This would ease the use in occasions where you don't expect a crash (ie:
> no listener in local network), but do log on remote syslogd's
> considerably.

That was in the patch I just sent to Ingo - the "client" logs all of the
messages to syslog.  However, it is not "perfect" yet, in that you need
to be able to select whether or not you really want it sent to syslog,
and for some reason, even though I have LOG_KERN as the type, it only
gets logged to /var/log/messages and not /var/log/kern.log (on my system
at least) (this was in the TODO list, which I'm not in the position to
work on right now).

For crash dumps and such (which you don't want sent to syslog) it may be
useful to have a different message type (with its own offset numbers),
so the client knows to save it to a different file, for example, and will
handle out-of-order messages, and sparse memory dumps.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [patch] netconsole-2.4.10-B1

[Kenneth Johansson]

Ingo Molnar wrote:

> sorry :-) definitions of netconsole-terms:
>
> 'server': the host that is the source of the messages. Ie. the box that
>           runs the netconsole.o module. It serves log messages to the
>           client.
>
> 'client': the host that receives the messages. This box is running the
>           netconsole-client.c program.
>
> 'target': the host that gets the messages sent - ie. the client.
>
> 'target IP address': the IP address of the 'target'.
>
> 'target ethernet address': the local-net host or first-hop router that
>                            gets the netconsole UDP packets sent. Ie. it
>                            does not necesserily match the MAC address of
>                            the 'target'.
>
> (i can see where the confusion comes from, 'syslog servers' are ones that
> receieve syslogs. It's a backwards term i think. 'netconsole servers' are
> the ones that produce the messages.)
>

Servers is usually the thing waiting for something to be sent to it, the
client is the sending part(initiator). this works for web servers , X
servers, log servers but strangley not for netconsole where everything is
backwards.

>
> does it make more sense now? :)
>

Not really :)

Re: [patch] netconsole-2.4.10-B1

[Rik van Riel]

On Sun, 30 Sep 2001, Kenneth Johansson wrote:
> Ingo Molnar wrote:
>
> > sorry :-) definitions of netconsole-terms:
> >
> > 'server': the host that is the source of the messages. Ie. the box that
> >           runs the netconsole.o module. It serves log messages to the
> >           client.
> >
> > 'client': the host that receives the messages. This box is running the
> >           netconsole-client.c program.
>
> Servers is usually the thing waiting for something to be sent to it,
> the client is the sending part(initiator). this works for web servers
> , X servers, log servers but strangley not for netconsole where
> everything is backwards.

Owww crap.  The majority of web traffic is _from_ the
server _to_ the client. Same for ftp, realaudio, etc...

In fact, usually the server is the _remote_ machine and
the client is the _local_ machine. Anybody who believes
in having the client remote and the server local should
be shipped off to whereever the server is ;)

regards,

Rik
-- 
IA64: a worthy successor to i860.

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: [patch] netconsole-2.4.10-B1

[Riley Williams]

Hi Rik.

>>> sorry :-) definitions of netconsole-terms:
>>>
>>> 'server': the host that is the source of the messages. Ie. the box that
>>>           runs the netconsole.o module. It serves log messages to the
>>>           client.
>>>
>>> 'client': the host that receives the messages. This box is running the
>>>           netconsole-client.c program.

>> Servers is usually the thing waiting for something to be sent to it,
>> the client is the sending part(initiator). this works for web
>> servers, X servers, log servers but strangley not for netconsole
>> where everything is backwards.

> Owww crap.  The majority of web traffic is _from_ the server _to_
> the client. Same for ftp, realaudio, etc...

> In fact, usually the server is the _remote_ machine and the client
> is the _local_ machine.

There's actually one example in the email you were replying to where the
server is the local machine and the client is the remote one, which you
must have overlooked: X-Windows defines the server as being the machine
with the display that it is to draw its picture on.

Perhaps I can offer a more reasonable definition than yours, and one
that is offered by most UK universities:

    SERVER	The system with some facility which other systems
		wish to make use of.

    CLIENT	The system wishing to make use of some facility on
		the server.

Apply that to the relevant protocols and you get the following table:

	PROTOCOL	SERVER		CLIENT

	Login - CHAP	Local		Remote
	Login - PAP	Local		Remote
	Login - SSH	Local		Remote
	Login - Text	Remote		Local

	FTP		Remote		Local
	LogServer	Remote		Local
	PrintServer	Remote		Local
	RealAudio	Remote		Local
	Web		Remote		Local

	X-Windows	Local		Remote

	NetConsole	???		???

Note that under that definition, the server can be either the local or
the remote system, with a 3:2 bias towards it being the remote system. I
don't know NetConsole, so can't comment on how it uses them.

Also note that for one task (logging in) that can be done by four
different methods (that I am aware of), only one of those methods has
the server as the remote system. The CHAP, PAP and SSH login systems all
define the local machine (the one trying to log in) as being the one
having the private part of a public/private keypair, with both systems
having the public part, and therefore assume that the local system is
the server that will authenticate a message sent by the remote client to
verify that the server is the correct system and user. Only the text
login assumes the opposite.

> Anybody who believes in having the client remote and the server
> local should be shipped off to whereever the server is ;)

>From their point of view, they already are where the server is, so no
shipping is necessary.

Best wishes from Riley.

Re: [patch] netconsole-2.4.10-B1

[Glynn Clements]

Rik van Riel wrote:

> > > sorry :-) definitions of netconsole-terms:
> > >
> > > 'server': the host that is the source of the messages. Ie. the box that
> > >           runs the netconsole.o module. It serves log messages to the
> > >           client.
> > >
> > > 'client': the host that receives the messages. This box is running the
> > >           netconsole-client.c program.
> >
> > Servers is usually the thing waiting for something to be sent to it,
> > the client is the sending part(initiator). this works for web servers
> > , X servers, log servers but strangley not for netconsole where
> > everything is backwards.
> 
> Owww crap.  The majority of web traffic is _from_ the
> server _to_ the client. Same for ftp, realaudio, etc...

... whereas with SMTP, syslog, printer (lpd) etc, it's the other way
around. Some servers are primarily "sources", while others are
primarily "sinks". Sources are more common, and most users are
probably more familiar with sources than sinks.

> In fact, usually the server is the _remote_ machine and
> the client is the _local_ machine.

But not for for X, NAS, ident ...

Local is a relative term. Presumably you meant local relative to a
user.

There are all kinds of generalisations one could make about individual
protocols, none of which are ultimately relevant to the client/server
distinction.

As Ingo points out, although it could have been more clear, the actual
distinction between client and server is that the client initiates the
communication, while the server responds (cf "originate" and "answer"
in telephone terminology).

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: [patch] netconsole-2.4.10-B1

[Richard Gooch]

Rik van Riel writes:
> Owww crap.  The majority of web traffic is _from_ the
> server _to_ the client. Same for ftp, realaudio, etc...
> 
> In fact, usually the server is the _remote_ machine and
> the client is the _local_ machine. Anybody who believes
> in having the client remote and the server local should
> be shipped off to whereever the server is ;)

Let's see, with X, the server is local (at least, it's local to where
I've placed my ass) and the client is remote.

I usually think of "server" as the box that's running all the time,
providing a service to multiple clients. In this case, the netconsole
server should always be running, accepting log messages for
storage. The clients (which are transitory, otherwise netconsole
wouldn't be needed:-), initiate work for the server to do.

Face it, Ingo's use of "client" and "server" is contrary to accepted
usage. You can't finesse around it.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [patch] netconsole-2.4.10-B1

[Marcus Sundberg]

mingo@elte.hu (Ingo Molnar) writes:

> sorry :-) definitions of netconsole-terms:
> 
> 'server': the host that is the source of the messages. Ie. the box that
>           runs the netconsole.o module. It serves log messages to the
>           client.
> 
> 'client': the host that receives the messages. This box is running the
>           netconsole-client.c program.

Then I guess you consider Mozilla to be a http-server, as it serves
http-requests to http-clients like Apache? ;)

Well, in any case it's a great patch even though the terminology is
backwards.

//Marcus
-- 
---------------------------------+---------------------------------
         Marcus Sundberg         |      Phone: +46 707 452062
   Embedded Systems Consultant   |     Email: marcus@cendio.se
        Cendio Systems AB        |      http://www.cendio.com

Re: [patch] netconsole-2.4.10-B1

[Randy.Dunlap]

Ingo Molnar wrote:
> 
> sorry :-) definitions of netconsole-terms:
> 
> 'server': the host that is the source of the messages. Ie. the box that
>           runs the netconsole.o module. It serves log messages to the
>           client.
> 
> 'client': the host that receives the messages. This box is running the
>           netconsole-client.c program.
> 
> 'target': the host that gets the messages sent - ie. the client.
> 
> 'target IP address': the IP address of the 'target'.
> 
> 'target ethernet address': the local-net host or first-hop router that
>                            gets the netconsole UDP packets sent. Ie. it
>                            does not necesserily match the MAC address of
>                            the 'target'.
> 
> (i can see where the confusion comes from, 'syslog servers' are ones that
> receieve syslogs. It's a backwards term i think. 'netconsole servers' are
> the ones that produce the messages.)
> 
> does it make more sense now? :)

Thanks for the definitions.  I can work with them,
although I think that there's much room for improvement...

~Randy

Re: [patch] netconsole-2.4.10-B1

[Randy.Dunlap]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

"Randy.Dunlap" wrote:
> 
> Ingo Molnar wrote:
> >
> >
> > does it make more sense now? :)
> 
> Thanks for the definitions.  I can work with them,
> although I think that there's much room for improvement...


and I did.  Eliminating typos on 'insmod netconsole.o ...' helps.  :)

Here's 3c59x.c patched for netconsole (HAVE_POLL_CONTROLLER).

Ingo, you _are_ planning to use most or all of Andreas's patches,
aren't you?

I'm interested in using netconsole early (during boot).
Any problems doing that, other than getting module parameters
to it?  I can fix that part.

~Randy

[-- Attachment #2: 3c59x-poll.patch --]
[-- Type: text/plain, Size: 1498 bytes --]

--- linux/drivers/net/3c59x.c.org	Sun Aug 12 12:27:18 2001
+++ linux/drivers/net/3c59x.c	Sun Sep 30 12:37:39 2001
@@ -842,6 +842,7 @@
 static int vortex_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
 static void vortex_tx_timeout(struct net_device *dev);
 static void acpi_set_WOL(struct net_device *dev);
+static void vorboom_poll(struct net_device *dev);
 \f
 /* This driver uses 'options' to pass the media type, full-duplex flag, etc. */
 /* Option count limit only -- unlimited interfaces are supported. */
@@ -1328,6 +1329,9 @@
 	dev->set_multicast_list = set_rx_mode;
 	dev->tx_timeout = vortex_tx_timeout;
 	dev->watchdog_timeo = (watchdog * HZ) / 1000;
+#ifdef HAVE_POLL_CONTROLLER
+	dev->poll_controller = &vorboom_poll;
+#endif
 	if (pdev && vp->enable_wol) {
 		vp->pm_state_valid = 1;
  		pci_save_state(vp->pdev, vp->power_state);
@@ -2295,6 +2299,29 @@
 handler_exit:
 	spin_unlock(&vp->lock);
 }
+
+#ifdef HAVE_POLL_CONTROLLER
+
+/*
+ * Polling 'interrupt' - used by things like netconsole to send skbs
+ * without having to re-enable interrupts. It's not called while
+ * the interrupt routine is executing.
+ */
+
+static void vorboom_poll (struct net_device *dev)
+{
+	struct vortex_private *vp = (struct vortex_private *)dev->priv;
+
+	disable_irq(dev->irq);
+	if (vp->full_bus_master_tx)
+		boomerang_interrupt(dev->irq, dev, 0);
+	else
+		vortex_interrupt(dev->irq, dev, 0);
+	enable_irq(dev->irq);
+}
+
+#endif
+
 
 static int vortex_rx(struct net_device *dev)
 {

Re: [patch] netconsole-2.4.10-B1

[H. Peter Anvin]

Followup to:  <3BB693AC.6E2DB9F4@canit.se>
By author:    Kenneth Johansson <ken@canit.se>
In newsgroup: linux.dev.kernel
>
> Ingo Molnar wrote:
> 
> > sorry :-) definitions of netconsole-terms:
> >
> > 'server': the host that is the source of the messages. Ie. the box that
> >           runs the netconsole.o module. It serves log messages to the
> >           client.
> >
> > 'client': the host that receives the messages. This box is running the
> >           netconsole-client.c program.
> >

This is backwards, sorry.  The host being logged is a client, the host
doing the logging is a server.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: [patch] netconsole-2.4.10-B1

[Andreas Dilger]

On Sep 30, 2001  13:25 -0700, Randy.Dunlap wrote:
> I'm interested in using netconsole early (during boot).
> Any problems doing that, other than getting module parameters
> to it?  I can fix that part.

I was thinking about this as well.  It should be relatively easy to allow
a line line "console=eth0,XX:XX:XX:XX:XX:XX,a.b.c.d" or similar.  The only
slight problem might be in configuring the interface early enough in the
boot process.  AFAIK (which isn't much in this area) the serial console
has special "console" code which allows it to be used very early in the
boot process.

You would obviously need to have the network driver compiled into the kernel
and not a module.  Maybe Ingo can hack something where it is possible
to initialize the network code very early in the boot process?

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [patch] netconsole-2.4.10-B1

[Ingo Molnar]

On Sun, 30 Sep 2001, Richard Gooch wrote:

> I usually think of "server" as the box that's running all the time,
> providing a service to multiple clients. In this case, the netconsole
> server should always be running, accepting log messages for storage.
> The clients (which are transitory, otherwise netconsole wouldn't be
> needed:-), initiate work for the server to do.
>
> Face it, Ingo's use of "client" and "server" is contrary to accepted
> usage. You can't finesse around it.

'server' is the box that serves content. 'client' is one that requests and
accepts it. in the case of netconsole, it's the netconsole-module box that
produces the messages, and the other one gets them.

it's analogous to a browser <-> http server relationship. The browser gets
messages from multiple servers - often in parallel. That is a 1:N
relationship as well.

the fact that the netconsole-module box did not get any formal 'request'
from the other side does not mean it's not the content generator: right
now the 'request' is implicit, but in the future it might be formalized.
The netconsole patch will soon be extended to do crashdumps - and in this
case it will not only be a log message server, it will also be a crashdump
server.

to further underscore why the netconsole-module box is a 'log message
server', it can produce messages to multiple 'clients'. (this is already
possible by renaming the netconsole module's symbols and inserting it as
eg. netconsole2.o.)

but in the case of logging there is indeed another way to think about it
as well: the netconsole-module box is asking the other side to store logs.
But in internet terms it's usually the content producer that is the
server, and the content sink that is the client. And i've been coding HTTP
and FTP server software lately which influenced my terminology :)

in this sense a browser is a 'server' too => the http server requests the
served page to be stored on the client.

but telling any side to be wrong is stupid - both are correct, and the
correct meaning of 'server' depends alot on context. this is why i defined
the terms.

	Ingo

Re: [patch] netconsole-2.4.10-B1

[Ingo Molnar]

On 30 Sep 2001, Marcus Sundberg wrote:

> > sorry :-) definitions of netconsole-terms:
> >
> > 'server': the host that is the source of the messages. Ie. the box that
> >           runs the netconsole.o module. It serves log messages to the
> >           client.
> >
> > 'client': the host that receives the messages. This box is running the
> >           netconsole-client.c program.
>
> Then I guess you consider Mozilla to be a http-server, as it serves
> http-requests to http-clients like Apache? ;)

no. Mozilla is a http-client, it sends requests to the Apache http-server
and it receives content produced by the server.

the netconsole-module box is a log-server that sends messages to the
log-client, which log content is produced by the netconsole-module box.
(right now it gets not requests from the client, but it will so in the
future.)

(and yes, occasionally Mozilla is the content server, think cookies ...)

	Ingo

Re: [patch] netconsole-2.4.10-B1

[Henning P. Schmiedehausen]

Rik van Riel <riel@conectiva.com.br> writes:

>Owww crap.  The majority of web traffic is _from_ the
>server _to_ the client. Same for ftp, realaudio, etc...

Did you mean:

Server is the data source.
Client is the data sink.

netconsole.o is the server (data source)
netconsole listener is the client (data sink)

Or did you mean:

Server is the part that offers a service
Client is the part that uses the service

netconsole listener offers the "receive console messages" service -> server
netconsole.o uses the "receive console message" service -> client

So both definitions are right/wrong. Choose any you like. Just
document it and stick to it. =:-) 

I am happy to have a network console no matter what is the client and
what is the server.

I personally, would say, that if you have a "one - many" network
relation, then the "one" part is the server. So in this case, the
netconsole listener would be the server and the netconsole.o the
client(s). Which is like syslog and so conforms to the "principle of
least surprise". :-)

Or can you have multiple listeners to a single netconsole.o instance?

	Regards
		Henning

OT: "Client/Server computing is like teenage sex. Everyone talks about
it, almost nobody really does it and those who do, don't get it right
most of the time". :-)

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: [patch] netconsole-2.4.10-B1

[Oliver Xymoron]

On Mon, 1 Oct 2001, Ingo Molnar wrote:

> > Face it, Ingo's use of "client" and "server" is contrary to accepted
> > usage. You can't finesse around it.
>
> 'server' is the box that serves content. 'client' is one that requests and
> accepts it. in the case of netconsole, it's the netconsole-module box that
> produces the messages, and the other one gets them.

Server is the side providing the service - direction of data is
irrelevant. If the service is logging, the side doing the logging is the
server. If the service is console message generation, then the machine
generating the messages is the server.  Client/server architecture
generally implies the possibility of multiple clients per server, and that
seems to make more sense with a 'logging server' than a 'console message
server'.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: [patch] netconsole-2.4.10-B1

[Andreas Dilger]

On Oct 01, 2001  08:47 +0000, Henning P. Schmiedehausen wrote:
> netconsole listener offers the "receive console messages" service -> server
> netconsole.o uses the "receive console message" service -> client
> 
> So both definitions are right/wrong. Choose any you like. Just
> document it and stick to it. =:-) 

It is ironic that the most popular thread about netconsole is a foolish
semantic argument, instead of a steady stream of patches for the various
network cards.

> I am happy to have a network console no matter what is the client and
> what is the server.

I agree.  I was actually thinking just now that I would "enhance" the
netconsole-server script so that:

1) it can start both the client and the server (I will just call it
   "netconsole", and use a config file to get the settings).  Maybe
   options like "--send" and "--receive" are unambiguous enough?
2) we don't need to specify the IP address of the local host for the
   "client" (possibly enhancing the client to listen on all configured
   interfaces by default.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [patch] netconsole-2.4.10-B1

[Richard Gooch]

Ingo Molnar writes:
[Much rationalising deleted:-]
> but telling any side to be wrong is stupid - both are correct, and
> the correct meaning of 'server' depends alot on context. this is why
> i defined the terms.

Hey! I didn't call anyone stupid. I didn't even call the idea
stupid. I think your terminology is backwards to the way I think and
what seems to be accepted practice (and I notice I'm not alone in
that).

However, "he who writes the code gets to choose", and I'd be a
hypocrite to say otherwise :-) I was just hoping to change your mind.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [patch] netconsole-2.4.10-B1

[Randy.Dunlap]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

Andreas Dilger wrote:
> 
> A few minor changes to the code, after testing it a bit locally (note that I
> am using kernel patch C1):
> 
> First, a patch to change the MAC address kernel parameter to be in the
> standard XX:XX:XX:XX:XX:XX form, instead of separate bytes.  It also
> fixes the output of the IP addresses to be unsigned ints.  Isn't there
> a function in the kernel to format IP addresses for output already?

Not quite for formatting, but NIPQUAD(ipaddr) passes 4 octets of IP
address to <anywhere>.

Here's a patch/replacement for the IP address printing in the
netconsole
kernel module, using NIPQUAD().  Against netconsole version C2.

BTW, in linux/include/linux/kernel.h, isn't HIPQUAD() totally useless
(and also unused)?  It looks very little-endian-specific.
Well, it can be used on little-endian systems if the ipaddr is
in host-order.

~Randy

[-- Attachment #2: netcon-ipaddr.patch --]
[-- Type: text/plain, Size: 1290 bytes --]

--- linux/drivers/net/netconsole.c.save	Mon Oct  1 07:43:31 2001
+++ linux/drivers/net/netconsole.c	Mon Oct  1 09:28:57 2001
@@ -263,25 +263,20 @@
 		printk(KERN_ERR "netconsole: network device %s is not an IP protocol device, aborting.\n", dev);
 		return -1;
 	}
-	source_ip = ntohl(in_dev->ifa_list->ifa_local);
+	source_ip = in_dev->ifa_list->ifa_local;
 	if (!source_ip) {
 		printk(KERN_ERR "netconsole: network device %s has no local address, aborting.\n", dev);
 		return -1;
 	}
-#define IP(x) ((char *)&source_ip)[x]
-	printk(KERN_INFO "netconsole: using source IP %i.%i.%i.%i\n",
-		IP(3), IP(2), IP(1), IP(0));
-#undef IP
-	source_ip = htonl(source_ip);
+	printk(KERN_INFO "netconsole: using source IP %u.%u.%u.%u\n", NIPQUAD(source_ip));
+
+	target_ip = htonl(target_ip);
 	if (!target_ip) {
 		printk(KERN_ERR "netconsole: target_ip parameter not specified, aborting.\n");
 		return -1;
 	}
-#define IP(x) ((char *)&target_ip)[x]
-	printk(KERN_INFO "netconsole: using target IP %i.%i.%i.%i\n",
-		IP(3), IP(2), IP(1), IP(0));
-#undef IP
-	target_ip = htonl(target_ip);
+	printk(KERN_INFO "netconsole: using target IP %u.%u.%u.%u\n", NIPQUAD(target_ip));
+
 	if (!source_port) {
 		printk(KERN_ERR "netconsole: source_port parameter not specified, aborting.\n");
 		return -1;

Re: [patch] netconsole-2.4.10-C2

[Randy.Dunlap]

Andreas Dilger wrote:
> 
> On Sep 30, 2001  13:25 -0700, Randy.Dunlap wrote:
> > I'm interested in using netconsole early (during boot).
> > Any problems doing that, other than getting module parameters
> > to it?  I can fix that part.
> 
> I was thinking about this as well.  It should be relatively easy to allow
> a line line "console=eth0,XX:XX:XX:XX:XX:XX,a.b.c.d" or similar.  The only
> slight problem might be in configuring the interface early enough in the
> boot process.  AFAIK (which isn't much in this area) the serial console
> has special "console" code which allows it to be used very early in the
> boot process.
> 
> You would obviously need to have the network driver compiled into the kernel
> and not a module.  Maybe Ingo can hack something where it is possible
> to initialize the network code very early in the boot process?

Well, I have netconsole-in-kernel (+ AD patches + RD patches)
built and parsing parameters, but not getting active nearly
soon enough.
I'll continue to work on that...hints appreciated/accepted.

~Randy