Hi
Could answers be cc'd to me personally, because I am not subscribed to
the list.
We are using kernel 2.4.24 and super-freeswan 1.99.8.
When using the frame relay protocol when a psk tunnel is established, we
are seeing a kernel panic when we ping through the tunnel.
This is the trace:
kernel BUG at skbuff.c:109!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c01bdbd1>] Not tainted
EFLAGS: 00010286
eax: 00000028 ebx: cf79fec0 ecx: c8f60000 edx: c6cfce00
esi: cbb28000 edi: c8f618ac ebp: 00000010 esp: c8f61854
ds: 0018 es: 0018 ss: 0018
Process ping (pid: 2323, stackpage=c8f61000)
Stack: c0232bc0 d0043f17 0000008c 00000004 cbb28000 d0043f20 cf79fec0
00000004
d0043f17 cbb28164 cbb28000 00000004 c8f618a4 d004436f c8f618ac
00000010
cf79fec0 cbb28000 00000004 cc73fcc0 00000000 c01c176a cf79fec0
cbb28000
Call Trace: [<d0043f17>] [<d0043f20>] [<d0043f17>] [<d004436f>]
[<c01c176a>]
[<c01d87c3>] [<c01d8730>] [<c01c8a96>] [<d01ddd8c>] [<c01d8712>]
[<c01d8730>]
[<d01ddd8c>] [<d01dddb6>] [<c01c8a96>] [<d01dccde>] [<d01ddd8c>]
[<d0211520>]
[<c018548e>] [<c013110a>] [<c019c49e>] [<d017340f>] [<c01cb4f1>]
[<d0211520>]
[<d0211520>] [<c01c16f1>] [<d0211520>] [<d0211520>] [<c01d87c3>]
[<d0211520>]
[<c01d8730>] [<c01c8a96>] [<d0211520>] [<c01d871c>] [<c01d735a>]
[<d0211520>]
[<c01d8730>] [<d0211520>] [<c01d871c>] [<c01d8729>] [<c01c8a96>]
[<c01d8020>]
[<d0211520>] [<c01d871c>] [<c01effb7>] [<c01efc54>] [<c01f6b56>]
[<c01baf95>]
[<c01bbcbc>] [<c0110ba4>] [<c011cdf0>] [<c01bc4ab>] [<c0108823>]
Running ksymoops on this gives:
>>ebx; cf79fec0 <_end+f4da4a0/fd71640>
>>ecx; c8f60000 <_end+8c9a5e0/fd71640>
>>edx; c6cfce00 <_end+6a373e0/fd71640>
>>esi; cbb28000 <_end+b8625e0/fd71640>
>>edi; c8f618ac <_end+8c9be8c/fd71640>
>>esp; c8f61854 <_end+8c9be34/fd71640>
Trace; d0043f17 <[hdlc].text.start+eb7/2f0e>
Trace; d0043f20 <[hdlc].text.start+ec0/2f0e>
Trace; d0043f17 <[hdlc].text.start+eb7/2f0e>
Trace; d004436f <[hdlc].text.start+130f/2f0e>
Trace; c01c176a <dev_queue_xmit+17a/2c4>
Trace; c01d87c3 <ip_finish_output+1b3/568>
Trace; c01d8730 <ip_finish_output+120/568>
Trace; c01c8a96 <nf_hook_slow+ee/144>
Trace; d01ddd8c <END_OF_CODE+22a55/????>
Trace; c01d8712 <ip_finish_output+102/568>
Trace; c01d8730 <ip_finish_output+120/568>
Trace; d01ddd8c <END_OF_CODE+22a55/????>
Trace; d01dddb6 <END_OF_CODE+22a7f/????>
Trace; c01c8a96 <nf_hook_slow+ee/144>
Trace; d01dccde <END_OF_CODE+219a7/????>
Trace; d01ddd8c <END_OF_CODE+22a55/????>
Trace; d0211520 <END_OF_CODE+561e9/????>
Trace; c018548e <blkdev_release_request+7be/7e0>
Trace; c013110a <bread+1a/d0>
Trace; c019c49e <execute_drive_cmd+38e/3bc>
Trace; d017340f <[ip_conntrack].text.start+3af/313f>
Trace; c01cb4f1 <qdisc_restart+51/1a4>
Trace; d0211520 <END_OF_CODE+561e9/????>
Trace; d0211520 <END_OF_CODE+561e9/????>
Trace; c01c16f1 <dev_queue_xmit+101/2c4>
Trace; d0211520 <END_OF_CODE+561e9/????>
Trace; d0211520 <END_OF_CODE+561e9/????>
Trace; c01d87c3 <ip_finish_output+1b3/568>
Trace; d0211520 <END_OF_CODE+561e9/????>
Trace; c01d8730 <ip_finish_output+120/568>
Trace; c01c8a96 <nf_hook_slow+ee/144>
Trace; d0211520 <END_OF_CODE+561e9/????>
Trace; c01d871c <ip_finish_output+10c/568>
Trace; c01d735a <ip_options_undo+a22/1760>
Trace; d0211520 <END_OF_CODE+561e9/????>
Trace; c01d8730 <ip_finish_output+120/568>
Trace; d0211520 <END_OF_CODE+561e9/????>
Trace; c01d871c <ip_finish_output+10c/568>
Trace; c01d8729 <ip_finish_output+119/568>
Trace; c01c8a96 <nf_hook_slow+ee/144>
Trace; c01d8020 <ip_options_undo+16e8/1760>
Trace; d0211520 <END_OF_CODE+561e9/????>
Trace; c01d871c <ip_finish_output+10c/568>
Trace; c01effb7 <tcp_read_sock+12567/1476c>
Trace; c01efc54 <tcp_read_sock+12204/1476c>
Trace; c01f6b56 <unregister_inetaddr_notifier+17de/1b54>
Trace; c01baf95 <sock_sendmsg+69/88>
Trace; c01bbcbc <sock_create+694/f40>
Trace; c0110ba4 <__verify_write+164/834>
Trace; c011cdf0 <notify_parent+b70/c58>
Trace; c01bc4ab <sock_create+e83/f40>
Trace; c0108823 <__up_wakeup+104f/1464>
Is anyone aware of this problem or have a solution to this problem?
Regards
--
Wim Ceulemans
R&D Engineer
aXs GUARD, internet communication solutions
do IT safe, do IT with aXs GUARD
Able NV
Leuvensesteenweg 282 - B-3190 Boortmeerbeek - Belgium
Phone: + 32 15 50.44.00 - Fax: + 32 15 50.44.09
Mobile: +32 497 44.52.52
E-Mail: [email protected]
http://www.axsguard.com
http://www.doITsafe.net
--
aXs GUARD has completed security and anti-virus checks on this e-mail
(http://www.axsguard.com)
Wim Ceulemans <[email protected]> writes:
> We are using kernel 2.4.24 and super-freeswan 1.99.8.
> When using the frame relay protocol when a psk tunnel is established,
> we are seeing a kernel panic when we ping through the tunnel.
Short version of my email to Wim:
It looks like a known bug - IPSEC code seems to ignore
dev->hard_header_len = 10 requirement for PVC devices and passes skbs
which have less than 10 bytes of header space. Not sure how does it
work with Ethernet which requires 14 bytes, though. It might be a good
idea to investigate.
I wonder if the FR behavior is correct - i.e. is it OK to set
dev->hard_header_len = 10 and expect that all skbs passed to
dev->hard_start_xmit() will have at least 10 bytes of space before
the data?
Does the situation depend on dev->hard_header being non-NULL?
--
Krzysztof Halasa, B*FH