Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Anthony Hinsinger <anthony.hinsinger@univ-pau.fr>
To: netfilter@vger.kernel.org
Cc: anthony.hinsinger@univ-pau.fr
Subject: Panic on 2.6.34+ and  bridged firewall
Date: Fri, 10 Dec 2010 13:34:34 +0100	[thread overview]
Message-ID: <4D021E5A.1010807@univ-pau.fr> (raw)

Hi.

I'm using netfilter/iptables on a Bridged Firewall, and i've a problem 
with linux kernel >= 2.6.34.
The kernel crash some seconds after i start the bridge interface and 
load my rules.

The setup of the firewall is :
- eth0 and eth1 bridged on br0, without ipv4 address (both using bnx2 
module)
- eth3 has an ip and a default gateway for administration purposes 
(e1000 module).
- The firewall is located between two routers, do ipv4 nat and filtering 
(30000 to 40000 simultaneous conntracks)

It was perfectly stable with 2.6.33.7 and earlier.

After some hours of crashes, i found the "guilty rules". This is rules 
with REJECT target. If i create only one rule, rejecting all bridged 
packets, it crash immediatly. If i replace reject with drop, no problem, 
it's stable. The bridge interface hasn't ipv4 adress so the ICMP 
messages generated by reject go through eth3. With tcpdump, i've been 
able to see some of thoses ICMP before it crashs.

I can understand "reject" is not really judicious on a bridge, but I 
imagine it's not a correct behavior to get a kernel panic :). Is there 
some modifications on 2.6.34 code that can explain this crash ?

This is one of the oops messages (if I reproduce the crash, the call 
trace is not exactly the same each times) :

[  389.021991] general protection fault: 0000 [#1] SMP
[  389.023038] last sysfs file: 
/sys/devices/pci0000:00/0000:00:04.0/0000:0a:00.1/net/eth3/broadcast
[  389.023038] CPU 0
[  389.023038] Modules linked in: ipt_REJECT bridge stp nf_nat_ftp 
nf_conntrack_ftp nf_nat_irc nf_conntrack_irc xt_limit xt_state xt_tcpudp 
ipt_LOG xt_physdev iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 
ip_set_iphash ip_set_nethash iptable_filter ipt_addrtype xt_dscp 
xt_string ipt_set xt_owner xt_multiport xt_mark xt_iprange xt_hashlimit 
xt_conntrack xt_connmark xt_DSCP ipt_SET ip_set xt_NFQUEUE xt_MARK 
xt_CONNMARK nf_conntrack ip_tables x_tables ipv6 tpm_tis tpm 8250_pnp 
pcspkr dcdbas bnx2 tpm_bios e1000e processor thermal rng_core button tg3 
libphy e1000 fuse nfs auth_rpcgss lockd sunrpc jfs raid10 raid1 raid0 
dm_snapshot dm_crypt dm_mirror dm_region_hash dm_log dm_mod 
scsi_wait_scan sbp2 ohci1394 ieee1394 sl811_hcd usbhid ohci_hcd uhci_hcd 
usb_storage ehci_hcd usbcore lpfc qla2xxx megaraid_sas megaraid_mbox 
megaraid_mm aacraid sx8 DAC960 cciss 3w_9xxx 3w_xxxx mptsas 
scsi_transport_sas mptfc scsi_transport_fc mptspi mptscsih mptbase 
atp870u dc395x qla1280 firmware_class imm parport dmx3191d sym53c8xx 
gdth initio BusLogic aic7xxx aic79xx scsi_transport_spi sg
[  389.023038]
[  389.023038] Pid: 0, comm: swapper Not tainted 2.6.34 #5 
0TT740/PowerEdge 1950
[  389.023038] RIP: 0010:[<ffffffff812eabd9>]  [<ffffffff812eabd9>] 
icmp_send+0x554/0x555
[  389.023038] RSP: 0018:ffff880001803708  EFLAGS: 00010286
[  389.023038] RAX: ffff88012f279940 RBX: 0e47658d95ab9026 RCX: 
ffff88012f279940
[  389.023038] RDX: 0000000000000000 RSI: 0000000002000000 RDI: 
ffffffff812eabc8
[  389.023038] RBP: 70604c93264364c1 R08: 0000000000000000 R09: 
0000000000000040
[  389.023038] R10: ffffffff812ab508 R11: ffff88012f061888 R12: 
60344ba6cd37126d
[  389.023038] R13: 119111c3b3b70261 R14: 6c885504af8db55f R15: 
a9c101014bbe640b
[  389.023038] FS:  0000000000000000(0000) GS:ffff880001800000(0000) 
knlGS:0000000000000000
[  389.023038] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  389.023038] CR2: 00000000006dc000 CR3: 000000000148f000 CR4: 
00000000000006f0
[  389.023038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
0000000000000000
[  389.023038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
0000000000000400
[  389.023038] Process swapper (pid: 0, threadinfo ffffffff8143c000, 
task ffffffff81497020)
[  389.023038] Stack:
[  389.023038]  7b8a648495529c0c 2ac6cdb97c629c37 b2d366a244c181b6 
a82d6e0a073a24bb
[  389.023038] <0> 449127a8960c8236 e89f174183805ff9 534593a2908afd53 
0cdb65034888d53f
[  389.023038] <0> 0ffff4a4822858b3 63684aa949806c11 dd6fcfeddf3e877a 
4c4996367c8ecfb6
[  389.023038] Call Trace:
[  389.023038] <IRQ>
[  389.023038]  [<ffffffff812bb26e>] ? sch_direct_xmit+0x83/0x156
[  389.023038]  [<ffffffff812ab508>] ? dev_queue_xmit+0x3e3/0x413
[  389.023038]  [<ffffffff812c2942>] ? nf_iterate+0x45/0xa7
[  389.023038]  [<ffffffffa03b49db>] ? br_nf_forward_finish+0x0/0xce 
[bridge]
[  389.023038]  [<ffffffff812c2a06>] ? nf_hook_slow+0x62/0xc3
[  389.023038]  [<ffffffffa03b49db>] ? br_nf_forward_finish+0x0/0xce 
[bridge]
[  389.023038]  [<ffffffffa03b4ca4>] ? br_nf_forward_ip+0x1fb/0x23e [bridge]
[  389.023038]  [<ffffffffa0442995>] ? __nf_ct_refresh_acct+0xb5/0x103 
[nf_conntrack]
[  389.023038]  [<ffffffff812c2942>] ? nf_iterate+0x45/0xa7
[  389.023038]  [<ffffffffa03b000a>] ? br_forward_finish+0x0/0x42 [bridge]
[  389.023038]  [<ffffffff812c2a06>] ? nf_hook_slow+0x62/0xc3
[  389.023038]  [<ffffffffa03b000a>] ? br_forward_finish+0x0/0x42 [bridge]
[  389.023038]  [<ffffffffa03b00c6>] ? __br_forward+0x7a/0x90 [bridge]
[  389.023038]  [<ffffffffa03b0bba>] ? 
br_handle_frame_finish+0x14e/0x1cf [bridge]
[  389.023038]  [<ffffffffa03b5296>] ? 
br_nf_pre_routing_finish+0x29d/0x2aa [bridge]
[  389.023038]  [<ffffffff812c2a06>] ? nf_hook_slow+0x62/0xc3
[  389.023038]  [<ffffffffa03b4ff9>] ? 
br_nf_pre_routing_finish+0x0/0x2aa [bridge]
[  389.023038]  [<ffffffffa03b4ff9>] ? 
br_nf_pre_routing_finish+0x0/0x2aa [bridge]
[  389.023038]  [<ffffffffa03b5910>] ? br_nf_pre_routing+0x66d/0x68a 
[bridge]
[  389.023038]  [<ffffffffa03b5910>] ? br_nf_pre_routing+0x66d/0x68a 
[bridge]
[  389.023038]  [<ffffffff812c2942>] ? nf_iterate+0x45/0xa7
[  389.023038]  [<ffffffffa03b0a6c>] ? br_handle_frame_finish+0x0/0x1cf 
[bridge]
[  389.023038]  [<ffffffff812c2a06>] ? nf_hook_slow+0x62/0xc3
[  389.023038]  [<ffffffffa03b0a6c>] ? br_handle_frame_finish+0x0/0x1cf 
[bridge]
[  389.023038]  [<ffffffffa03b0dcc>] ? br_handle_frame+0x191/0x1b9 [bridge]
[  389.023038]  [<ffffffff812aa12b>] ? netif_receive_skb+0x202/0x324
[  389.023038]  [<ffffffff811cfd33>] ? is_swiotlb_buffer+0x26/0x31
[  389.023038]  [<ffffffffa0343bb3>] ? bnx2_poll_work+0xf9f/0x10c6 [bnx2]
[  389.023038]  [<ffffffff811d0476>] ? swiotlb_map_page+0x0/0xc8
[  389.023038]  [<ffffffffa0343e8a>] ? bnx2_poll+0x10d/0x203 [bnx2]
[  389.023038]  [<ffffffff812aa440>] ? net_rx_action+0x64/0x128
[  389.023038]  [<ffffffff81064fed>] ? __rcu_process_callbacks+0x71/0x252
[  389.023038]  [<ffffffff81034d63>] ? __do_softirq+0x88/0x109
[  389.023038]  [<ffffffffa0340940>] ? bnx2_msi+0x3e/0x45 [bnx2]
[  389.023038]  [<ffffffff8100370c>] ? call_softirq+0x1c/0x28
[  389.023038]  [<ffffffff810052ed>] ? do_softirq+0x31/0x63
[  389.023038]  [<ffffffff810049f7>] ? do_IRQ+0xa3/0xb9
[  389.023038]  [<ffffffff8131ca53>] ? ret_from_intr+0x0/0xa
[  389.023038] <EOI>
[  389.023038]  [<ffffffff81009a6e>] ? mwait_idle+0x62/0x65
[  389.023038]  [<ffffffff81001bba>] ? cpu_idle+0x45/0x7a
[  389.023038]  [<ffffffff814f4c69>] ? start_kernel+0x353/0x35e
[  389.023038]  [<ffffffff814f4381>] ? x86_64_start_kernel+0xe5/0xe9
[  389.023038] Code: bc 24 28 01 00 00 48 85 ff 74 05 e8 fc 4b fc ff 48 
8b 7c 24 10 e8 65 1c 03 00 48 81 c4 38 01 00 00 5b 5d 41 5c 41 5d 41 5e 
41 5f <c3> 41 56 41 55 4c 8d 6f 28 41 54 49 89 f4 55 53 48 89 fb 4c 89
[  389.023038] RIP  [<ffffffff812eabd9>] icmp_send+0x554/0x555
[  389.023038]  RSP <ffff880001803708>
[  391.564381] ---[ end trace 527035a392022e35 ]---
[  391.605572] Kernel panic - not syncing: Fatal exception in interrupt

Thank you for help.
I'm available to make any tests you'll need.

-- 
Anthony Hinsinger
University of Pau - France
CRI / Network team.


             reply	other threads:[~2010-12-10 12:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-10 12:34 Anthony Hinsinger [this message]
2011-02-19 23:27 ` Panic on 2.6.34+ and bridged firewall Thomas Wild
2011-02-20 13:00   ` Atle Solbakken

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D021E5A.1010807@univ-pau.fr \
    --to=anthony.hinsinger@univ-pau.fr \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox