[PATCH] ipt_LOG split MAC

[PATCH] ipt_LOG split MAC

[Danny Rathjens]

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

Is a patch like this sensible?
with the log messages currently looking like:
  IN=eth0 OUT= MAC=00:c0:49:5f:9a:0d:00:00:c5:66:00:28:08:00 SRC=72.234.128.92 DST=72.1.142.189  ...
it's hard to tell what the source or destination MAC address is.

I just split the MAC header in half, but now that I am reading more about
variable length MAC addresses I don't think that is the right way to do it.

Just spitting out the raw header seems pretty efficient, too.  Perhaps that
is by design for efficienecy as opposed to laziness? :)

[-- Attachment #2: ipt_LOG-split-MAC.patch --]
[-- Type: text/x-patch, Size: 740 bytes --]

--- net/ipv4/netfilter/ipt_LOG.c	2006-09-07 20:04:02.000000000 -0400
+++ net/ipv4/netfilter/ipt_LOG.c	2006-09-07 20:04:20.000000000 -0400
@@ -392,15 +392,19 @@
 
 	if (in && !out) {
 		/* MAC logging for input chain only. */
-		printk("MAC=");
 		if (skb->dev && skb->dev->hard_header_len
 		    && skb->mac.raw != (void*)skb->nh.iph) {
 			int i;
 			unsigned char *p = skb->mac.raw;
-			for (i = 0; i < skb->dev->hard_header_len; i++,p++)
+			for (i = 0; i < skb->dev->hard_header_len; i++,p++) {
+				if i == 0
+					printk("DSTMAC=");
+				if i == skb->dev->hard_header_len / 2
+					printk(" SRCMAC=");
 				printk("%02x%c", *p,
 				       i==skb->dev->hard_header_len - 1
 				       ? ' ':':');
+			}
 		} else
 			printk(" ");
 	}

Re: [PATCH] ipt_LOG split MAC

[Patrick McHardy]

Danny Rathjens wrote:
> Is a patch like this sensible?
> with the log messages currently looking like:
>  IN=eth0 OUT= MAC=00:c0:49:5f:9a:0d:00:00:c5:66:00:28:08:00
> SRC=72.234.128.92 DST=72.1.142.189  ...
> it's hard to tell what the source or destination MAC address is.
> 
> I just split the MAC header in half, but now that I am reading more about
> variable length MAC addresses I don't think that is the right way to do it.
> 
> Just spitting out the raw header seems pretty efficient, too.  Perhaps that
> is by design for efficienecy as opposed to laziness? :)

I don't think so :) We can't change it however since that would most
likely break lots of existing log file parsers.