* Panic on 2.6.34+ and bridged firewall
@ 2010-12-10 12:34 Anthony Hinsinger
2011-02-19 23:27 ` Thomas Wild
0 siblings, 1 reply; 3+ messages in thread
From: Anthony Hinsinger @ 2010-12-10 12:34 UTC (permalink / raw)
To: netfilter; +Cc: anthony.hinsinger
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Panic on 2.6.34+ and bridged firewall
2010-12-10 12:34 Panic on 2.6.34+ and bridged firewall Anthony Hinsinger
@ 2011-02-19 23:27 ` Thomas Wild
2011-02-20 13:00 ` Atle Solbakken
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Wild @ 2011-02-19 23:27 UTC (permalink / raw)
To: netfilter
>Anthony Hinsinger <anthony.hinsinger <at> univ-pau.fr> writes:
>
>
> 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.
>
Hello,
I can absolutely confirm this problem. My system has the same behavior. The
previous kernel worked fine. But rejected crash the system a few seconds after
my iptables came up. I changed to DROP ... no it works out.
- Thomas
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Panic on 2.6.34+ and bridged firewall
2011-02-19 23:27 ` Thomas Wild
@ 2011-02-20 13:00 ` Atle Solbakken
0 siblings, 0 replies; 3+ messages in thread
From: Atle Solbakken @ 2011-02-20 13:00 UTC (permalink / raw)
To: Thomas Wild; +Cc: netfilter
Den 20. feb. 2011 00:27, skrev Thomas Wild:
>> Anthony Hinsinger<anthony.hinsinger<at> univ-pau.fr> writes:
>>
>>
>> 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.
>>
> Hello,
>
> I can absolutely confirm this problem. My system has the same behavior. The
> previous kernel worked fine. But rejected crash the system a few seconds after
> my iptables came up. I changed to DROP ... no it works out.
>
> - Thomas
>
I've also encountered crashes like this with 2.6.35-25-generic (Ubuntu).
I tried to figure out which packets that caused the crash.
I am not sure about the cause, but the crashes at least stopped after
blocking 224.0.0.0/16-traffic coming from a Mac on one of the interfaces.
Atle.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-02-20 13:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-10 12:34 Panic on 2.6.34+ and bridged firewall Anthony Hinsinger
2011-02-19 23:27 ` Thomas Wild
2011-02-20 13:00 ` Atle Solbakken
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox