* Re: skb_checksum_help [not found] <41F432BD.3000300@davidcoulson.net> @ 2005-01-24 0:32 ` Thomas Graf 2005-01-24 0:49 ` skb_checksum_help Patrick McHardy 2005-01-24 1:31 ` skb_checksum_help David Coulson 0 siblings, 2 replies; 46+ messages in thread From: Thomas Graf @ 2005-01-24 0:32 UTC (permalink / raw) To: David Coulson; +Cc: netdev * 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; ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 0:32 ` skb_checksum_help Thomas Graf @ 2005-01-24 0:49 ` Patrick McHardy 2005-01-24 0:53 ` skb_checksum_help Thomas Graf 2005-01-24 1:31 ` skb_checksum_help David Coulson 1 sibling, 1 reply; 46+ messages in thread From: Patrick McHardy @ 2005-01-24 0:49 UTC (permalink / raw) To: Thomas Graf; +Cc: David Coulson, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 0:49 ` skb_checksum_help Patrick McHardy @ 2005-01-24 0:53 ` Thomas Graf 2005-01-24 1:31 ` skb_checksum_help Herbert Xu 0 siblings, 1 reply; 46+ messages in thread From: Thomas Graf @ 2005-01-24 0:53 UTC (permalink / raw) To: Patrick McHardy; +Cc: David Coulson, netdev * 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 0:53 ` skb_checksum_help Thomas Graf @ 2005-01-24 1:31 ` Herbert Xu 2005-01-24 4:27 ` skb_checksum_help David S. Miller 0 siblings, 1 reply; 46+ messages in thread From: Herbert Xu @ 2005-01-24 1:31 UTC (permalink / raw) To: Thomas Graf; +Cc: kaber, david, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 1:31 ` skb_checksum_help Herbert Xu @ 2005-01-24 4:27 ` David S. Miller 2005-01-24 4:38 ` skb_checksum_help David S. Miller ` (3 more replies) 0 siblings, 4 replies; 46+ messages in thread From: David S. Miller @ 2005-01-24 4:27 UTC (permalink / raw) To: Herbert Xu; +Cc: tgraf, kaber, david, netdev 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 4:27 ` skb_checksum_help David S. Miller @ 2005-01-24 4:38 ` David S. Miller 2005-01-24 4:46 ` skb_checksum_help Patrick McHardy ` (2 subsequent siblings) 3 siblings, 0 replies; 46+ messages in thread From: David S. Miller @ 2005-01-24 4:38 UTC (permalink / raw) To: David S. Miller; +Cc: herbert, tgraf, kaber, david, netdev 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 :-) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 4:27 ` skb_checksum_help David S. Miller 2005-01-24 4:38 ` skb_checksum_help David S. Miller @ 2005-01-24 4:46 ` Patrick McHardy 2005-01-24 4:56 ` skb_checksum_help Herbert Xu 2005-01-24 12:16 ` skb_checksum_help Thomas Graf 3 siblings, 0 replies; 46+ messages in thread From: Patrick McHardy @ 2005-01-24 4:46 UTC (permalink / raw) To: David S. Miller Cc: netdev, Netfilter Development Mailinglist, Herbert Xu, david 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 4:27 ` skb_checksum_help David S. Miller 2005-01-24 4:38 ` skb_checksum_help David S. Miller 2005-01-24 4:46 ` skb_checksum_help Patrick McHardy @ 2005-01-24 4:56 ` Herbert Xu 2005-01-24 5:07 ` skb_checksum_help Patrick McHardy 2005-01-24 12:16 ` skb_checksum_help Thomas Graf 3 siblings, 1 reply; 46+ messages in thread From: Herbert Xu @ 2005-01-24 4:56 UTC (permalink / raw) To: David S. Miller; +Cc: tgraf, kaber, david, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 4:56 ` skb_checksum_help Herbert Xu @ 2005-01-24 5:07 ` Patrick McHardy 2005-01-24 12:22 ` skb_checksum_help Thomas Graf 0 siblings, 1 reply; 46+ messages in thread From: Patrick McHardy @ 2005-01-24 5:07 UTC (permalink / raw) To: Herbert Xu; +Cc: David S. Miller, tgraf, david, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 5:07 ` skb_checksum_help Patrick McHardy @ 2005-01-24 12:22 ` Thomas Graf 2005-01-24 13:09 ` skb_checksum_help Patrick McHardy 0 siblings, 1 reply; 46+ messages in thread From: Thomas Graf @ 2005-01-24 12:22 UTC (permalink / raw) To: Patrick McHardy; +Cc: Herbert Xu, David S. Miller, david, netdev * 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 12:22 ` skb_checksum_help Thomas Graf @ 2005-01-24 13:09 ` Patrick McHardy 2005-01-24 14:49 ` skb_checksum_help David Coulson 0 siblings, 1 reply; 46+ messages in thread From: Patrick McHardy @ 2005-01-24 13:09 UTC (permalink / raw) To: Thomas Graf; +Cc: Herbert Xu, David S. Miller, david, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 13:09 ` skb_checksum_help Patrick McHardy @ 2005-01-24 14:49 ` David Coulson 0 siblings, 0 replies; 46+ messages in thread From: David Coulson @ 2005-01-24 14:49 UTC (permalink / raw) To: Patrick McHardy; +Cc: Thomas Graf, Herbert Xu, David S. Miller, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 4:27 ` skb_checksum_help David S. Miller ` (2 preceding siblings ...) 2005-01-24 4:56 ` skb_checksum_help Herbert Xu @ 2005-01-24 12:16 ` Thomas Graf 2005-01-24 14:51 ` skb_checksum_help David Coulson 3 siblings, 1 reply; 46+ messages in thread From: Thomas Graf @ 2005-01-24 12:16 UTC (permalink / raw) To: David S. Miller; +Cc: Herbert Xu, kaber, david, netdev * 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) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 12:16 ` skb_checksum_help Thomas Graf @ 2005-01-24 14:51 ` David Coulson 2005-01-24 15:15 ` skb_checksum_help Thomas Graf 0 siblings, 1 reply; 46+ messages in thread From: David Coulson @ 2005-01-24 14:51 UTC (permalink / raw) To: Thomas Graf; +Cc: David S. Miller, Herbert Xu, kaber, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 14:51 ` skb_checksum_help David Coulson @ 2005-01-24 15:15 ` Thomas Graf 2005-01-24 15:27 ` skb_checksum_help David Coulson 2005-01-24 22:54 ` skb_checksum_help Herbert Xu 0 siblings, 2 replies; 46+ messages in thread From: Thomas Graf @ 2005-01-24 15:15 UTC (permalink / raw) To: David Coulson; +Cc: David S. Miller, Herbert Xu, kaber, netdev * 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 15:15 ` skb_checksum_help Thomas Graf @ 2005-01-24 15:27 ` David Coulson 2005-01-24 22:54 ` skb_checksum_help Herbert Xu 1 sibling, 0 replies; 46+ messages in thread From: David Coulson @ 2005-01-24 15:27 UTC (permalink / raw) To: Thomas Graf; +Cc: David S. Miller, Herbert Xu, kaber, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 15:15 ` skb_checksum_help Thomas Graf 2005-01-24 15:27 ` skb_checksum_help David Coulson @ 2005-01-24 22:54 ` Herbert Xu 2005-01-24 23:45 ` skb_checksum_help Thomas Graf ` (2 more replies) 1 sibling, 3 replies; 46+ messages in thread From: Herbert Xu @ 2005-01-24 22:54 UTC (permalink / raw) To: Thomas Graf; +Cc: David Coulson, David S. Miller, kaber, netdev [-- 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); ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 22:54 ` skb_checksum_help Herbert Xu @ 2005-01-24 23:45 ` Thomas Graf 2005-01-25 0:07 ` skb_checksum_help Herbert Xu 2005-01-25 2:15 ` skb_checksum_help Patrick McHardy 2005-01-25 14:16 ` skb_checksum_help David Coulson 2 siblings, 1 reply; 46+ messages in thread From: Thomas Graf @ 2005-01-24 23:45 UTC (permalink / raw) To: Herbert Xu; +Cc: David Coulson, David S. Miller, kaber, netdev * 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 23:45 ` skb_checksum_help Thomas Graf @ 2005-01-25 0:07 ` Herbert Xu 2005-01-25 0:40 ` skb_checksum_help David S. Miller 0 siblings, 1 reply; 46+ messages in thread From: Herbert Xu @ 2005-01-25 0:07 UTC (permalink / raw) To: Thomas Graf; +Cc: David Coulson, David S. Miller, kaber, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 0:07 ` skb_checksum_help Herbert Xu @ 2005-01-25 0:40 ` David S. Miller 2005-01-25 1:45 ` skb_checksum_help Thomas Graf 2005-01-25 11:23 ` skb_checksum_help Herbert Xu 0 siblings, 2 replies; 46+ messages in thread From: David S. Miller @ 2005-01-25 0:40 UTC (permalink / raw) To: Herbert Xu; +Cc: tgraf, david, kaber, netdev 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 0:40 ` skb_checksum_help David S. Miller @ 2005-01-25 1:45 ` Thomas Graf 2005-01-25 1:48 ` skb_checksum_help Herbert Xu ` (2 more replies) 2005-01-25 11:23 ` skb_checksum_help Herbert Xu 1 sibling, 3 replies; 46+ messages in thread From: Thomas Graf @ 2005-01-25 1:45 UTC (permalink / raw) To: David S. Miller; +Cc: Herbert Xu, david, kaber, netdev * 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 1:45 ` skb_checksum_help Thomas Graf @ 2005-01-25 1:48 ` Herbert Xu 2005-01-25 1:59 ` skb_checksum_help David Coulson 2005-01-25 2:01 ` skb_checksum_help Thomas Graf 2005-01-25 2:02 ` skb_checksum_help David S. Miller 2005-01-25 2:14 ` skb_checksum_help Herbert Xu 2 siblings, 2 replies; 46+ messages in thread From: Herbert Xu @ 2005-01-25 1:48 UTC (permalink / raw) To: Thomas Graf; +Cc: David S. Miller, david, kaber, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 1:48 ` skb_checksum_help Herbert Xu @ 2005-01-25 1:59 ` David Coulson 2005-01-25 2:07 ` skb_checksum_help Herbert Xu 2005-01-25 2:01 ` skb_checksum_help Thomas Graf 1 sibling, 1 reply; 46+ messages in thread From: David Coulson @ 2005-01-25 1:59 UTC (permalink / raw) To: Herbert Xu; +Cc: Thomas Graf, David S. Miller, kaber, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 1:59 ` skb_checksum_help David Coulson @ 2005-01-25 2:07 ` Herbert Xu 0 siblings, 0 replies; 46+ messages in thread From: Herbert Xu @ 2005-01-25 2:07 UTC (permalink / raw) To: David Coulson; +Cc: Thomas Graf, David S. Miller, kaber, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 1:48 ` skb_checksum_help Herbert Xu 2005-01-25 1:59 ` skb_checksum_help David Coulson @ 2005-01-25 2:01 ` Thomas Graf 2005-01-25 2:03 ` skb_checksum_help David S. Miller 1 sibling, 1 reply; 46+ messages in thread From: Thomas Graf @ 2005-01-25 2:01 UTC (permalink / raw) To: Herbert Xu; +Cc: David S. Miller, david, kaber, netdev * 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 2:01 ` skb_checksum_help Thomas Graf @ 2005-01-25 2:03 ` David S. Miller 2005-01-25 2:24 ` skb_checksum_help Thomas Graf 0 siblings, 1 reply; 46+ messages in thread From: David S. Miller @ 2005-01-25 2:03 UTC (permalink / raw) To: Thomas Graf; +Cc: herbert, david, kaber, netdev 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 2:03 ` skb_checksum_help David S. Miller @ 2005-01-25 2:24 ` Thomas Graf 2005-01-25 3:43 ` skb_checksum_help David S. Miller 0 siblings, 1 reply; 46+ messages in thread From: Thomas Graf @ 2005-01-25 2:24 UTC (permalink / raw) To: David S. Miller; +Cc: herbert, david, kaber, netdev * 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 2:24 ` skb_checksum_help Thomas Graf @ 2005-01-25 3:43 ` David S. Miller 2005-01-25 12:05 ` skb_checksum_help David Coulson 2005-01-25 14:33 ` skb_checksum_help Thomas Graf 0 siblings, 2 replies; 46+ messages in thread From: David S. Miller @ 2005-01-25 3:43 UTC (permalink / raw) To: Thomas Graf; +Cc: herbert, david, kaber, netdev 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 3:43 ` skb_checksum_help David S. Miller @ 2005-01-25 12:05 ` David Coulson 2005-01-25 14:33 ` skb_checksum_help Thomas Graf 1 sibling, 0 replies; 46+ messages in thread From: David Coulson @ 2005-01-25 12:05 UTC (permalink / raw) To: David S. Miller; +Cc: Thomas Graf, herbert, kaber, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 3:43 ` skb_checksum_help David S. Miller 2005-01-25 12:05 ` skb_checksum_help David Coulson @ 2005-01-25 14:33 ` Thomas Graf 2005-01-25 20:36 ` skb_checksum_help Thomas Graf 1 sibling, 1 reply; 46+ messages in thread From: Thomas Graf @ 2005-01-25 14:33 UTC (permalink / raw) To: David S. Miller; +Cc: herbert, david, kaber, netdev * 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 14:33 ` skb_checksum_help Thomas Graf @ 2005-01-25 20:36 ` Thomas Graf 2005-01-25 20:48 ` skb_checksum_help Ben Greear 2005-01-25 20:50 ` skb_checksum_help David S. Miller 0 siblings, 2 replies; 46+ messages in thread From: Thomas Graf @ 2005-01-25 20:36 UTC (permalink / raw) To: David S. Miller; +Cc: herbert, david, kaber, greearb, netdev * 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; ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 20:36 ` skb_checksum_help Thomas Graf @ 2005-01-25 20:48 ` Ben Greear 2005-01-25 21:15 ` skb_checksum_help Thomas Graf 2005-01-25 20:50 ` skb_checksum_help David S. Miller 1 sibling, 1 reply; 46+ messages in thread From: Ben Greear @ 2005-01-25 20:48 UTC (permalink / raw) To: Thomas Graf; +Cc: David S. Miller, herbert, david, kaber, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 20:48 ` skb_checksum_help Ben Greear @ 2005-01-25 21:15 ` Thomas Graf 2005-01-25 22:14 ` skb_checksum_help Ben Greear 2005-01-25 23:30 ` skb_checksum_help David S. Miller 0 siblings, 2 replies; 46+ messages in thread From: Thomas Graf @ 2005-01-25 21:15 UTC (permalink / raw) To: Ben Greear, David S. Miller; +Cc: herbert, david, kaber, netdev * 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? ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 21:15 ` skb_checksum_help Thomas Graf @ 2005-01-25 22:14 ` Ben Greear 2005-01-25 23:31 ` skb_checksum_help David S. Miller 2005-01-25 23:30 ` skb_checksum_help David S. Miller 1 sibling, 1 reply; 46+ messages in thread From: Ben Greear @ 2005-01-25 22:14 UTC (permalink / raw) To: Thomas Graf; +Cc: David S. Miller, herbert, david, kaber, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 22:14 ` skb_checksum_help Ben Greear @ 2005-01-25 23:31 ` David S. Miller 0 siblings, 0 replies; 46+ messages in thread From: David S. Miller @ 2005-01-25 23:31 UTC (permalink / raw) To: Ben Greear; +Cc: tgraf, herbert, david, kaber, netdev 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 21:15 ` skb_checksum_help Thomas Graf 2005-01-25 22:14 ` skb_checksum_help Ben Greear @ 2005-01-25 23:30 ` David S. Miller 1 sibling, 0 replies; 46+ messages in thread From: David S. Miller @ 2005-01-25 23:30 UTC (permalink / raw) To: Thomas Graf; +Cc: greearb, herbert, david, kaber, netdev 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 20:36 ` skb_checksum_help Thomas Graf 2005-01-25 20:48 ` skb_checksum_help Ben Greear @ 2005-01-25 20:50 ` David S. Miller 1 sibling, 0 replies; 46+ messages in thread From: David S. Miller @ 2005-01-25 20:50 UTC (permalink / raw) To: Thomas Graf; +Cc: herbert, david, kaber, greearb, netdev 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 1:45 ` skb_checksum_help Thomas Graf 2005-01-25 1:48 ` skb_checksum_help Herbert Xu @ 2005-01-25 2:02 ` David S. Miller 2005-01-25 2:14 ` skb_checksum_help Herbert Xu 2 siblings, 0 replies; 46+ messages in thread From: David S. Miller @ 2005-01-25 2:02 UTC (permalink / raw) To: Thomas Graf; +Cc: herbert, david, kaber, netdev 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. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 1:45 ` skb_checksum_help Thomas Graf 2005-01-25 1:48 ` skb_checksum_help Herbert Xu 2005-01-25 2:02 ` skb_checksum_help David S. Miller @ 2005-01-25 2:14 ` Herbert Xu 2 siblings, 0 replies; 46+ messages in thread From: Herbert Xu @ 2005-01-25 2:14 UTC (permalink / raw) To: Thomas Graf; +Cc: David S. Miller, david, kaber, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 0:40 ` skb_checksum_help David S. Miller 2005-01-25 1:45 ` skb_checksum_help Thomas Graf @ 2005-01-25 11:23 ` Herbert Xu 2005-01-25 20:46 ` skb_checksum_help David S. Miller 1 sibling, 1 reply; 46+ messages in thread From: Herbert Xu @ 2005-01-25 11:23 UTC (permalink / raw) To: David S. Miller; +Cc: tgraf, david, kaber, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-25 11:23 ` skb_checksum_help Herbert Xu @ 2005-01-25 20:46 ` David S. Miller 0 siblings, 0 replies; 46+ messages in thread From: David S. Miller @ 2005-01-25 20:46 UTC (permalink / raw) To: Herbert Xu; +Cc: tgraf, david, kaber, netdev 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 :-) ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 22:54 ` skb_checksum_help Herbert Xu 2005-01-24 23:45 ` skb_checksum_help Thomas Graf @ 2005-01-25 2:15 ` Patrick McHardy 2005-01-25 14:16 ` skb_checksum_help David Coulson 2 siblings, 0 replies; 46+ messages in thread From: Patrick McHardy @ 2005-01-25 2:15 UTC (permalink / raw) To: Herbert Xu; +Cc: Thomas Graf, David Coulson, David S. Miller, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 22:54 ` skb_checksum_help Herbert Xu 2005-01-24 23:45 ` skb_checksum_help Thomas Graf 2005-01-25 2:15 ` skb_checksum_help Patrick McHardy @ 2005-01-25 14:16 ` David Coulson 2 siblings, 0 replies; 46+ messages in thread From: David Coulson @ 2005-01-25 14:16 UTC (permalink / raw) To: Herbert Xu; +Cc: Thomas Graf, David S. Miller, kaber, netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 0:32 ` skb_checksum_help Thomas Graf 2005-01-24 0:49 ` skb_checksum_help Patrick McHardy @ 2005-01-24 1:31 ` David Coulson 2005-01-24 12:31 ` skb_checksum_help Thomas Graf 1 sibling, 1 reply; 46+ messages in thread From: David Coulson @ 2005-01-24 1:31 UTC (permalink / raw) To: Thomas Graf; +Cc: netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 1:31 ` skb_checksum_help David Coulson @ 2005-01-24 12:31 ` Thomas Graf 2005-01-24 14:25 ` skb_checksum_help David Coulson 0 siblings, 1 reply; 46+ messages in thread From: Thomas Graf @ 2005-01-24 12:31 UTC (permalink / raw) To: David Coulson; +Cc: netdev * 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? ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: skb_checksum_help 2005-01-24 12:31 ` skb_checksum_help Thomas Graf @ 2005-01-24 14:25 ` David Coulson 0 siblings, 0 replies; 46+ messages in thread From: David Coulson @ 2005-01-24 14:25 UTC (permalink / raw) To: Thomas Graf; +Cc: netdev 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 ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2005-01-25 23:31 UTC | newest]
Thread overview: 46+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <41F432BD.3000300@davidcoulson.net>
2005-01-24 0:32 ` skb_checksum_help Thomas Graf
2005-01-24 0:49 ` skb_checksum_help Patrick McHardy
2005-01-24 0:53 ` skb_checksum_help Thomas Graf
2005-01-24 1:31 ` skb_checksum_help Herbert Xu
2005-01-24 4:27 ` skb_checksum_help David S. Miller
2005-01-24 4:38 ` skb_checksum_help David S. Miller
2005-01-24 4:46 ` skb_checksum_help Patrick McHardy
2005-01-24 4:56 ` skb_checksum_help Herbert Xu
2005-01-24 5:07 ` skb_checksum_help Patrick McHardy
2005-01-24 12:22 ` skb_checksum_help Thomas Graf
2005-01-24 13:09 ` skb_checksum_help Patrick McHardy
2005-01-24 14:49 ` skb_checksum_help David Coulson
2005-01-24 12:16 ` skb_checksum_help Thomas Graf
2005-01-24 14:51 ` skb_checksum_help David Coulson
2005-01-24 15:15 ` skb_checksum_help Thomas Graf
2005-01-24 15:27 ` skb_checksum_help David Coulson
2005-01-24 22:54 ` skb_checksum_help Herbert Xu
2005-01-24 23:45 ` skb_checksum_help Thomas Graf
2005-01-25 0:07 ` skb_checksum_help Herbert Xu
2005-01-25 0:40 ` skb_checksum_help David S. Miller
2005-01-25 1:45 ` skb_checksum_help Thomas Graf
2005-01-25 1:48 ` skb_checksum_help Herbert Xu
2005-01-25 1:59 ` skb_checksum_help David Coulson
2005-01-25 2:07 ` skb_checksum_help Herbert Xu
2005-01-25 2:01 ` skb_checksum_help Thomas Graf
2005-01-25 2:03 ` skb_checksum_help David S. Miller
2005-01-25 2:24 ` skb_checksum_help Thomas Graf
2005-01-25 3:43 ` skb_checksum_help David S. Miller
2005-01-25 12:05 ` skb_checksum_help David Coulson
2005-01-25 14:33 ` skb_checksum_help Thomas Graf
2005-01-25 20:36 ` skb_checksum_help Thomas Graf
2005-01-25 20:48 ` skb_checksum_help Ben Greear
2005-01-25 21:15 ` skb_checksum_help Thomas Graf
2005-01-25 22:14 ` skb_checksum_help Ben Greear
2005-01-25 23:31 ` skb_checksum_help David S. Miller
2005-01-25 23:30 ` skb_checksum_help David S. Miller
2005-01-25 20:50 ` skb_checksum_help David S. Miller
2005-01-25 2:02 ` skb_checksum_help David S. Miller
2005-01-25 2:14 ` skb_checksum_help Herbert Xu
2005-01-25 11:23 ` skb_checksum_help Herbert Xu
2005-01-25 20:46 ` skb_checksum_help David S. Miller
2005-01-25 2:15 ` skb_checksum_help Patrick McHardy
2005-01-25 14:16 ` skb_checksum_help David Coulson
2005-01-24 1:31 ` skb_checksum_help David Coulson
2005-01-24 12:31 ` skb_checksum_help Thomas Graf
2005-01-24 14:25 ` skb_checksum_help David Coulson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).