Re: skb_checksum_help

Re: skb_checksum_help

[Thomas Graf]

* David Coulson <41F432BD.3000300@davidcoulson.net> 2005-01-23 18:26
> I got this out of one of my boxes today - I'm not 100% sure what the 
> output is prior to the TSC error, but I figure they're probably 
> associated. I forgot to compile in CONFIG_RTC on this box (It's SMP 
> using a HT P4 CPU), so I'll stick a fresh kernel on it.
> 
> Anyway, hope the hex output makes sense to you :-)

I CC'ed netdev, this seems more serious than I thought.

Background: David noticed the assertion csum + 2 > offset being trigged
in skb_checksum_help. I sent him a patch converting it into a warning
printing offset, len, n.raw, tail, csum, features and the whole packet
as hexdump. He uses the acenic driver which is actually capable of doing
IP checksumming. (Patch enclosed at the end)

> <4>Losing too many ticks!
> TSC cannot be used as a timesource.
> Possible reasons for this are:
>   You're running with Speedstep,
>   You don't have DMA enabled for your hard disk (see hdparm),
>   Incorrect TSC synchronization on an SMP system (see dmesg).
> Falling back to a sane timesource now.

Not related.

> offset=345 len=379 n=e859c024 tail=e859c17d csum=0xf69c
> features: 0

features == 0, this looks very wrong, also explains why it
actually tries to do software checksumming even if your
card can do it in hardware.

> skb hdr corrupted!

not good, this explains why the checksum is wrong. skb->h.raw
is < skb->data.

Let's enable the brain network parser for your hex dumps.

> 00 d0 b7 a6 ba e3 00 02 e3 00 09 31 08 00

Ethernet header:
  From: 00:d0:b7:a6:ba:e3
  To:   00:02:e3:00:09:31
  Protocol: 0x0800 (IP)

> 45 00 01 6d b9 8d 00 b9 31 11 7b 08 d3 20 75 0b 0a 01 01 05

Version: 4
IHL: 5
DSCP: 00
Length: 365 bytes, so len=379 above is correct (365+14 ether)
ID: 0xb98d
Flags: 0
Fragment Offset: 185
TTL: 49 [0]
Protocol: 17 (UDP)
Checksum: 0x7b08
Source: 211.32.117.11 (korean ip)
Destination: 10.1.1.5

[0] The originator of this packet is likely a BSD based
UNIX box. It is unlikely that it dropped to 49 from 128
which I think is the base TTL windows uses. Only guessing
though.

The payload doesn't look special at a first glance
but align it correctly and you'll get:

> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 6c c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 6d c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 68 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 29 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 0a c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 45 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 50 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 88 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 84 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 92 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 9c c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 b6 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 b7 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 b8 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 b9 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 ba c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 7f c0 90
> 00 01 00 01 00 01 51 80 00 04 de e7 23 15 c0 90
> 00 01 00 01 00 01 51 80 00 04 de e7 23 17 c0 f2
> 00 01 00 01 00 01 51 80 00 04 d3 20 75 0a c1 08
> 00 01 00 01 00 01 51 80 00 04 d3 20 75 0b 00 00
> 29 10 00 00 00 00 00 00 00

It _could_ be nothing but still looks very suspicous.

Next fragment:

[ Same ethernet header ]
[ Same IP header except: ]

Length: 477
ID: 0xb525
Flags: 0
Fragment Offset: 185
Checksum: 0x7f01
Source: 211.32.117.12
Destination: 10.1.1.5

Same source incremented by 1.

> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 b6 c0 7c
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 b7 c0 7c
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 b8 c0 7c
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 b9 c0 7c
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 ba c0 7c
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 7f c0 7c
> 00 01 00 01 00 01 51 80 00 04 de e7 23 15 c0 7c
> 00 01 00 01 00 01 51 80 00 04 de e7 23 17 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 6e c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 2a c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 0b c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 46 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 47 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 48 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 51 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 89 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 93 c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 9d c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 bb c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 bc c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 bd c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 be c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 bf c0 90
> 00 01 00 01 00 01 51 80 00 04 d3 2b c5 80 c0 90
> 00 01 00 01 00 01 51 80 00 04 de e7 23 18 c0 90
> 00 01 00 01 00 01 51 80 00 04 de e7 23 19 c0 f2
> 00 01 00 01 00 01 51 80 00 04 d3 20 75 0a c1 08
> 00 01 00 01 00 01 51 80 00 04 d3 20 75 0b 00 00
> 29 10 00 00 00 00 00 00 00

Very similiar again.

Next fragment:

Length: 477
ID: 0xb525
Flags: 0
Fragment Offset: 185
Checksum: 0x7f01
Source: 211.32.117.11
Destination: 10.1.15

Back to the first IP, same payload as first packet.

Without further inspection I'd guess this is just junk traffic of some
stupid tool trying to screw up ip stacks and it seems to be quite
sucessful. I'll try to investigate some more later on, there must be
some serious memory corruption happening.

--- linux-2.6.10-bk14.orig/net/core/dev.c	2005-01-13 10:56:33.000000000 +0100
+++ linux-2.6.10-bk14/net/core/dev.c	2005-01-15 23:38:03.000000000 +0100
@@ -1096,8 +1096,27 @@
 	offset = skb->tail - skb->h.raw;
 	if (offset <= 0)
 		BUG();
-	if (skb->csum + 2 > offset)
-		BUG();
+	if (skb->csum + 2 > offset) {
+		int l = 0;
+		u8 *p;
+
+		if (!skb_shinfo(skb)->nr_frags) {
+			for (p = skb->data; p < skb->tail; p++) {
+				printk("%02x ", *p);
+				if (++l == 20) {
+					printk("\n");
+					l = 0;
+				}
+			}
+		} else
+			printk("paged skb, not printing\n");
+		printk(KERN_CRIT "offset=%d len=%d n=%p tail=%p csum=0x%x\n",
+		    offset, skb->len, skb->h.raw, skb->tail, skb->csum);
+		printk(KERN_CRIT "features: %x\n", skb->dev->features);
+		if (skb->h.raw < skb->data || skb->h.raw > skb->data)
+			printk(KERN_CRIT "skb hdr corrupted!\n");
+		goto out;
+	}
 
 	*(u16*)(skb->h.raw + skb->csum) = csum_fold(csum);
 	skb->ip_summed = CHECKSUM_NONE;

Re: skb_checksum_help

[Patrick McHardy]

Thomas Graf wrote:

>I CC'ed netdev, this seems more serious than I thought.
>
>Background: David noticed the assertion csum + 2 > offset being trigged
>in skb_checksum_help. I sent him a patch converting it into a warning
>printing offset, len, n.raw, tail, csum, features and the whole packet
>as hexdump. He uses the acenic driver which is actually capable of doing
>IP checksumming. (Patch enclosed at the end)
>
How does the backtrace look ?

>>skb hdr corrupted!
>>
>
The check looks bogus:

>+		if (skb->h.raw < skb->data || skb->h.raw > skb->data)
>+			printk(KERN_CRIT "skb hdr corrupted!\n");
>+		goto out;
>+	}
>
Regards
Patrick

Re: skb_checksum_help

[Thomas Graf]

* Patrick McHardy <41F44605.6050001@trash.net> 2005-01-24 01:49
> Thomas Graf wrote:
> 
> >I CC'ed netdev, this seems more serious than I thought.
> >
> >Background: David noticed the assertion csum + 2 > offset being trigged
> >in skb_checksum_help. I sent him a patch converting it into a warning
> >printing offset, len, n.raw, tail, csum, features and the whole packet
> >as hexdump. He uses the acenic driver which is actually capable of doing
> >IP checksumming. (Patch enclosed at the end)
> >
> How does the backtrace look ?

It's a normal forwarded packet as it seems. ipq_kill doesn't show
up in other occurances of this bug.

kernel BUG at net/core/dev.c:1100!
invalid operand: 0000 [#1]
SMP
CPU:    0
EIP:    0060:[<c02b78dc>]    Not tainted VLI
EFLAGS: 00010216   (2.6.10)
EIP is at skb_checksum_help+0x9c/0xf0
eax: 00009ec4   ebx: 000001ce   ecx: 00009ec2   edx: adc3f0fe
esi: f6b58b80   edi: f693d824   ebp: 00000000   esp: c04c3c84
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c04c2000 task=c0410b40)
Stack: adc3f0fe f6b58b80 f7034000 00000000 fffffff4 c02b7c86 000073a6 
02e0f250
        00000282 f6de9ea4 f6b58b80 f6de9e80 0000000e c02bd354 f6de9ea8 
00000000
        000001e2 c02e5697 f589b680 f693d800 f693d824 f6b58b80 c02ea0de 
00000000
Call Trace:
  [<c02b7c86>] dev_queue_xmit+0x246/0x290
  [<c02bd354>] neigh_resolve_output+0xc4/0x1b0
  [<c02e5697>] ipq_kill+0x67/0x80
  [<c02ea0de>] ip_finish_output2+0xce/0x1a0
  [<c02e8998>] ip_fragment+0x638/0x750
  [<c02ea010>] ip_finish_output2+0x0/0x1a0
  [<c02ea010>] ip_finish_output2+0x0/0x1a0
  [<c031a70f>] ip_refrag+0x6f/0x80
  [<c02ea010>] ip_finish_output2+0x0/0x1a0
  [<c02c1592>] nf_iterate+0x72/0xb0
  [<c02ea010>] ip_finish_output2+0x0/0x1a0
  [<c02ea010>] ip_finish_output2+0x0/0x1a0
  [<c02c1898>] nf_hook_slow+0x68/0xf0
  [<c02ea010>] ip_finish_output2+0x0/0x1a0
  [<c02ea010>] ip_finish_output2+0x0/0x1a0
  [<c02e7ba1>] ip_finish_output+0x1e1/0x1f0
  [<c02ea010>] ip_finish_output2+0x0/0x1a0
  [<c02e8998>] ip_fragment+0x638/0x750
  [<c0322c28>] ipt_hook+0x28/0x30
  [<c02c1592>] nf_iterate+0x72/0xb0
  [<c02e79c0>] ip_finish_output+0x0/0x1f0
  [<c02e65d0>] ip_forward_finish+0x0/0x50
  [<c02e65f9>] ip_forward_finish+0x29/0x50
  [<c02c18e2>] nf_hook_slow+0xb2/0xf0
  [<c02e65d0>] ip_forward_finish+0x0/0x50
  [<c02e650c>] ip_forward+0x1bc/0x280
  [<c02e65d0>] ip_forward_finish+0x0/0x50
  [<c02e5378>] ip_rcv_finish+0x1f8/0x270
  [<c02c1592>] nf_iterate+0x72/0xb0
  [<c02e5180>] ip_rcv_finish+0x0/0x270
  [<c02e5180>] ip_rcv_finish+0x0/0x270
  [<c02c18e2>] nf_hook_slow+0xb2/0xf0
  [<c02e5180>] ip_rcv_finish+0x0/0x270
  [<c02e4eec>] ip_rcv+0x3ec/0x4b0
  [<c02e5180>] ip_rcv_finish+0x0/0x270
  [<c0241e09>] ace_rx_int+0x2f9/0x3d0
  [<c02b837a>] netif_receive_skb+0x20a/0x2b0
  [<c02b84a6>] process_backlog+0x86/0x120
  [<c02b85bf>] net_rx_action+0x7f/0x110
  [<c011c5d6>] __do_softirq+0xb6/0xd0
  [<c011c61d>] do_softirq+0x2d/0x30
  [<c010474e>] do_IRQ+0x1e/0x30
  [<c0102ef2>] common_interrupt+0x1a/0x20
  [<c01006f0>] default_idle+0x0/0x40
  [<c0100719>] default_idle+0x29/0x40
  [<c01007ab>] cpu_idle+0x3b/0x50
  [<c04c48ab>] start_kernel+0x13b/0x160
  [<c04c4350>] unknown_bootoption+0x0/0x1c0
Code: 24 00 00 00 00 29 d9 89 da 89 f0 e8 df bb ff ff 8b 9e b0 00 00 00 
89 c2 8b 7e 24 29 fb 85 db 7e 4e 8b 4e 6c 8d 41 02 39 d8 76 08 <0f> 0b 
4c 04 73 ad 3f c0 89 d0 c1 e0 10 81 e2 00 00 ff ff 01 c2
  <0>Kernel panic - not syncing: Fatal exception in interrupt

> The check looks bogus:
> 
> >+		if (skb->h.raw < skb->data || skb->h.raw > skb->data)
> >+			printk(KERN_CRIT "skb hdr corrupted!\n");

Right, my fault, should have been skb->tail in the second check.

Re: skb_checksum_help

[David Coulson]

Thomas Graf wrote:

> Protocol: 17 (UDP)
> Checksum: 0x7b08
> Source: 211.32.117.11 (korean ip)
> Destination: 10.1.1.5
> 
> [0] The originator of this packet is likely a BSD based
> UNIX box. It is unlikely that it dropped to 49 from 128
> which I think is the base TTL windows uses. Only guessing
> though.

Looks like a DNS packet. AFAIK, 53 is the only UDP port I NAT through 
from the outside to 10.1.1.5. No idea if that really matters or not, 
with respect to the contents of the IP packet.

David

-- 
David J. Coulson
email: david@davidcoulson.net
web: http://www.davidcoulson.net/
phone: (216) 920-3100 / (216) 258-4942

Re: skb_checksum_help

[Herbert Xu]

Thomas Graf <tgraf@suug.ch> wrote:
>
> Call Trace:
>  [<c02b7c86>] dev_queue_xmit+0x246/0x290
...
>  [<c02e79c0>] ip_finish_output+0x0/0x1f0
>  [<c02e65d0>] ip_forward_finish+0x0/0x50

Something is screwed up here.  If the packet really went
through forwarding, then skb->ip_summed should be CHECKSUM_NONE.
This is done as the first thing in ip_forward().

So if you're seeing CHECKSUM_HW at the end of the pipe,
then somebody must've changed it.  CHECKSUM_HW should
only be seen in dev_queue_xmit for locally generated
traffic.

I suggest that you print out the value of skb->ip_summed
at various points in and after ip_forward() to find out
who is changing skb->ip_summed.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: skb_checksum_help

[David S. Miller]

On Mon, 24 Jan 2005 12:31:34 +1100
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> Something is screwed up here.  If the packet really went
> through forwarding, then skb->ip_summed should be CHECKSUM_NONE.
> This is done as the first thing in ip_forward().
> 
> So if you're seeing CHECKSUM_HW at the end of the pipe,
> then somebody must've changed it.  CHECKSUM_HW should
> only be seen in dev_queue_xmit for locally generated
> traffic.

Yes.  This backtrace is very strange.  Let me take this
chance to get on my podium and re-express my distaste
for x86's inaccurate backtraces.  They make debugging so
difficult.  It's time for some dwarf2 unwind table support
the kernel x86 backtracer and a way to enable it during the
build.

My current guess is that this is some successful exploit
of some as-yet-unknown issue in netfilter's fragmentation
handling.  But that's just a guess.  If some code underruns
skb->data somehow while unfragging/refragging, that's a sure
fire way to corrupt things such as the skb->ip_summed field.

All the theoretical attack has to do is find some way to
copy a "1" into the byte at skb->ip_summed, as that's the
value of CHECKSUM_HW.

It would be nice to just log a full tcpdump trace for that
UDP port on the incoming interface on that machine.  This
will allow us to see the exact traffic pattern.

Re: skb_checksum_help

[David S. Miller]

On Sun, 23 Jan 2005 20:27:15 -0800
"David S. Miller" <davem@davemloft.net> wrote:

> If some code underruns
> skb->data somehow while unfragging/refragging, that's a sure
> fire way to corrupt things such as the skb->ip_summed field.

Ignore this, I'm wrong.  We allocate sk_buff and skb->data
seperately, so this can't happen.

I'm really showing my age, because many moons ago we did
allocate them together :-)

Re: skb_checksum_help

[Patrick McHardy]

David S. Miller wrote:

>Yes.  This backtrace is very strange.  Let me take this
>chance to get on my podium and re-express my distaste
>for x86's inaccurate backtraces.  They make debugging so
>difficult.  It's time for some dwarf2 unwind table support
>the kernel x86 backtracer and a way to enable it during the
>build.
>
>My current guess is that this is some successful exploit
>of some as-yet-unknown issue in netfilter's fragmentation
>handling.  But that's just a guess.  If some code underruns
>skb->data somehow while unfragging/refragging, that's a sure
>fire way to corrupt things such as the skb->ip_summed field.
>
That's what I suspect too. There is still the possibility of skbs
"jumping" through the stack between ip_defrag callers, the same
problem that caused the crashes on conntrack module unload fixed
by Olaf Kirch some time ago. This could theoretically cause skbs
from PRE_ROUTING to show up in POST_ROUTING and continue from
there on if NAT is used. Perhaps we should add a "user"-argument
to ip_defrag and keep fragment queues private to a single user.

Regards
Patrick

Re: skb_checksum_help

[Herbert Xu]

On Sun, Jan 23, 2005 at 08:27:15PM -0800, David S. Miller wrote:
> 
> My current guess is that this is some successful exploit
> of some as-yet-unknown issue in netfilter's fragmentation
> handling.  But that's just a guess.  If some code underruns
> skb->data somehow while unfragging/refragging, that's a sure
> fire way to corrupt things such as the skb->ip_summed field.

Another possibility is some bogus netfilter module that the
reporter is using.  His backtrace was showing an ipq_kill which
isn't in the main tree.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: skb_checksum_help

[Patrick McHardy]

Herbert Xu wrote:

>Another possibility is some bogus netfilter module that the
>reporter is using.  His backtrace was showing an ipq_kill which
>isn't in the main tree.
>
I was fooled by the name too, ipq_kill doesn't belong to ip_queue but
to net/ipv4/ip_fragment.c.

Regards
Patrick

Re: skb_checksum_help

[Thomas Graf]

* David S. Miller <20050123202715.281ac87c.davem@davemloft.net> 2005-01-23 20:27
> My current guess is that this is some successful exploit
> of some as-yet-unknown issue in netfilter's fragmentation
> handling.  But that's just a guess.  If some code underruns
> skb->data somehow while unfragging/refragging, that's a sure
> fire way to corrupt things such as the skb->ip_summed field.
> 
> All the theoretical attack has to do is find some way to
> copy a "1" into the byte at skb->ip_summed, as that's the
> value of CHECKSUM_HW.

It's more than that, to make it work on all nics, features
must be modified as well and it seems to happen. Besides
of that, there must be more corruption to ensure the checksum
gets calculated wrong, right? So why would one corrupt 3
places when it could be done a lot easier.

What is suspicious in the packet? The payload does indeed make
sense for DNS. The equal fragment offset for the two fragments
originating from two different hosts can also be explained.

It _does_ look like a bug in the fragmentation code but I'm not
sure if it really is triggered by some exploit.

> It would be nice to just log a full tcpdump trace for that
> UDP port on the incoming interface on that machine.  This
> will allow us to see the exact traffic pattern.

Yes, this might clear things up.

David, can you do this? and fix my patch by changing

	if (skb->h.raw < skb->data || skb->h.raw > skb->data)
into:
	if (skb->h.raw < skb->data || skb->h.raw > skb->tail)

Re: skb_checksum_help

[Thomas Graf]

* Patrick McHardy <41F48293.9050301@trash.net> 2005-01-24 06:07
> Herbert Xu wrote:
> 
> >Another possibility is some bogus netfilter module that the
> >reporter is using.  His backtrace was showing an ipq_kill which
> >isn't in the main tree.
> >
> I was fooled by the name too, ipq_kill doesn't belong to ip_queue but
> to net/ipv4/ip_fragment.c.

I followed this one too because it is directly related to frag reasm
but it is a regular occurance called by a timer, here's a backtrace
without ipq_kill:

kernel BUG at net/core/dev.c:1103!
invalid operand: 0000 [#1]
SMP 
CPU:    0
EIP:    0060:[<c02bb4bd>]    Not tainted VLI
EFLAGS: 00010282   (2.6.10-ac8) 
EIP is at skb_checksum_help+0xcd/0x120
eax: 00000011   ebx: f665bb80   ecx: c04bfc84   edx: 00000296
esi: 0000011d   edi: 1e97231e   ebp: f4d76941   esp: c04bfc80
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c04be000 task=c040db40)
Stack: c03f84c8 00000008 00000000 f665bb80 f7e31c00 00000000 fffffff4 c02bb866 
       00000000 f691b520 00000286 f6ffe4a4 f665bb80 0000000e f6ffe480 c02c1095 
       f6ffe4a8 00000000 00000131 f4dc0b80 f4d76800 00000000 f665bb80 c02edb5e 
Call Trace:
 [<c02bb866>] dev_queue_xmit+0x246/0x290
 [<c02c1095>] neigh_connected_output+0x85/0xd0
 [<c02edb5e>] ip_finish_output2+0xce/0x1a0
 [<c02ec420>] ip_fragment+0x5e0/0x6f0
 [<c02eda90>] ip_finish_output2+0x0/0x1a0
 [<c02eda90>] ip_finish_output2+0x0/0x1a0
 [<c031e17f>] ip_refrag+0x6f/0x80
 [<c02eda90>] ip_finish_output2+0x0/0x1a0
 [<c02c5152>] nf_iterate+0x72/0xb0
 [<c02eda90>] ip_finish_output2+0x0/0x1a0
 [<c02eda90>] ip_finish_output2+0x0/0x1a0
 [<c02c53f8>] nf_hook_slow+0x68/0xf0
 [<c02eda90>] ip_finish_output2+0x0/0x1a0
 [<c02eda90>] ip_finish_output2+0x0/0x1a0
 [<c02eb6c1>] ip_finish_output+0x1e1/0x1f0
 [<c02eda90>] ip_finish_output2+0x0/0x1a0
 [<c02ec420>] ip_fragment+0x5e0/0x6f0
 [<c0326698>] ipt_hook+0x28/0x30
 [<c02c5152>] nf_iterate+0x72/0xb0
 [<c02eb4e0>] ip_finish_output+0x0/0x1f0
 [<c02ea0f0>] ip_forward_finish+0x0/0x50
 [<c02ea119>] ip_forward_finish+0x29/0x50
 [<c02c5442>] nf_hook_slow+0xb2/0xf0
 [<c02ea0f0>] ip_forward_finish+0x0/0x50
 [<c02ea02c>] ip_forward+0x1bc/0x280
 [<c02ea0f0>] ip_forward_finish+0x0/0x50
 [<c02e8e98>] ip_rcv_finish+0x1f8/0x270
 [<c02c5152>] nf_iterate+0x72/0xb0
 [<c02e8ca0>] ip_rcv_finish+0x0/0x270
 [<c02e8ca0>] ip_rcv_finish+0x0/0x270
 [<c02c5442>] nf_hook_slow+0xb2/0xf0
 [<c02e8ca0>] ip_rcv_finish+0x0/0x270
 [<c02e8a0c>] ip_rcv+0x3ec/0x4b0
 [<c02e8ca0>] ip_rcv_finish+0x0/0x270
 [<c02bbf5a>] netif_receive_skb+0x20a/0x2b0
 [<c02bc086>] process_backlog+0x86/0x120
 [<c02bc19f>] net_rx_action+0x7f/0x110
 [<c011c606>] __do_softirq+0xb6/0xd0
 [<c011c64d>] do_softirq+0x2d/0x30
 [<c010474e>] do_IRQ+0x1e/0x30
 [<c0102ef2>] common_interrupt+0x1a/0x20
 [<c01006f0>] default_idle+0x0/0x40
 [<c0100719>] default_idle+0x29/0x40
 [<c01007ab>] cpu_idle+0x3b/0x50
 [<c04c08ab>] start_kernel+0x13b/0x160
 [<c04c0350>] unknown_bootoption+0x0/0x1c0
Code: 83 a8 00 00 00 72 04 39 e8 76 0c c7 04 24 aa 84 3f c0 e8 47 cb e5 ff 0f b7 43 78 c7 04 24 c8 84 3f c0 89 44 24 04 e8 33 cb e5 ff <0f> 0b 4f 04 93 84 3f c0 8b 4b 24 8b 53 6c 89 f8 c1 e0 10 81 e7 
 <0>Kernel panic - not syncing: Fatal exception in interrupt

Re: skb_checksum_help

[Thomas Graf]

* David Coulson <41F44FD6.4000205@davidcoulson.net> 2005-01-23 20:31
> Thomas Graf wrote:
> 
> >Protocol: 17 (UDP)
> >Checksum: 0x7b08
> >Source: 211.32.117.11 (korean ip)
> >Destination: 10.1.1.5
> >
> >[0] The originator of this packet is likely a BSD based
> >UNIX box. It is unlikely that it dropped to 49 from 128
> >which I think is the base TTL windows uses. Only guessing
> >though.
> 
> Looks like a DNS packet. AFAIK, 53 is the only UDP port I NAT through 
> from the outside to 10.1.1.5. No idea if that really matters or not, 
> with respect to the contents of the IP packet.

Yes, this explains the repetive payload. Can you provide your complete
netfilter rule set?

Re: skb_checksum_help

[Patrick McHardy]

Thomas Graf wrote:

>I followed this one too because it is directly related to frag reasm
>but it is a regular occurance called by a timer, here's a backtrace
>without ipq_kill:
>
What about modules, .config, ... ?

Regards
Patrick

Re: skb_checksum_help

[David Coulson]

Thomas Graf wrote:

> Yes, this explains the repetive payload. Can you provide your complete
> netfilter rule set?


iptables-save + .config + /var/log/dmesg output (in that order)



# Generated by iptables-save v1.2.11 on Mon Jan 24 09:21:46 2005
*raw
:PREROUTING ACCEPT [57093101:15158285462]
:OUTPUT ACCEPT [12060512:2123455512]
COMMIT
# Completed on Mon Jan 24 09:21:46 2005
# Generated by iptables-save v1.2.11 on Mon Jan 24 09:21:46 2005
*nat
:PREROUTING ACCEPT [131677:9174978]
:POSTROUTING ACCEPT [4583564:374167230]
:OUTPUT ACCEPT [6380:559033]
:BOGONS - [0:0]
:INGRESS - [0:0]
-A PREROUTING -m mark --mark 0x16 -j ACCEPT
-A PREROUTING -m state --state RELATED,ESTABLISHED -j ACCEPT
-A PREROUTING -p icmp -m ttl --ttl-eq 1 -j ACCEPT
-A PREROUTING -p udp -m udp --dport 33434:33542 -m ttl --ttl-eq 1 -j ACCEPT
-A PREROUTING -d 207.166.198.0/255.255.255.224 -i vlan102 -p icmp -m ttl 
--ttl-eq 2 -j LOG
-A PREROUTING -d 207.166.198.0/255.255.255.224 -i vlan102 -p icmp -m ttl 
--ttl-eq 2 -j DNAT --to-destination 10.1.1.1
-A PREROUTING -d 207.166.193.157 -p icmp -j ACCEPT
-A PREROUTING -d 207.166.193.237 -p icmp -j ACCEPT
-A PREROUTING -d 207.166.193.238 -p icmp -j ACCEPT
-A PREROUTING -d 207.166.203.128/255.255.255.192 -p icmp -m ttl --ttl-eq 
2 -j DNAT --to-destination 10.1.1.1
-A PREROUTING -d 207.166.203.128/255.255.255.192 -p icmp -m ttl --ttl-gt 
2 -j DNAT --to-destination 10.1.1.1
-A PREROUTING -p udp -m udp --dport 33434:33542 -m ttl --ttl-eq 2 -j 
DNAT --to-destination 10.1.1.1
-A PREROUTING -i lo -j ACCEPT
-A PREROUTING -s 10.0.0.0/255.0.0.0 -d 10.0.0.0/255.0.0.0 -j ACCEPT
-A PREROUTING -s 10.0.0.0/255.0.0.0 -d 224.0.0.0/255.0.0.0 -j ACCEPT
-A PREROUTING -m state --state INVALID -j DROP
-A PREROUTING -i vlan102 -j BOGONS
-A PREROUTING -i vlan102 -j INGRESS
-A PREROUTING -d 207.166.198.0/255.255.255.224 -j ACCEPT
-A PREROUTING -d 207.166.203.176/255.255.255.240 -j ACCEPT
-A PREROUTING -d 207.166.218.128/255.255.255.224 -j ACCEPT
-A PREROUTING -d 207.166.193.157 -p udp -m udp --dport 500 -j ACCEPT
-A PREROUTING -d 207.166.193.237 -p udp -m udp --dport 500 -j ACCEPT
-A PREROUTING -d 207.166.193.238 -p udp -m udp --dport 500 -j ACCEPT
-A PREROUTING -d 207.166.193.157 -p udp -m udp --dport 4500 -j ACCEPT
-A PREROUTING -d 207.166.193.237 -p udp -m udp --dport 4500 -j ACCEPT
-A PREROUTING -d 207.166.193.238 -p udp -m udp --dport 4500 -j ACCEPT
-A PREROUTING -d 207.166.193.157 -p ah -j ACCEPT
-A PREROUTING -d 207.166.193.237 -p ah -j ACCEPT
-A PREROUTING -d 207.166.193.238 -p ah -j ACCEPT
-A PREROUTING -d 207.166.193.157 -p esp -j ACCEPT
-A PREROUTING -d 207.166.193.237 -p esp -j ACCEPT
-A PREROUTING -d 207.166.193.238 -p esp -j ACCEPT
-A PREROUTING -d 207.166.193.157 -p tcp -m tcp --dport 1723 -j DNAT 
--to-destination 10.1.1.1
-A PREROUTING -d 207.166.193.237 -p tcp -m tcp --dport 1723 -j DNAT 
--to-destination 10.1.1.2
-A PREROUTING -d 207.166.193.238 -p tcp -m tcp --dport 1723 -j DNAT 
--to-destination 10.1.1.3
-A PREROUTING -d 207.166.193.157 -p gre -j ACCEPT
-A PREROUTING -d 207.166.193.237 -p gre -j ACCEPT
-A PREROUTING -d 207.166.193.238 -p gre -j ACCEPT
-A PREROUTING -d 207.166.193.237 -p tcp -m tcp --dport 2525 -j DNAT 
--to-destination 10.1.1.3:25
-A PREROUTING -d 207.166.193.237 -p tcp -m tcp --dport 25 -j DNAT 
--to-destination 10.1.1.2
-A PREROUTING -d 207.166.193.237 -p tcp -m tcp --dport 53 -j DNAT 
--to-destination 10.1.1.2
-A PREROUTING -d 207.166.193.237 -p udp -m udp --dport 53 -j DNAT 
--to-destination 10.1.1.2
-A PREROUTING -d 207.166.193.238 -p tcp -m tcp --dport 25 -j DNAT 
--to-destination 10.1.1.3
-A PREROUTING -d 207.166.193.238 -p tcp -m tcp --dport 53 -j DNAT 
--to-destination 10.1.1.3
-A PREROUTING -d 207.166.193.238 -p udp -m udp --dport 53 -j DNAT 
--to-destination 10.1.1.3
-A PREROUTING -d 207.166.203.130 -p tcp -m tcp --dport 25 -j DNAT 
--to-destination 10.1.1.5
-A PREROUTING -d 207.166.203.130 -p tcp -m tcp --dport 80 -j DNAT 
--to-destination 10.1.1.5
-A PREROUTING -d 207.166.203.130 -p tcp -m tcp --dport 443 -j DNAT 
--to-destination 10.1.1.5
-A PREROUTING -d 207.166.203.130 -p tcp -m tcp --dport 993 -j DNAT 
--to-destination 10.1.1.5
-A PREROUTING -d 207.166.203.130 -p tcp -m tcp --dport 995 -j DNAT 
--to-destination 10.1.1.5
-A PREROUTING -d 207.166.203.131 -p tcp -m tcp --dport 53 -j DNAT 
--to-destination 10.1.1.5
-A PREROUTING -d 207.166.203.131 -p udp -m udp --dport 53 -j DNAT 
--to-destination 10.1.1.5
-A PREROUTING -d 207.166.203.131 -p tcp -m tcp --dport 80 -j DNAT 
--to-destination 10.1.1.5
-A PREROUTING -d 207.166.203.131 -p tcp -m tcp --dport 443 -j DNAT 
--to-destination 10.1.1.5
-A PREROUTING -d 207.166.203.139 -p tcp -m tcp --dport 80 -j DNAT 
--to-destination 10.1.7.5
-A PREROUTING -d 207.166.203.139 -p tcp -m tcp --dport 110 -j DNAT 
--to-destination 10.1.7.3
-A PREROUTING -d 207.166.203.139 -p tcp -m tcp --dport 443 -j DNAT 
--to-destination 10.1.7.5
-A PREROUTING -d 207.166.203.139 -p tcp -m tcp --dport 993 -j DNAT 
--to-destination 10.1.7.3
-A PREROUTING -d 207.166.203.139 -p tcp -m tcp --dport 995 -j DNAT 
--to-destination 10.1.7.3
-A PREROUTING -d 207.166.203.144 -p udp -m udp --dport 4569 -j DNAT 
--to-destination 10.1.1.8
-A PREROUTING -d 207.166.203.135 -p udp -m udp --dport 53 -j DNAT 
--to-destination 10.1.1.8
-A PREROUTING -d 207.166.203.145 -p udp -m udp --dport 53 -j DNAT 
--to-destination 10.1.2.2:8053
-A PREROUTING -d 207.166.203.146 -p udp -m udp --dport 53 -j DNAT 
--to-destination 10.1.2.3:8053
-A PREROUTING -d 207.166.203.139 -p tcp -m tcp --dport 22 -j DNAT 
--to-destination 10.1.1.130
-A PREROUTING -d 207.166.203.143 -j DNAT --to-destination 10.4.7.18
-A PREROUTING -d 207.166.203.148 -j DNAT --to-destination 10.1.7.6
-A PREROUTING -d 207.166.203.149 -j DNAT --to-destination 10.4.7.2
-A PREROUTING -d 207.166.203.150 -j DNAT --to-destination 10.4.7.20
-A PREROUTING -d 207.166.203.151 -j DNAT --to-destination 10.4.7.4
-A PREROUTING -d 207.166.203.153 -j DNAT --to-destination 10.4.7.6
-A PREROUTING -d 207.166.203.154 -j DNAT --to-destination 10.4.7.21
-A PREROUTING -d 207.166.203.155 -j DNAT --to-destination 10.4.7.8
-A PREROUTING -d 207.166.203.156 -j DNAT --to-destination 10.4.7.22
-A PREROUTING -d 207.166.203.157 -j DNAT --to-destination 10.4.7.10
-A PREROUTING -d 207.166.203.158 -j DNAT --to-destination 10.4.7.15
-A PREROUTING -d 207.166.203.159 -j DNAT --to-destination 10.4.7.17
-A PREROUTING -d 207.166.203.160 -j DNAT --to-destination 10.4.7.19
-A PREROUTING -d 207.166.203.161 -j DNAT --to-destination 10.4.7.23
-A PREROUTING -d 207.166.203.162 -j DNAT --to-destination 10.4.7.24
-A PREROUTING -d 207.166.193.157 -j DROP
-A PREROUTING -d 207.166.193.237 -j DROP
-A PREROUTING -d 207.166.193.238 -j DROP
-A PREROUTING -d 207.166.203.128/255.255.255.192 -j DROP
-A PREROUTING -d 207.166.218.128/255.255.255.224 -j DROP
-A PREROUTING -d 207.166.198.0/255.255.255.224 -j DROP
-A POSTROUTING -d 127.0.0.1 -j ACCEPT
-A POSTROUTING -o lo -j ACCEPT
-A POSTROUTING -s 10.0.0.0/255.0.0.0 -d 10.0.0.0/255.0.0.0 -m mark ! 
--mark 0x13 -j ACCEPT
-A POSTROUTING -s 10.0.0.0/255.0.0.0 -d 224.0.0.0/255.0.0.0 -j ACCEPT
-A POSTROUTING -m mark --mark 0x13 -j SNAT --to-source 207.166.193.157
-A POSTROUTING -s 10.1.1.8 -o vlan102 -p udp -m udp --dport 4569 -j SNAT 
--to-source 207.166.203.144
-A POSTROUTING -s 10.1.1.2 -o vlan102 -j SNAT --to-source 207.166.203.129
-A POSTROUTING -s 10.1.1.3 -o vlan102 -j SNAT --to-source 207.166.203.129
-A POSTROUTING -s 10.1.1.5 -o vlan102 -j SNAT --to-source 207.166.203.131
-A POSTROUTING -s 10.4.7.18 -o vlan102 -j SNAT --to-source 207.166.203.143
-A POSTROUTING -s 10.1.7.6 -o vlan102 -j SNAT --to-source 207.166.203.148
-A POSTROUTING -s 10.4.7.2 -o vlan102 -j SNAT --to-source 207.166.203.149
-A POSTROUTING -s 10.4.7.20 -o vlan102 -j SNAT --to-source 207.166.203.150
-A POSTROUTING -s 10.4.7.4 -o vlan102 -j SNAT --to-source 207.166.203.151
-A POSTROUTING -s 10.4.7.6 -o vlan102 -j SNAT --to-source 207.166.203.153
-A POSTROUTING -s 10.4.7.21 -o vlan102 -j SNAT --to-source 207.166.203.154
-A POSTROUTING -s 10.4.7.8 -o vlan102 -j SNAT --to-source 207.166.203.155
-A POSTROUTING -s 10.4.7.22 -o vlan102 -j SNAT --to-source 207.166.203.156
-A POSTROUTING -s 10.4.7.10 -o vlan102 -j SNAT --to-source 207.166.203.157
-A POSTROUTING -s 10.4.7.15 -o vlan102 -j SNAT --to-source 207.166.203.158
-A POSTROUTING -s 10.4.7.17 -o vlan102 -j SNAT --to-source 207.166.203.159
-A POSTROUTING -s 10.4.7.19 -o vlan102 -j SNAT --to-source 207.166.203.160
-A POSTROUTING -s 10.4.7.23 -o vlan102 -j SNAT --to-source 207.166.203.161
-A POSTROUTING -s 10.4.7.24 -o vlan102 -j SNAT --to-source 207.166.203.162
-A POSTROUTING -s 10.0.0.0/255.0.0.0 -o vlan102 -j SNAT --to-source 
207.166.203.142
-A BOGONS -s 0.0.0.0/254.0.0.0 -j DROP
-A BOGONS -s 2.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 5.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 7.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 10.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 23.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 27.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 31.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 36.0.0.0/254.0.0.0 -j DROP
-A BOGONS -s 39.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 41.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 42.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 49.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 50.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 73.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 74.0.0.0/254.0.0.0 -j DROP
-A BOGONS -s 76.0.0.0/252.0.0.0 -j DROP
-A BOGONS -s 89.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 90.0.0.0/254.0.0.0 -j DROP
-A BOGONS -s 92.0.0.0/252.0.0.0 -j DROP
-A BOGONS -s 96.0.0.0/224.0.0.0 -j DROP
-A BOGONS -s 169.254.0.0/255.255.0.0 -j DROP
-A BOGONS -s 172.16.0.0/255.240.0.0 -j DROP
-A BOGONS -s 173.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 174.0.0.0/254.0.0.0 -j DROP
-A BOGONS -s 176.0.0.0/248.0.0.0 -j DROP
-A BOGONS -s 184.0.0.0/252.0.0.0 -j DROP
-A BOGONS -s 189.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 190.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 192.0.2.0/255.255.255.0 -j DROP
-A BOGONS -s 192.168.0.0/255.255.0.0 -j DROP
-A BOGONS -s 197.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 198.18.0.0/255.254.0.0 -j DROP
-A BOGONS -s 223.0.0.0/255.0.0.0 -j DROP
-A BOGONS -s 224.0.0.0/224.0.0.0 -j DROP
-A INGRESS -d 207.166.198.0/255.255.255.224 -j RETURN
-A INGRESS -d 207.166.203.128/255.255.255.192 -j RETURN
-A INGRESS -d 207.166.218.128/255.255.255.224 -j RETURN
-A INGRESS -d 207.166.193.157 -j RETURN
-A INGRESS -d 207.166.193.237 -j RETURN
-A INGRESS -d 207.166.193.238 -j RETURN
-A INGRESS -j DROP
COMMIT
# Completed on Mon Jan 24 09:21:46 2005
# Generated by iptables-save v1.2.11 on Mon Jan 24 09:21:46 2005
*mangle
:PREROUTING ACCEPT [9667679:816132796]
:INPUT ACCEPT [13345820:1622723008]
:FORWARD ACCEPT [43129597:13669963843]
:OUTPUT ACCEPT [12060509:2123455184]
:POSTROUTING ACCEPT [55164024:15853406259]
-A PREROUTING -i vlan102 -p esp -j MARK --set-mark 0x16
-A PREROUTING -i vlan102 -p udp -m udp --dport 4500 -j MARK --set-mark 0x16
-A PREROUTING -m mark --mark 0x16 -j ACCEPT
-A PREROUTING -s 10.0.0.0/255.0.0.0 -d 207.166.193.157 -j MARK 
--set-mark 0x13
-A PREROUTING -s 10.0.0.0/255.0.0.0 -d 207.166.193.237 -j MARK 
--set-mark 0x13
-A PREROUTING -s 10.0.0.0/255.0.0.0 -d 207.166.193.238 -j MARK 
--set-mark 0x13
-A PREROUTING -s 10.0.0.0/255.0.0.0 -d 207.166.198.0/255.255.255.224 -j 
MARK --set-mark 0x13
-A PREROUTING -s 10.0.0.0/255.0.0.0 -d 207.166.203.128/255.255.255.192 
-j MARK --set-mark 0x13
-A PREROUTING -s 10.0.0.0/255.0.0.0 -d 207.166.218.128/255.255.255.224 
-j MARK --set-mark 0x13
-A PREROUTING -s 10.0.0.0/255.0.0.0 -j ACCEPT
-A PREROUTING -s 207.166.203.128/255.255.255.192 -j ACCEPT
-A PREROUTING -s 207.166.198.0/255.255.255.224 -j ACCEPT
-A PREROUTING -s 207.166.218.128/255.255.255.224 -j ACCEPT
-A PREROUTING -j CONNMARK --restore-mark
-A PREROUTING -m mark ! --mark 0x0 -j ACCEPT
-A PREROUTING -i ! vlan102 -j MARK --set-mark 0x14
-A PREROUTING -i vlan102 -j MARK --set-mark 0x15
-A PREROUTING -j CONNMARK --save-mark
-A OUTPUT -s 10.0.0.0/255.0.0.0 -j CONNMARK --restore-mark
COMMIT
# Completed on Mon Jan 24 09:21:46 2005
# Generated by iptables-save v1.2.11 on Mon Jan 24 09:21:46 2005
*filter
:INPUT ACCEPT [13345820:1622723008]
:FORWARD ACCEPT [43129597:13669963843]
:OUTPUT ACCEPT [12034429:2183442456]
COMMIT
# Completed on Mon Jan 24 09:21:46 2005
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-rc1-bk8
# Fri Jan 21 14:24:40 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_LOG_BUF_SHIFT=15
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set

#
# Loadable module support
#
# CONFIG_MODULES is not set

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HPET_TIMER is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
CONFIG_MATH_EMULATION=y
# CONFIG_MTRR is not set
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_SOFTWARE_SUSPEND is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=y
CONFIG_ACPI_IBM=y
CONFIG_ACPI_TOSHIBA=y
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_X86_PM_TIMER is not set
# CONFIG_ACPI_CONTAINER is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PC-card bridges
#

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=y
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI Transport Attributes
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
# CONFIG_MD_RAID10 is not set
CONFIG_MD_RAID5=y
# CONFIG_MD_RAID6 is not set
CONFIG_MD_MULTIPATH=y
# CONFIG_MD_FAULTY is not set
# CONFIG_BLK_DEV_DM is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=y
CONFIG_NET_IPGRE=y
# CONFIG_NET_IPGRE_BROADCAST is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_TUNNEL=y
CONFIG_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set

#
# IP: Virtual Server Configuration
#
CONFIG_IP_VS=y
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=y
CONFIG_IP_VS_WRR=y
CONFIG_IP_VS_LC=y
CONFIG_IP_VS_WLC=y
CONFIG_IP_VS_LBLC=y
CONFIG_IP_VS_LBLCR=y
CONFIG_IP_VS_DH=y
CONFIG_IP_VS_SH=y
CONFIG_IP_VS_SED=y
CONFIG_IP_VS_NQ=y

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=y
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
# CONFIG_IP_NF_CT_ACCT is not set
CONFIG_IP_NF_CONNTRACK_MARK=y
CONFIG_IP_NF_CT_PROTO_SCTP=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_PHYSDEV=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_REALM=y
CONFIG_IP_NF_MATCH_SCTP=y
CONFIG_IP_NF_MATCH_COMMENT=y
CONFIG_IP_NF_MATCH_CONNMARK=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_TARGET_CONNMARK=y
CONFIG_IP_NF_TARGET_CLUSTERIP=y
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_TARGET_NOTRACK=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y

#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=y
CONFIG_BRIDGE_EBT_BROUTE=y
CONFIG_BRIDGE_EBT_T_FILTER=y
CONFIG_BRIDGE_EBT_T_NAT=y
CONFIG_BRIDGE_EBT_802_3=y
CONFIG_BRIDGE_EBT_AMONG=y
CONFIG_BRIDGE_EBT_ARP=y
CONFIG_BRIDGE_EBT_IP=y
CONFIG_BRIDGE_EBT_LIMIT=y
CONFIG_BRIDGE_EBT_MARK=y
CONFIG_BRIDGE_EBT_PKTTYPE=y
CONFIG_BRIDGE_EBT_STP=y
CONFIG_BRIDGE_EBT_VLAN=y
CONFIG_BRIDGE_EBT_ARPREPLY=y
CONFIG_BRIDGE_EBT_DNAT=y
CONFIG_BRIDGE_EBT_MARK_T=y
CONFIG_BRIDGE_EBT_REDIRECT=y
CONFIG_BRIDGE_EBT_SNAT=y
CONFIG_BRIDGE_EBT_LOG=y
CONFIG_BRIDGE_EBT_ULOG=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
CONFIG_BRIDGE=y
CONFIG_VLAN_8021Q=y
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=y
CONFIG_NET_SCH_TEQL=y
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_GRED=y
CONFIG_NET_SCH_DSMARK=y
CONFIG_NET_SCH_NETEM=y
CONFIG_NET_SCH_INGRESS=y
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
# CONFIG_CLS_U32_PERF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=y
CONFIG_NET_CLS_RSVP6=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=y
CONFIG_NET_ACT_GACT=y
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=y
CONFIG_NET_ACT_IPT=y
CONFIG_NET_ACT_PEDIT=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
CONFIG_BONDING=y
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
CONFIG_ETHERTAP=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
CONFIG_VIA_RHINE=y
# CONFIG_VIA_RHINE_MMIO is not set

#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=y
# CONFIG_ACENIC_OMIT_TIGON_I is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
CONFIG_NS83820=y
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=y
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
CONFIG_PPP_ASYNC=y
CONFIG_PPP_SYNC_TTY=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=y
CONFIG_PPP_MPPE_MPPC=y
# CONFIG_PPPOE is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
CONFIG_GEN_RTC=y
CONFIG_GEN_RTC_X=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# I2C support
#
CONFIG_I2C=y
# CONFIG_I2C_CHARDEV is not set

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_ISA is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set

#
# Other I2C Chip support
#
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be 
needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_RW_DETECT is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set

#
# USB Input Devices
#
# CONFIG_USB_HID is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set

#
# USB port drivers
#

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=y
# CONFIG_USB_SERIAL_CONSOLE is not set
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
CONFIG_USB_SERIAL_PL2303=y
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_TEST is not set

#
# USB ATM/DSL drivers
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_DEVFS_FS=y
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
# CONFIG_NLS is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_WP512=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES_586=y
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_KHAZAD=y
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set

#
# Library routines
#
CONFIG_CRC_CCITT=y
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_PC=y
Linux version 2.6.11-rc1-bk8 (root@cr1) (gcc version 3.3.5 (Debian 
1:3.3.5-5)) #2 SMP Fri Jan 21 14:39:25 EST 2005
BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
  BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
  BIOS-e820: 0000000000100000 - 000000003eff0000 (usable)
  BIOS-e820: 000000003eff0000 - 000000003eff3000 (ACPI NVS)
  BIOS-e820: 000000003eff3000 - 000000003f000000 (ACPI data)
  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
111MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f52a0
On node 0 totalpages: 258032
   DMA zone: 4096 pages, LIFO batch:1
   Normal zone: 225280 pages, LIFO batch:16
   HighMem zone: 28656 pages, LIFO batch:6
DMI 2.3 present.
ACPI: RSDP (v000 PM800                                 ) @ 0x000f8ab0
ACPI: RSDT (v001 PM800  AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3eff3040
ACPI: FADT (v001 PM800  AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3eff30c0
ACPI: MADT (v001 PM800  AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3eff7f80
ACPI: DSDT (v001 PM800  AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:2 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
Using ACPI for processor (LAPIC) configuration information
Intel MultiProcessor Specification v1.4
     Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 2
Built 1 zonelists
Kernel command line: root=/dev/md1 ro pci=noacpi console=tty0 
console=ttyS0,9600n8
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 3055.467 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1017832k/1032128k available (2694k kernel code, 13736k reserved, 
1127k data, 332k init, 114624k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 5996.54 BogoMIPS (lpj=2998272)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 
00004400 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 
00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 00004400 
00000000 00000000
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Pentium(R) 4 CPU 3.06GHz stepping 09
per-CPU timeslice cutoff: 1462.66 usecs.
task migration cache decay timeout: 2 msecs.
Booting processor 1/1 eip 3000
Initializing CPU#1
Calibrating delay loop... 6094.84 BogoMIPS (lpj=3047424)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 
00004400 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 
00004400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 00004400 
00000000 00000000
CPU1: Intel(R) Pentium(R) 4 CPU 3.06GHz stepping 09
Total of 2 processors activated (12091.39 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=0
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
CPU0 attaching sched-domain:
  domain 0: span 03
   groups: 01 02
   domain 1: span 03
    groups: 03
CPU1 attaching sched-domain:
  domain 0: span 03
   groups: 02 01
   domain 1: span 03
    groups: 03
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb020, last bus=1
PCI: Using configuration type 1
ACPI: Subsystem revision 20041210
     ACPI-1138: *** Error: Method execution failed [\STRC] (Node 
c1904340), AE_AML_BUFFER_LIMIT
     ACPI-1138: *** Error: Method execution failed [\_SB_.PCI0._INI] 
(Node c190a980), AE_AML_BUFFER_LIMIT
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Via IRQ fixup
PCI: Via IRQ fixup
PCI: Using IRQ router VIA [1106/3177] at 0000:00:11.0
PCI->APIC IRQ transform: 0000:00:09.0[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:00:10.0[A] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:10.1[B] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:10.2[C] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:10.3[D] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:12.0[A] -> IRQ 23
PCI->APIC IRQ transform: 0000:01:00.0[A] -> IRQ 16
TC classifier action (bugs to netdev@oss.sgi.com cc hadi@cyberus.ca)
highmem bounce pool size: 64 pages
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
ibm_acpi: ec object not found
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
loop: loaded (max 8 devices)
nbd: registered device at major 43
Ethernet Channel Bonding Driver: v2.6.1 (October 29, 2004)
bonding: Warning: either miimon or arp_interval and arp_ip_target module 
parameters must be specified, otherwise bonding will not detect link 
failures! see bonding.txt for details.
acenic.c: v0.92 08/05/2002  Jes Sorensen, linux-acenic@SunSITE.dk
                             http://home.cern.ch/~jes/gige/acenic.html
0000:00:09.0: NetGear GA620 Gigabit Ethernet at 0xee000000, irq 16
   Tigon II (Rev. 6), Firmware: 12.4.11, MAC: 00:02:e3:00:09:31
   PCI cache line size set incorrectly (32 bytes) by BIOS/FW, correcting 
to 128
   PCI bus width: 32 bits, speed: 33MHz, latency: 64 clks
0000:00:09.0: Firmware up and running
ns83820.c: National Semiconductor DP83820 10/100/1000 driver.
eth0: Optical link UP (Full Duplex, Flow Control: )
via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker
eth1: VIA Rhine II at 0x1e400, 00:50:70:c8:57:92, IRQ 23.
eth1: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1.
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
MPPE/MPPC encryption/compression module registered
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:11.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci0000:00:11.1
     ide0: BM-DMA at 0xe300-0xe307, BIOS settings: hda:DMA, hdb:DMA
     ide1: BM-DMA at 0xe308-0xe30f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: SAMSUNG SP1203N, ATA DISK drive
hdb: SAMSUNG SP1203N, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: SAMSUNG SP1203N, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
Probing IDE interface ide3...
Probing IDE interface ide4...
Probing IDE interface ide5...
hda: max request size: 1024KiB
hda: Host Protected Area detected.
	current capacity is 234490943 sectors (120059 MB)
	native  capacity is 234493056 sectors (120060 MB)
hda: Host Protected Area disabled.
hda: 234493056 sectors (120060 MB) w/2048KiB Cache, CHS=16383/255/63, 
UDMA(100)
hda: cache flushes supported
  /dev/ide/host0/bus0/target0/lun0: p1 p2 p3
hdb: max request size: 1024KiB
hdb: 234493056 sectors (120060 MB) w/2048KiB Cache, CHS=16383/255/63, 
UDMA(100)
hdb: cache flushes supported
  /dev/ide/host0/bus0/target1/lun0: p1 p2 p3
hdc: max request size: 1024KiB
hdc: 234493056 sectors (120060 MB) w/2048KiB Cache, CHS=16383/255/63, 
UDMA(100)
hdc: cache flushes supported
  /dev/ide/host0/bus1/target0/lun0: p1 p2 p3
ehci_hcd 0000:00:10.3: VIA Technologies, Inc. USB 2.0
ehci_hcd 0000:00:10.3: irq 21, pci mem 0xee004000
ehci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:10.3: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
USB Universal Host Controller Interface driver v2.2
uhci_hcd 0000:00:10.0: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller
uhci_hcd 0000:00:10.0: irq 21, io base 0xe000
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
uhci_hcd 0000:00:10.1: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (#2)
uhci_hcd 0000:00:10.1: irq 21, io base 0xe100
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
uhci_hcd 0000:00:10.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (#3)
uhci_hcd 0000:00:10.2: irq 21, io base 0xe200
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic
usbcore: registered new driver usbserial_generic
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
drivers/usb/serial/usb-serial.c: USB Serial support registered for PL-2303
usbcore: registered new driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor 
driver v0.12
mice: PS/2 mouse device common for all mice
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: automatically using best checksumming function: pIII_sse
    pIII_sse  :  3980.000 MB/sec
raid5: using function: pIII_sse (3980.000 MB/sec)
md: multipath personality registered as nr 7
md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
GACT probability on
Mirror/redirect action on
u32 classifier
     Actions configured
NET: Registered protocol family 2
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
ip_conntrack version 2.1 (8063 buckets, 64504 max) - 300 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>. 
http://snowman.net/projects/ipt_recent/
ClusterIP Version 0.6 loaded successfully
arp_tables: (C) 2002 David S. Miller
IPVS: Registered protocols (TCP, UDP, AH, ESP)
IPVS: Connection hash table configured (size=4096, memory=32Kbytes)
IPVS: ipvs loaded.
IPVS: [rr] scheduler registered.
IPVS: [wrr] scheduler registered.
IPVS: [lc] scheduler registered.
IPVS: [wlc] scheduler registered.
IPVS: [lblc] scheduler registered.
IPVS: [lblcr] scheduler registered.
IPVS: [dh] scheduler registered.
IPVS: [sh] scheduler registered.
IPVS: [sed] scheduler registered.
IPVS: [nq] scheduler registered.
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Bridge firewalling registered
Ebtables v2.0 registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
Starting balanced_irq
ACPI wakeup devices:
SLPB PCI0 USB3 USB4 USB5 USB6 LAN0 AC97 UAR1
ACPI: (supports S0 S1 S4 S5)
md: Autodetecting RAID arrays.
md: autorun ...
md: considering hdc3 ...
md:  adding hdc3 ...
md: hdc1 has different UUID to hdc3
md:  adding hdb3 ...
md: hdb1 has different UUID to hdc3
md:  adding hda3 ...
md: hda1 has different UUID to hdc3
md: created md1
md: bind<hda3>
md: bind<hdb3>
md: bind<hdc3>
md: running: <hdc3><hdb3><hda3>
raid5: device hdc3 operational as raid disk 2
raid5: device hdb3 operational as raid disk 1
raid5: device hda3 operational as raid disk 0
raid5: allocated 3155kB for md1
raid5: raid level 5 set md1 active with 3 out of 3 devices, algorithm 2
RAID5 conf printout:
  --- rd:3 wd:3 fd:0
  disk 0, o:1, dev:hda3
  disk 1, o:1, dev:hdb3
  disk 2, o:1, dev:hdc3
md: considering hdc1 ...
md:  adding hdc1 ...
md:  adding hdb1 ...
md:  adding hda1 ...
md: created md0
md: bind<hda1>
md: bind<hdb1>
md: bind<hdc1>
md: running: <hdc1><hdb1><hda1>
raid1: raid set md0 active with 3 out of 3 mirrors
md: ... autorun DONE.
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 332k freed
Adding 979956k swap on /dev/hda2.  Priority:1 extents:1
Adding 979956k swap on /dev/hdb2.  Priority:1 extents:1
Adding 979956k swap on /dev/hdc2.  Priority:1 extents:1
EXT3 FS on md1, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on md0, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
device eth0.100 entered promiscuous mode
eth0.100: dev_set_promiscuity(master, 1)
device eth0 entered promiscuous mode
eth0.100: add 01:00:5e:00:00:01 mcast address to master interface
eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
device eth1.100 entered promiscuous mode
eth1.100: dev_set_promiscuity(master, 1)
eth1: Promiscuous mode enabled.
device eth1 entered promiscuous mode
eth1: Promiscuous mode enabled.
eth1.100: add 01:00:5e:00:00:01 mcast address to master interface
vlan100: port 2(eth1.100) entering listening state
vlan100: port 1(eth0.100) entering listening state
vlan100: port 2(eth1.100) entering blocking state
vlan100: port 1(eth0.100) entering learning state
vlan100: topology change detected, propagating
vlan100: port 1(eth0.100) entering forwarding state
eth0.101: dev_set_promiscuity(master, 1)
eth0.101: add 01:00:5e:00:00:01 mcast address to master interface
eth1.101: dev_set_promiscuity(master, 1)
eth1.101: add 01:00:5e:00:00:01 mcast address to master interface
vlan101: port 2(eth1.101) entering listening state
vlan101: port 1(eth0.101) entering listening state
vlan101: port 2(eth1.101) entering blocking state
vlan101: port 1(eth0.101) entering learning state
vlan101: topology change detected, propagating
vlan101: port 1(eth0.101) entering forwarding state
eth0.102: dev_set_promiscuity(master, 1)
eth0.102: add 01:00:5e:00:00:01 mcast address to master interface
eth1.102: dev_set_promiscuity(master, 1)
eth1.102: add 01:00:5e:00:00:01 mcast address to master interface
vlan102: port 2(eth1.102) entering listening state
vlan102: port 1(eth0.102) entering listening state
vlan102: port 2(eth1.102) entering blocking state
vlan102: port 1(eth0.102) entering learning state
vlan102: topology change detected, propagating
vlan102: port 1(eth0.102) entering forwarding state
eth0.200: dev_set_promiscuity(master, 1)
eth0.200: add 01:00:5e:00:00:01 mcast address to master interface
eth1.200: dev_set_promiscuity(master, 1)
eth1.200: add 01:00:5e:00:00:01 mcast address to master interface
vlan200: port 2(eth1.200) entering listening state
vlan200: port 1(eth0.200) entering listening state
vlan200: port 2(eth1.200) entering blocking state
vlan200: port 1(eth0.200) entering learning state
vlan200: topology change detected, propagating
vlan200: port 1(eth0.200) entering forwarding state
eth0.201: dev_set_promiscuity(master, 1)
eth0.201: add 01:00:5e:00:00:01 mcast address to master interface
eth1.201: dev_set_promiscuity(master, 1)
eth1.201: add 01:00:5e:00:00:01 mcast address to master interface
vlan201: port 2(eth1.201) entering listening state
vlan201: port 1(eth0.201) entering listening state
vlan201: port 2(eth1.201) entering blocking state
vlan201: port 1(eth0.201) entering learning state
vlan201: topology change detected, propagating
vlan201: port 1(eth0.201) entering forwarding state
eth0.300: dev_set_promiscuity(master, 1)
eth0.300: add 01:00:5e:00:00:01 mcast address to master interface
eth1.300: dev_set_promiscuity(master, 1)
eth1.300: add 01:00:5e:00:00:01 mcast address to master interface
vlan300: port 2(eth1.300) entering listening state
vlan300: port 1(eth0.300) entering listening state
vlan300: port 2(eth1.300) entering blocking state
vlan300: port 1(eth0.300) entering learning state
vlan300: topology change detected, propagating
vlan300: port 1(eth0.300) entering forwarding state
eth0.301: dev_set_promiscuity(master, 1)
eth0.301: add 01:00:5e:00:00:01 mcast address to master interface
eth1.301: dev_set_promiscuity(master, 1)
eth1.301: add 01:00:5e:00:00:01 mcast address to master interface
vlan301: port 2(eth1.301) entering listening state
vlan301: port 1(eth0.301) entering listening state
vlan301: port 2(eth1.301) entering blocking state
vlan301: port 1(eth0.301) entering learning state
vlan301: topology change detected, propagating
vlan301: port 1(eth0.301) entering forwarding state
eth0.302: dev_set_promiscuity(master, 1)
eth0.302: add 01:00:5e:00:00:01 mcast address to master interface
eth1.302: dev_set_promiscuity(master, 1)
eth1.302: add 01:00:5e:00:00:01 mcast address to master interface
vlan302: port 2(eth1.302) entering listening state
vlan302: port 1(eth0.302) entering listening state
vlan302: port 2(eth1.302) entering blocking state
vlan302: port 1(eth0.302) entering learning state
vlan302: topology change detected, propagating
vlan302: port 1(eth0.302) entering forwarding state
eth0.303: dev_set_promiscuity(master, 1)
eth0.303: add 01:00:5e:00:00:01 mcast address to master interface
eth1.303: dev_set_promiscuity(master, 1)
eth1.303: add 01:00:5e:00:00:01 mcast address to master interface
vlan303: port 2(eth1.303) entering listening state
vlan303: port 1(eth0.303) entering listening state
vlan303: port 2(eth1.303) entering blocking state
vlan303: port 1(eth0.303) entering learning state
vlan303: topology change detected, propagating
vlan303: port 1(eth0.303) entering forwarding state
ttyS1: LSR safety check engaged!
ttyS1: LSR safety check engaged!


David

-- 
David J. Coulson
email: david@davidcoulson.net
web: http://www.davidcoulson.net/
phone: (216) 920-3100 / (216) 258-4942

Re: skb_checksum_help

[David Coulson]

Patrick McHardy wrote:
> What about modules, .config, ... ?

No kernel module support on the box. Only non-standard patch, was the 
mppe/mppc patch which isn't being used right now (It's turned on in the 
kernel config however). I attached the .config to a previous e-mail.

David

-- 
David J. Coulson
email: david@davidcoulson.net
web: http://www.davidcoulson.net/
phone: (216) 920-3100 / (216) 258-4942

Re: skb_checksum_help

[David Coulson]

Thomas Graf wrote:
> Yes, this might clear things up.

10.1.1.5 is a production NS, so there is >500kbit/sec of DNS traffic to 
the box. Do you want me to restrict tcpdump to the /24 we were seeing 
traffic from which broke the kernel, or dump everything and send the 
part from around when the kernel fails?

> David, can you do this? and fix my patch by changing
> 
> 	if (skb->h.raw < skb->data || skb->h.raw > skb->data)
> into:
> 	if (skb->h.raw < skb->data || skb->h.raw > skb->tail)

Done

David

-- 
David J. Coulson
email: david@davidcoulson.net
web: http://www.davidcoulson.net/
phone: (216) 920-3100 / (216) 258-4942

Re: skb_checksum_help

[Thomas Graf]

* David Coulson <41F50B6C.6010107@davidcoulson.net> 2005-01-24 09:51
> Thomas Graf wrote:
> >Yes, this might clear things up.
> 
> 10.1.1.5 is a production NS, so there is >500kbit/sec of DNS traffic to 
> the box. Do you want me to restrict tcpdump to the /24 we were seeing 
> traffic from which broke the kernel, or dump everything and send the 
> part from around when the kernel fails?

After inspecting your iptables rule set I think it is a general UDP DNAT
problem under some circumstances. Some defragmentation weirdness in
prerouting might be invovled. It would definitely help to have a dump
of a complete ip fragments sequence causing this bug but I can't tell
what exactly is the cause just now so yes it might be a good idea to
limit the dump to the above subnet and hope the dodgy traffic comes
from the same subnet again.

Re: skb_checksum_help

[David Coulson]

Thomas Graf wrote:

> After inspecting your iptables rule set I think it is a general UDP DNAT
> problem under some circumstances. Some defragmentation weirdness in
> prerouting might be invovled. It would definitely help to have a dump
> of a complete ip fragments sequence causing this bug but I can't tell
> what exactly is the cause just now so yes it might be a good idea to
> limit the dump to the above subnet and hope the dodgy traffic comes
> from the same subnet again.

cr1:~# tcpdump -nxxli vlan102 net 211.32.117.0/24 and port 53 > tcpdump.txt

I assume that 'xx' is sufficient to dump all of the packet/link 
information we need?

David

-- 
David J. Coulson
email: david@davidcoulson.net
web: http://www.davidcoulson.net/
phone: (216) 920-3100 / (216) 258-4942

Re: skb_checksum_help

[Herbert Xu]

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

On Mon, Jan 24, 2005 at 04:15:10PM +0100, Thomas Graf wrote:
> 
> After inspecting your iptables rule set I think it is a general UDP DNAT
> problem under some circumstances. Some defragmentation weirdness in
> prerouting might be invovled. It would definitely help to have a dump
> of a complete ip fragments sequence causing this bug but I can't tell
> what exactly is the cause just now so yes it might be a good idea to
> limit the dump to the above subnet and hope the dodgy traffic comes
> from the same subnet again.

OK, I think I've found the problem.  It's a totally innocuous bug
in ip_fragment/ip6_fragment.  When we're in the fast path and use
the pre-existing frag_list skb's, we forgot to clear ip_summed.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

However, the problem that Patrick identified is very serious and
we should fix that as a matter of urgency.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[-- Attachment #2: p --]
[-- Type: text/plain, Size: 902 bytes --]

===== net/ipv4/ip_output.c 1.73 vs edited =====
--- 1.73/net/ipv4/ip_output.c	2004-12-28 12:56:34 +11:00
+++ edited/net/ipv4/ip_output.c	2005-01-25 09:32:49 +11:00
@@ -504,6 +504,7 @@
 			/* Prepare header of the next frame,
 			 * before previous one went down. */
 			if (frag) {
+				frag->ip_summed = CHECKSUM_NONE;
 				frag->h.raw = frag->data;
 				frag->nh.raw = __skb_push(frag, hlen);
 				memcpy(frag->nh.raw, iph, hlen);
===== net/ipv6/ip6_output.c 1.81 vs edited =====
--- 1.81/net/ipv6/ip6_output.c	2005-01-15 15:41:34 +11:00
+++ edited/net/ipv6/ip6_output.c	2005-01-25 09:48:25 +11:00
@@ -592,6 +592,7 @@
 			/* Prepare header of the next frame,
 			 * before previous one went down. */
 			if (frag) {
+				frag->ip_summed = CHECKSUM_NONE;
 				frag->h.raw = frag->data;
 				fh = (struct frag_hdr*)__skb_push(frag, sizeof(struct frag_hdr));
 				frag->nh.raw = __skb_push(frag, hlen);

Re: skb_checksum_help

[Thomas Graf]

* Herbert Xu <20050124225423.GA15405@gondor.apana.org.au> 2005-01-25 09:54
> On Mon, Jan 24, 2005 at 04:15:10PM +0100, Thomas Graf wrote:
> > 
> > After inspecting your iptables rule set I think it is a general UDP DNAT
> > problem under some circumstances. Some defragmentation weirdness in
> > prerouting might be invovled. It would definitely help to have a dump
> > of a complete ip fragments sequence causing this bug but I can't tell
> > what exactly is the cause just now so yes it might be a good idea to
> > limit the dump to the above subnet and hope the dodgy traffic comes
> > from the same subnet again.
> 
> OK, I think I've found the problem.  It's a totally innocuous bug
> in ip_fragment/ip6_fragment.  When we're in the fast path and use
> the pre-existing frag_list skb's, we forgot to clear ip_summed.

I don't quite understand how this solves the problem. How could
ip_summed be non zero after ip_forward? The earliest possible call
to ip_fragment is in postrouting. Please correct me if I'm wrong.

The bug isn't triggered for every fragment only once in a while so I don't
think it's that simple. 

Re: skb_checksum_help

[Herbert Xu]

On Tue, Jan 25, 2005 at 12:45:15AM +0100, Thomas Graf wrote:
> 
> I don't quite understand how this solves the problem. How could
> ip_summed be non zero after ip_forward? The earliest possible call
> to ip_fragment is in postrouting. Please correct me if I'm wrong.

ip_forward only sets ip_summed for the packet at the head.  It does
not clear ip_summed for the fragments themselves.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: skb_checksum_help

[David S. Miller]

On Tue, 25 Jan 2005 11:07:59 +1100
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> On Tue, Jan 25, 2005 at 12:45:15AM +0100, Thomas Graf wrote:
> > 
> > I don't quite understand how this solves the problem. How could
> > ip_summed be non zero after ip_forward? The earliest possible call
> > to ip_fragment is in postrouting. Please correct me if I'm wrong.
> 
> ip_forward only sets ip_summed for the packet at the head.  It does
> not clear ip_summed for the fragments themselves.

Yes, there exists all of this weird logic in ip_fragment.c trying
to preserve the checksumming done on RX by the hardware.

When we reassemble an ipv4 set of frags, we do this in ip_frag_reasm()

	for (fp=head->next; fp; fp = fp->next) {
		head->data_len += fp->len;
		head->len += fp->len;
		if (head->ip_summed != fp->ip_summed)
			head->ip_summed = CHECKSUM_NONE;
		else if (head->ip_summed == CHECKSUM_HW)
			head->csum = csum_add(head->csum, fp->csum);
		head->truesize += fp->truesize;
		atomic_sub(fp->truesize, &ip_frag_mem);
	}

Acenic uses the CHECKSUM_HW case, where the chip does a pretty much
straight 16-bit two's complement checksum over the whole data area.

Thus the head SKB csum field plus it's CHECKSUM_HW setting means
that UDP et al. receive checksumming offloading works for this
fraglist as it gets processed by IPv4 input protocol paths.

However, if we forward this thing, only the head SKB in the
fraglist has it's skb->ip_summed value reset.  Then ip_output()
sees that the head skb has a length greater than the dst_pmtu()
and we get to ip_fragment() which is where Herbert's fix is
located.

Remember that skb->len is the sum of the lengths of all the SKBs
on the fraglist.  So it will likely exceed the PMTU of the outgoing
route.

ip_fragment() notices that we have a frag list, all the geometry
and ownership tests pass, and we simply reuse the fraglist SKBs
to produce the output fragments.  And as Herbert discovered, we need
to reset the frag->ip_summed values before we push the IP header onto
such frags.

We want to preserve local IP protocol input usage of CHECKSUM_HW
information on such frag list SKBs, so the location to fix this
is in fact ip_fragment() and not any of the code in ip_fragment.c

Good catch Herbert, I'll integrate this fix.  2.4.x needs it too
I'm pretty sure.

Re: skb_checksum_help

[Thomas Graf]

* David S. Miller <20050124164049.3b939791.davem@davemloft.net> 2005-01-24 16:40
> On Tue, 25 Jan 2005 11:07:59 +1100
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
> 
> > On Tue, Jan 25, 2005 at 12:45:15AM +0100, Thomas Graf wrote:
> > > 
> > > I don't quite understand how this solves the problem. How could
> > > ip_summed be non zero after ip_forward? The earliest possible call
> > > to ip_fragment is in postrouting. Please correct me if I'm wrong.
> > 
> > ip_forward only sets ip_summed for the packet at the head.  It does
> > not clear ip_summed for the fragments themselves.

You are indeed right, I actually thought it would be like this first but
tricked myself into not believeing in this anymore because it would have
meant that every fragmented sequence could crash a kernel with one of
the drivers setting ip_summed to HW and the card not being able to do
the checksummin itself, so I thought I'd have missed some magic.

As it seems, it is really the case, a first peeks shows that the
following drivers set ip_summed to HW under some circumstances:
 acenic, he, hamachi, starfire, sungem, happy meal

> However, if we forward this thing, only the head SKB in the
> fraglist has it's skb->ip_summed value reset.  Then ip_output()
> sees that the head skb has a length greater than the dst_pmtu()
> and we get to ip_fragment() which is where Herbert's fix is
> located.

> We want to preserve local IP protocol input usage of CHECKSUM_HW
> information on such frag list SKBs, so the location to fix this
> is in fact ip_fragment() and not any of the code in ip_fragment.c

Agreed.

I've been talking to David on IRC and we have been able to reproduce the
bug by sending a sequence of fragmented ip packets to a host behind
the router. The only objection I had with this patch was, that I found
it too unlikely that his box wouldn't receive fragmented packets more
often, but as it seems it is really is this simple.

Still, one problem remains, even if ip_summed was incorrect,
skb_checksum_help should never be called in dev_queue_xmit for the
acenic driver since it sets NETIF_F_IP_CSUM. For some reason, features
is set to 0 while checking for it.

Re: skb_checksum_help

[Herbert Xu]

On Tue, Jan 25, 2005 at 02:45:38AM +0100, Thomas Graf wrote:
> 
> Still, one problem remains, even if ip_summed was incorrect,
> skb_checksum_help should never be called in dev_queue_xmit for the
> acenic driver since it sets NETIF_F_IP_CSUM. For some reason, features
> is set to 0 while checking for it.

Didn't he say that he cleared the features bits in the acenic driver?

BTW, is he using acenic for both the LAN and the WAN? If he's only
using it on the WAN side, then the LAN side might not be CSUM capable.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: skb_checksum_help

[David Coulson]

Herbert Xu wrote:
> Didn't he say that he cleared the features bits in the acenic driver?

I'm using the original acenic.c driver right now.

> BTW, is he using acenic for both the LAN and the WAN? If he's only
> using it on the WAN side, then the LAN side might not be CSUM capable.

I've got the NIC VLANed out in the kernel. It's the same physical NIC 
for inside and outside.

David

-- 
David J. Coulson
email: david@davidcoulson.net
web: http://www.davidcoulson.net/
phone: (216) 920-3100 / (216) 258-4942

Re: skb_checksum_help

[Thomas Graf]

* Herbert Xu <20050125014838.GA16637@gondor.apana.org.au> 2005-01-25 12:48
> On Tue, Jan 25, 2005 at 02:45:38AM +0100, Thomas Graf wrote:
> > 
> > Still, one problem remains, even if ip_summed was incorrect,
> > skb_checksum_help should never be called in dev_queue_xmit for the
> > acenic driver since it sets NETIF_F_IP_CSUM. For some reason, features
> > is set to 0 while checking for it.
> 
> Didn't he say that he cleared the features bits in the acenic driver?

He changed it back to the original version, I just checked with him.

> BTW, is he using acenic for both the LAN and the WAN? If he's only
> using it on the WAN side, then the LAN side might not be CSUM capable.

The packets get routed back over the same physical interface.

Re: skb_checksum_help

[David S. Miller]

On Tue, 25 Jan 2005 02:45:38 +0100
Thomas Graf <tgraf@suug.ch> wrote:

> As it seems, it is really the case, a first peeks shows that the
> following drivers set ip_summed to HW under some circumstances:
>  acenic, he, hamachi, starfire, sungem, happy meal

I looked this up too, and your list of drivers actually
using CHECKSUM_HW on RX seems accurate.

Re: skb_checksum_help

[David S. Miller]

On Tue, 25 Jan 2005 03:01:18 +0100
Thomas Graf <tgraf@suug.ch> wrote:

> * Herbert Xu <20050125014838.GA16637@gondor.apana.org.au> 2005-01-25 12:48
> > On Tue, Jan 25, 2005 at 02:45:38AM +0100, Thomas Graf wrote:
> > > 
> > > Still, one problem remains, even if ip_summed was incorrect,
> > > skb_checksum_help should never be called in dev_queue_xmit for the
> > > acenic driver since it sets NETIF_F_IP_CSUM. For some reason, features
> > > is set to 0 while checking for it.
> > 
> > Didn't he say that he cleared the features bits in the acenic driver?
> 
> He changed it back to the original version, I just checked with him.
> 
> > BTW, is he using acenic for both the LAN and the WAN? If he's only
> > using it on the WAN side, then the LAN side might not be CSUM capable.
> 
> The packets get routed back over the same physical interface.

I think I see what is happening, it's the virtual VLAN device which
has dev->features set to zero not the acenic's netdev struct.

Re: skb_checksum_help

[Herbert Xu]

On Mon, Jan 24, 2005 at 08:59:20PM -0500, David Coulson wrote:
> 
> I've got the NIC VLANed out in the kernel. It's the same physical NIC 
> for inside and outside.

I don't think the vlan code actually sets the features bits...
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: skb_checksum_help

[Herbert Xu]

On Tue, Jan 25, 2005 at 02:45:38AM +0100, Thomas Graf wrote:
> 
> the router. The only objection I had with this patch was, that I found
> it too unlikely that his box wouldn't receive fragmented packets more
> often, but as it seems it is really is this simple.

Well the BUG() only triggers if skb->csum + 2 > offset, which is not
necessarily true for every skb.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: skb_checksum_help

[Patrick McHardy]

Herbert Xu wrote:

>However, the problem that Patrick identified is very serious and
>we should fix that as a matter of urgency.
>
I'll send a patch later tonight.

Regards
Patrick

Re: skb_checksum_help

[Thomas Graf]

* David S. Miller <20050124180354.63ae600d.davem@davemloft.net> 2005-01-24 18:03
> > * Herbert Xu <20050125014838.GA16637@gondor.apana.org.au> 2005-01-25 12:48
> > > On Tue, Jan 25, 2005 at 02:45:38AM +0100, Thomas Graf wrote:
> > The packets get routed back over the same physical interface.
> 
> I think I see what is happening, it's the virtual VLAN device which
> has dev->features set to zero not the acenic's netdev struct.

This of course explains it, didn't think of that. I thought it would
inherit the checksumming features.

Re: skb_checksum_help

[David S. Miller]

On Tue, 25 Jan 2005 03:24:31 +0100
Thomas Graf <tgraf@suug.ch> wrote:

> This of course explains it, didn't think of that. I thought it would
> inherit the checksumming features.

It should, but only in very limited cases.

For example, it probably only works properly when HW vlan assist
is being used on TX.  It's likely that the chips which don't support
VLAN assist also can't handle VLAN headers in their TX checksumming
engine.

Because it is very chip dependant whether this works or not in
any case, we should probably create a special features flag for
this.  Something like NETIF_F_VLAN_INHERIT_FEATURES.

Re: skb_checksum_help

[Herbert Xu]

On Mon, Jan 24, 2005 at 04:40:49PM -0800, David S. Miller wrote:
> 
> Good catch Herbert, I'll integrate this fix.  2.4.x needs it too
> I'm pretty sure.

Well I just had a look there and no, this clever frag reuse code
was added in 2.5.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: skb_checksum_help

[David Coulson]

David S. Miller wrote:
> For example, it probably only works properly when HW vlan assist
> is being used on TX.  It's likely that the chips which don't support
> VLAN assist also can't handle VLAN headers in their TX checksumming
> engine.

This is in acenic.c - ACENIC_DO_VLAN is a check to see if 8021q is 
compiled into the kernel or available as a module.

#if ACENIC_DO_VLAN
         dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
         dev->vlan_rx_register = ace_vlan_rx_register;
         dev->vlan_rx_kill_vid = ace_vlan_rx_kill_vid;
#endif

David

-- 
David J. Coulson
email: david@davidcoulson.net
web: http://www.davidcoulson.net/
phone: (216) 920-3100 / (216) 258-4942

Re: skb_checksum_help

[David Coulson]

Herbert Xu wrote:

> OK, I think I've found the problem.  It's a totally innocuous bug
> in ip_fragment/ip6_fragment.  When we're in the fast path and use
> the pre-existing frag_list skb's, we forgot to clear ip_summed.

Okay - I applied Herbert's patch to my kernels and it all looks good 
now. Thomas showed me how to generate fragged packets using hping2 
(handy tool!) and replicate the kernel failure.

I slammed it with hping2 for a while, and didn't experience any kernel 
errors or see any debug information from previous patches. Everything is 
working as it should be, and I verified I saw the fragged packets in 
tcpdump to make sure they were being routed properly.

:-)

David

-- 
David J. Coulson
email: david@davidcoulson.net
web: http://www.davidcoulson.net/
phone: (216) 920-3100 / (216) 258-4942

Re: skb_checksum_help

[Thomas Graf]

* David S. Miller <20050124194328.20a106de.davem@davemloft.net> 2005-01-24 19:43
> On Tue, 25 Jan 2005 03:24:31 +0100
> Thomas Graf <tgraf@suug.ch> wrote:
> 
> > This of course explains it, didn't think of that. I thought it would
> > inherit the checksumming features.
> 
> It should, but only in very limited cases.
> 
> For example, it probably only works properly when HW vlan assist
> is being used on TX.  It's likely that the chips which don't support
> VLAN assist also can't handle VLAN headers in their TX checksumming
> engine.

I agreed, but those who have vlan accel are likely to be able to
also do the checksumming. 

> Because it is very chip dependant whether this works or not in
> any case, we should probably create a special features flag for
> this.  Something like NETIF_F_VLAN_INHERIT_FEATURES.

Can't we just use NETIF_F_HW_VLAN_TX for this and inherit
NETIF_F_HW_CSUM | NETIF_F_IP_CSUM if it is set? I don't have any
specs at hand though.

Re: skb_checksum_help

[Thomas Graf]

* Thomas Graf <20050125143319.GF31837@postel.suug.ch> 2005-01-25 15:33
> * David S. Miller <20050124194328.20a106de.davem@davemloft.net> 2005-01-24 19:43
> > On Tue, 25 Jan 2005 03:24:31 +0100
> > Thomas Graf <tgraf@suug.ch> wrote:
> > 
> > > This of course explains it, didn't think of that. I thought it would
> > > inherit the checksumming features.
> > 
> > It should, but only in very limited cases.
> > 
> > Because it is very chip dependant whether this works or not in
> > any case, we should probably create a special features flag for
> > this.  Something like NETIF_F_VLAN_INHERIT_FEATURES.
> 
> Can't we just use NETIF_F_HW_VLAN_TX for this and inherit
> NETIF_F_HW_CSUM | NETIF_F_IP_CSUM if it is set? I don't have any
> specs at hand though.

Vlan devices don't inherit any features at the moment but it would make
sense to do so.

NETIF_F_SG|NETIF_F_TSO:
  The normal vlan code seems to handle pskbs correctly, we don't gain
  that much though. The big gain would be in the driver specific accel
  code. I assume that the driver specific accel code is aware of
  pskbs if the card can handle it but I haven't checked this yet.

NETIF_F_NO_CSUM:
  Avoid checksumming for vlan devices on loopback interfaces.

NETIF_F_HIGHDMA|NETIF_F_FRAGLIST:
  Didn't find a reason why this would cause problems.

NETIF_F_LLTX:
  vlan code accesses statistic counters so I think we can't
  inherit. It might be worth to make it clean though.

NETIF_F_IP_CSUM|NETIF_F_HW_CSUM:
  Assuming that the vlan accel code can always do the checksumming
  if the card can do it.

Otherwise we need a mask describing which features can be
inherited.

Thoughts?

diff -Nru linux-2.6.11-rc2-bk2.orig/include/linux/if_vlan.h linux-2.6.11-rc2-bk2/include/linux/if_vlan.h
--- linux-2.6.11-rc2-bk2.orig/include/linux/if_vlan.h	2005-01-25 00:49:27.000000000 +0100
+++ linux-2.6.11-rc2-bk2/include/linux/if_vlan.h	2005-01-25 18:51:11.000000000 +0100
@@ -61,6 +61,9 @@
 
 #define VLAN_VID_MASK	0xfff
 
+#define VLAN_COMP_FEATURES(f)	((f) & (NETIF_F_SG|NETIF_F_NO_CSUM| \
+				 NETIF_F_HIGHDMA|NETIF_F_FRAGLIST|NETIF_F_TSO))
+
 /* found in socket.c */
 extern void vlan_ioctl_set(int (*hook)(void __user *));
 
diff -Nru linux-2.6.11-rc2-bk2.orig/net/8021q/vlan.c linux-2.6.11-rc2-bk2/net/8021q/vlan.c
--- linux-2.6.11-rc2-bk2.orig/net/8021q/vlan.c	2005-01-25 00:50:01.000000000 +0100
+++ linux-2.6.11-rc2-bk2/net/8021q/vlan.c	2005-01-25 18:54:45.000000000 +0100
@@ -459,6 +459,8 @@
 	/* TODO: maybe just assign it to be ETHERNET? */
 	new_dev->type = real_dev->type;
 
+	new_dev->features = VLAN_COMP_FEATURES(real_dev->features);
+
 	new_dev->hard_header_len = real_dev->hard_header_len;
 	if (!(real_dev->features & NETIF_F_HW_VLAN_TX)) {
 		/* Regular ethernet + 4 bytes (18 total). */
@@ -477,6 +479,7 @@
 		new_dev->hard_header = real_dev->hard_header;
 		new_dev->hard_start_xmit = vlan_dev_hwaccel_hard_start_xmit;
 		new_dev->rebuild_header = real_dev->rebuild_header;
+		new_dev->features = real_dev->features & (NETIF_F_IP_CSUM | NETIF_F_HW_CSUM);
 	} else {
 		new_dev->hard_header = vlan_dev_hard_header;
 		new_dev->hard_start_xmit = vlan_dev_hard_start_xmit;

Re: skb_checksum_help

[David S. Miller]

On Tue, 25 Jan 2005 22:23:46 +1100
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> On Mon, Jan 24, 2005 at 04:40:49PM -0800, David S. Miller wrote:
> > 
> > Good catch Herbert, I'll integrate this fix.  2.4.x needs it too
> > I'm pretty sure.
> 
> Well I just had a look there and no, this clever frag reuse code
> was added in 2.5.

Right, I noticed this too when I tried to "backport" the 2.6.x
patch :-)

Re: skb_checksum_help

[Ben Greear]

Thomas Graf wrote:
> * Thomas Graf <20050125143319.GF31837@postel.suug.ch> 2005-01-25 15:33
> 
>>* David S. Miller <20050124194328.20a106de.davem@davemloft.net> 2005-01-24 19:43
>>
>>>On Tue, 25 Jan 2005 03:24:31 +0100
>>>Thomas Graf <tgraf@suug.ch> wrote:
>>>
>>>
>>>>This of course explains it, didn't think of that. I thought it would
>>>>inherit the checksumming features.
>>>
>>>It should, but only in very limited cases.
>>>
>>>Because it is very chip dependant whether this works or not in
>>>any case, we should probably create a special features flag for
>>>this.  Something like NETIF_F_VLAN_INHERIT_FEATURES.
>>
>>Can't we just use NETIF_F_HW_VLAN_TX for this and inherit
>>NETIF_F_HW_CSUM | NETIF_F_IP_CSUM if it is set? I don't have any
>>specs at hand though.
> 
> 
> Vlan devices don't inherit any features at the moment but it would make
> sense to do so.
> 
> NETIF_F_SG|NETIF_F_TSO:
>   The normal vlan code seems to handle pskbs correctly, we don't gain
>   that much though. The big gain would be in the driver specific accel
>   code. I assume that the driver specific accel code is aware of
>   pskbs if the card can handle it but I haven't checked this yet.
> 
> NETIF_F_NO_CSUM:
>   Avoid checksumming for vlan devices on loopback interfaces.
> 
> NETIF_F_HIGHDMA|NETIF_F_FRAGLIST:
>   Didn't find a reason why this would cause problems.
> 
> NETIF_F_LLTX:
>   vlan code accesses statistic counters so I think we can't
>   inherit. It might be worth to make it clean though.
> 
> NETIF_F_IP_CSUM|NETIF_F_HW_CSUM:
>   Assuming that the vlan accel code can always do the checksumming
>   if the card can do it.

I am leery of assuming these things for all drivers and all chipsets.

Maybe the driver itself could tell vlan code what sorts of flags it
can set?  That takes the guess-work out, and each driver can add
the features support as it is verified to work.  If any particular
hacks need to be used (ie, maybe chipset foo.rev-1a can't handle one
particular thing), then the VLAN code doesn't have to care.

	new_dev->features = real_dev->vlan_features;

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: skb_checksum_help

[David S. Miller]

On Tue, 25 Jan 2005 21:36:07 +0100
Thomas Graf <tgraf@suug.ch> wrote:

> NETIF_F_IP_CSUM|NETIF_F_HW_CSUM:
>   Assuming that the vlan accel code can always do the checksumming
>   if the card can do it.

I bet there are cards that don't have VLAN hw assist yet
can properly checksum such packets.  One example I am counting
on to fit this property is the 3c59x.

This is why I'm suggesting some kind of inheritance indication
explicitly from the real_dev driver.  Perhaps even something
like:

	unsigned int vlan_inherited_features;

in the netdev struct.

Basically, I don't want to preclude inheritance of checksumming
capability just because the device doesn't have VLAN assist.

Re: skb_checksum_help

[Thomas Graf]

* Ben Greear <41F6B090.6020602@candelatech.com> 2005-01-25 12:48
> Thomas Graf wrote:
> >NETIF_F_IP_CSUM|NETIF_F_HW_CSUM:
> >  Assuming that the vlan accel code can always do the checksumming
> >  if the card can do it.
> 
> I am leery of assuming these things for all drivers and all chipsets.
> 
> Maybe the driver itself could tell vlan code what sorts of flags it
> can set?  That takes the guess-work out, and each driver can add
> the features support as it is verified to work.  If any particular
> hacks need to be used (ie, maybe chipset foo.rev-1a can't handle one
> particular thing), then the VLAN code doesn't have to care.
> 
> 	new_dev->features = real_dev->vlan_features;
> 
* David S. Miller <20050125125019.5ca32de1.davem@davemloft.net> 2005-01-25 12:50
> I bet there are cards that don't have VLAN hw assist yet
> can properly checksum such packets.  One example I am counting
> on to fit this property is the 3c59x.
> 
> This is why I'm suggesting some kind of inheritance indication
> explicitly from the real_dev driver.  Perhaps even something
> like:
> 
> 	unsigned int vlan_inherited_features;
> 
> in the netdev struct.

I thought about this too and actually implemented it but it means to
change all relevant drivers and the only feature that might be
driver specific is checksumming, given I didn't make any mistakes
while checking the drivers for pskb compatibility. Therefore I tried
to avoid it but it seems we can't get around it.

Any objections in inheriting SG|NO_CSUM|HIGH_DMA|FRAGLIST|TSO by
default or leave it to the driver as well?

Re: skb_checksum_help

[Ben Greear]

Thomas Graf wrote:
> * Ben Greear <41F6B090.6020602@candelatech.com> 2005-01-25 12:48
> 
>>Thomas Graf wrote:
>>
>>>NETIF_F_IP_CSUM|NETIF_F_HW_CSUM:
>>> Assuming that the vlan accel code can always do the checksumming
>>> if the card can do it.
>>
>>I am leery of assuming these things for all drivers and all chipsets.
>>
>>Maybe the driver itself could tell vlan code what sorts of flags it
>>can set?  That takes the guess-work out, and each driver can add
>>the features support as it is verified to work.  If any particular
>>hacks need to be used (ie, maybe chipset foo.rev-1a can't handle one
>>particular thing), then the VLAN code doesn't have to care.
>>
>>	new_dev->features = real_dev->vlan_features;
>>
> 
> * David S. Miller <20050125125019.5ca32de1.davem@davemloft.net> 2005-01-25 12:50
> 
>>I bet there are cards that don't have VLAN hw assist yet
>>can properly checksum such packets.  One example I am counting
>>on to fit this property is the 3c59x.
>>
>>This is why I'm suggesting some kind of inheritance indication
>>explicitly from the real_dev driver.  Perhaps even something
>>like:
>>
>>	unsigned int vlan_inherited_features;
>>
>>in the netdev struct.
> 
> 
> I thought about this too and actually implemented it but it means to
> change all relevant drivers and the only feature that might be
> driver specific is checksumming, given I didn't make any mistakes
> while checking the drivers for pskb compatibility. Therefore I tried
> to avoid it but it seems we can't get around it.
> 
> Any objections in inheriting SG|NO_CSUM|HIGH_DMA|FRAGLIST|TSO by
> default or leave it to the driver as well?

I'd leave everything to the driver.  Once we add the new flags field (vlan_inherited_features),
then it's trivial to just set the flags and not have to worry about automatic
inheritance.


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: skb_checksum_help

[David S. Miller]

On Tue, 25 Jan 2005 22:15:24 +0100
Thomas Graf <tgraf@suug.ch> wrote:

> I thought about this too and actually implemented it but it means to
> change all relevant drivers and the only feature that might be
> driver specific is checksumming, given I didn't make any mistakes
> while checking the drivers for pskb compatibility.

It is not only checksumming, but also TSO.  TSO, like checksumming,
is a feature where the chip must parse the packet to figure out where
to do it's work.  In fact, TSO is a prime suspect for VLAN problems
as the card must duplicate the VLAN headers properly as it chops
up the TSO frame into MSS sized pieces.

Re: skb_checksum_help

[David S. Miller]

On Tue, 25 Jan 2005 14:14:14 -0800
Ben Greear <greearb@candelatech.com> wrote:

> I'd leave everything to the driver.

I agree with Ben.  We've learned often in the past, especially
with VLAN, that it is often better to let the driver explicitly
say it can do something rather then assuming anything in
particular.