8 messages, 2 authors, 2008-02-08 · open the first message on its own page
From: Beschorner Daniel <hidden>
Date: 2008-02-06 14:43:37
Unable to handle kernel paging request at ffffc200000fb000 RIP: [<ffffffff8031b8f0>] deflate_slow+0x40/0x400
Here is some more information about the scenario in which I can easily reproduce the oops now: Net_A - GW_A --- GW_B - Net_B The Net_A - Net_B ESP/AES/IPComp tunnel works fine, the tunnel between Net_B and the external IP address of GW_A triggers the oops in GW_A. Daniel
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2008-02-06 17:07:19
On Wed, Feb 06, 2008 at 03:43:25PM +0100, Beschorner Daniel wrote:
Net_A - GW_A --- GW_B - Net_B The Net_A - Net_B ESP/AES/IPComp tunnel works fine, the tunnel between Net_B and the external IP address of GW_A triggers the oops in GW_A.
That's interesting. So which one out of A and B is running 2.6.24?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
From: Beschorner Daniel <hidden>
Date: 2008-02-06 20:55:10
quoted
Net_A - GW_A --- GW_B - Net_B The Net_A - Net_B ESP/AES/IPComp tunnel works fine, the tunnel
between
quoted
Net_B and the external IP address of GW_A triggers the oops in GW_A.
That's interesting. So which one out of A and B is running 2.6.24?
A is the oopsing 2.6.24, B is 2.6.23. I didn't change anything in the scenario recently, till 2.6.23 all worked fine. Daniel
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2008-02-07 15:44:42
On Wed, Feb 06, 2008 at 09:55:03PM +0100, Beschorner Daniel wrote:
A is the oopsing 2.6.24, B is 2.6.23. I didn't change anything in the scenario recently, till 2.6.23 all worked fine.
OK, so are you now able to reproduce this crash without waiting
for hours? That would be really helpful in tracking it down.
Could you show me the exact policies/SAs of the tunnel involved
in the crash?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
From: Beschorner Daniel <hidden>
Date: 2008-02-07 18:01:41
OK, so are you now able to reproduce this crash without waiting for hours? That would be really helpful in tracking it down.
Yes, I can reproduce it in minutes now.
Could you show me the exact policies/SAs of the tunnel involved in the crash?
esp/cbc(aes128)/hmac(sha1) -------------------------------------------------------- Mit freundlichen Grüßen i.A. Daniel Beschorner Entwicklung FACTON GmbH Prager Str. 2 01069 Dresden Tel.: +49-351-40223-0 Mobil: +49-151-54446012 Fax: +49-351-40223-15 Mail: Daniel.Beschorner@facton.com Web: www.facton.com -------------------------------------------------------- Neuer FACTON-Unternehmensauftritt im Internet: www.facton.com Alle Schulungstermine 2008 in der Übersicht: www.facton.com/akademie2008 -------------------------------------------------------- Vertretungsberechtigte Geschäftsführer: Thoralf Nehls, Martin Nehls Sitz der Gesellschaft: Prager Straße 2, 01069 Dresden Handelsregister: Amtsgericht Dresden HRB 17304 -------------------------------------------------------- "This email message is intended only for the person(s) to whom it is addressed and as such is confidential. If you have received this communication in error, please notify us immediately and delete the original message. Thank you for your cooperation."
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2008-02-08 08:58:40
On Thu, Feb 07, 2008 at 07:01:32PM +0100, Beschorner Daniel wrote:
quoted
Could you show me the exact policies/SAs of the tunnel involved in the crash?esp/cbc(aes128)/hmac(sha1)
No I meant the exact output of ip x p and ip x s.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
From: Beschorner Daniel <hidden>
Date: 2008-02-08 10:45:40
No I meant the exact output of ip x p and ip x s.
I know, but as I end up every time with a tainted kernel on our production server I didn't turn ipcomp on, but now I got it. src Net_B dst A dir in priority 2088 tmpl src B dst A proto comp reqid 16394 mode tunnel level use tmpl src 0.0.0.0 dst 0.0.0.0 proto esp reqid 16393 mode transport src Net_B dst Net_A dir in priority 2344 tmpl src B dst A proto comp reqid 16390 mode tunnel level use tmpl src 0.0.0.0 dst 0.0.0.0 proto esp reqid 16389 mode transport src A dst Net_B dir out priority 2088 tmpl src A dst B proto comp reqid 16394 mode tunnel tmpl src 0.0.0.0 dst 0.0.0.0 proto esp reqid 16393 mode transport src Net_A dst Net_B dir out priority 2344 tmpl src A dst B proto comp reqid 16390 mode tunnel tmpl src 0.0.0.0 dst 0.0.0.0 proto esp reqid 16389 mode transport src Net_B dst A dir fwd priority 2088 tmpl src B dst A proto comp reqid 16394 mode tunnel level use tmpl src 0.0.0.0 dst 0.0.0.0 proto esp reqid 16393 mode transport src Net_B dst Net_A dir fwd priority 2344 tmpl src B dst A proto comp reqid 16390 mode tunnel level use tmpl src 0.0.0.0 dst 0.0.0.0 proto esp reqid 16389 mode transport src A dst B proto comp spi 0x0000427e reqid 16390 mode tunnel replay-window 0 comp deflate 0x sel src 0.0.0.0/0 dst 0.0.0.0/0 src B dst A proto comp spi 0x0000ecf0 reqid 16390 mode tunnel replay-window 0 comp deflate 0x sel src 0.0.0.0/0 dst 0.0.0.0/0 src A dst B proto esp spi 0x53f15e96 reqid 16389 mode transport replay-window 32 auth hmac(sha1) 0x... enc cbc(aes) 0x... sel src 0.0.0.0/0 dst 0.0.0.0/0 src B dst A proto esp spi 0x7b329066 reqid 16389 mode transport replay-window 32 auth hmac(sha1) 0... enc cbc(aes) 0x... sel src 0.0.0.0/0 dst 0.0.0.0/0 src A dst B proto (null) spi 0x53ec987a reqid 0 mode tunnel replay-window 0 sel src 0.0.0.0/0 dst 0.0.0.0/0 src B dst A proto (null) spi 0xc19ef67c reqid 0 mode tunnel replay-window 0 sel src 0.0.0.0/0 dst 0.0.0.0/0 src A dst B proto comp spi 0x00001314 reqid 16394 mode tunnel replay-window 0 comp deflate 0x sel src 0.0.0.0/0 dst 0.0.0.0/0 src B dst A proto comp spi 0x000032ff reqid 16394 mode tunnel replay-window 0 comp deflate 0x sel src 0.0.0.0/0 dst 0.0.0.0/0 src A dst B proto esp spi 0xec7d12de reqid 16393 mode transport replay-window 32 auth hmac(sha1) 0x... enc cbc(aes) 0x... sel src 0.0.0.0/0 dst 0.0.0.0/0 src B dst A proto esp spi 0x75016d2d reqid 16393 mode transport replay-window 32 auth hmac(sha1) 0x... enc cbc(aes) 0x... sel src 0.0.0.0/0 dst 0.0.0.0/0
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2008-02-08 18:32:00
On Fri, Feb 08, 2008 at 11:45:33AM +0100, Beschorner Daniel wrote:
quoted
No I meant the exact output of ip x p and ip x s.I know, but as I end up every time with a tainted kernel on our production server I didn't turn ipcomp on, but now I got it.
Hmm, that's pretty much what I've got (but I'm on 32-bit still).
Does every packet from A trigger the crash?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt