[Openswan dev] [PATCH] Openswan: fix ipcomp skb offset calculations

Thu Dec 4 00:21:16 EST 2008

Jivin Paul Wouters lays it down ...
> On Mon, 1 Dec 2008, Florian Westphal wrote:
> 
> > 
> > When a compressed packed is received, the kernel panics
> > (also see http://bugs.xelerance.com/view.php?id=982 , which appears to describe
> > the same issue):
> 
> can you confirm that with openswan-2.6.20dr2? Some of the defines got
> accidentally flipped around on some kernels.
> 
> I tried to reproduce this. I did run into issues.
> 
> - initiating with compress=yes on 2.6.20dr2 yielded a working connection,
>   but without IPcomp. Filed bug: http://bugs.xelerance.com/view.php?id=1014

Looking at this one now.

> - klips 2.4.x on the remote initiating to us. IPcomp negotiated. packets fail, despite:
>   klips_debug:ipsec_xmit_send: ...done, calling ip_send() on device:eth0
> - netkey 2.6.x on the remote initiating to us. IPcomp negotiated. packets fail as with klips 2.4
> 
> I do not however get a crasher or oops. It actually appears to me fine:
> 
> klips_debug:ipsec_xmit_send: ...done, calling ip_send() on device:eth0
> 
> I checked with the klips 2.4.x <-> klips 2.6.20dr2 where 2.4.x initiated and a correct ipcomp
> SA is established. pinging from 2.4.x to 2.6.20dr2 gives me encrypted packets out of 2.4.x
> onto 2.6.20dr2, decrypted, replied, encrypted send to 2.4.x, decrypted and then vanish.
> klipsdebug on 2.4.x tells me:
> 
> klips_debug:ipsec_xmit_encap_once: calling output for <COMP_DEFLATE>, SA:comp.ae2c at 193.110.157.17
> klips_debug:ipsec_xmit_encap_once: pushing 0 bytes, putting 0, proto 108.
> klips_debug:ipsec_xmit_encap_once: head,tailroom: 56,96 before xform.
> klips_debug:skb_compress: .
> klips_debug:skb_compress: skipping compression of tiny packet, len=84.
> klips_debug:ipsec_xmit_encap_once: packet did not compress (flags = 1).
> klips_debug:ipsec_xmit_encap_once: after <COMP_DEFLATE>, SA:comp.ae2c at 193.110.157.17:
> klips_debug:   IP: ihl:20 ver:4 tos:0 tlen:104 id:60345 frag_off:0 ttl:64 proto:4 chk:53594 saddr:193.110.157.143 daddr:193.110.157.17
> klips_debug:   IP: ihl:20 ver:4 tos:0 tlen:104 id:60345 frag_off:0 ttl:64 proto:4 chk:53594 saddr:193.110.157.143 daddr:193.110.157.17
> klips_debug:ipsec_xmit_encap_once: calling output for <ESP_AES_HMAC_SHA1>, SA:esp.91d3983c at 193.110.157.17
> klips_debug:ipsec_xmit_encap_once: pushing 24 bytes, putting 24, proto 50.
> klips_debug:ipsec_xmit_encap_once: head,tailroom: 32,72 before xform.
> klips_dmp: at pre-encrypt, len=152:
> klips_debug:   @000: 45 00 00 98 eb b9 00 00 40 32 d1 5a c1 6e 9d 8f
> klips_debug:   @010: c1 6e 9d 11 91 d3 98 3c 00 00 00 32 eb b9 00 00
> klips_debug:   @020: 40 04 d1 5a c1 6e 9d 8f c1 6e 9d 11 45 00 00 54
> klips_debug:   @030: 00 00 40 00 40 01 7d 2b c1 6e 9d 8f c1 6e 9d 11
> klips_debug:   @040: 08 00 b9 1e cd 36 00 04 58 59 37 49 ea 00 0d 00
> klips_debug:   @050: 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17
> klips_debug:   @060: 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27
> klips_debug:   @070: 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
> klips_debug:   @080: 01 02 03 04 05 06 07 08 09 0a 0a 04 3e 63 31 36
> klips_debug:   @090: 65 39 64 31 31 00 9d d1
> klips_debug:ipsec_alg_esp_encrypt: entering with encalg=12, ixt_e=d16abfa0
> klips_debug:ipsec_alg_esp_encrypt: calling cbc_encrypt encalg=12 ips_key_e=c2a44c00 idat=c325004c ilen=96 iv=c325003c, encrypt=1
> klips_debug:ipsec_alg_esp_encrypt: returned ret=96
> klips_debug:ipsec_xmit_encap_once: after <ESP_AES_HMAC_SHA1>, SA:esp.91d3983c at 193.110.157.17:
> klips_debug:   IP: ihl:20 ver:4 tos:0 tlen:152 id:60345 frag_off:0 ttl:64 proto:50 (ESP) chk:53500 saddr:193.110.157.143 daddr:193.110.157.17
> klips_debug:   IP: ihl:20 ver:4 tos:0 tlen:152 id:60345 frag_off:0 ttl:64 proto:50 (ESP) chk:53500 saddr:193.110.157.143 daddr:193.110.157.17
> klips_error:ipsec_sa_put: null pointer passed in!
> klips_debug:ipsec_findroute: 193.110.157.143:0->193.110.157.17:0 50
> klips_debug:rj_match: * See if we match exactly as a host destination
> klips_debug:rj_match: ** try to match a leaf, t=0pc2b163a0
> klips_debug:ipsec_xmit_restore_hard_header: After recursive xforms -- head,tailroom: 32,72
> klips_debug:ipsec_xmit_restore_hard_header: With hard_header, final head,tailroom: 18,72
> klips_debug:ipsec_xmit_send: ...done, calling ip_send() on device:eth0
> klips_debug:   IP: ihl:20 ver:4 tos:0 tlen:152 id:60345 frag_off:0 ttl:64 proto:50 (ESP) chk:53500 saddr:193.110.157.143 daddr:193.110.157.17
> 
> I am not sure why I am not seeing the successfully decrypted packet.
> 
> I did want to test with your patch, to see if it resolved anything. But
> it did not compile for me:
> 
> make -C /usr/src/kernels/2.6.27.5-117.fc10.x86_64/  BUILDDIR=/vol/git/openswan.ikev2/modobj26 SUBDIRS=/vol/git/openswan.ikev2/modobj26 MODULE_DEF_INCLUDE=/vol/git/openswan.ikev2/packaging/linus/config-all.h MODULE_DEFCONFIG=/vol/git/openswan.ikev2/linux/net/ipsec/defconfig  MODULE_EXTRA_INCLUDE= ARCH=x86_64 modules
> make[2]: Entering directory `/usr/src/kernels/2.6.27.5-117.fc10.x86_64'
>   CC [M]  /vol/git/openswan.ikev2/modobj26/ipcomp.o
> /vol/git/openswan.ikev2/modobj26/ipcomp.c: In function 'skb_copy_ipcomp':
> /vol/git/openswan.ikev2/modobj26/ipcomp.c:618: error: 'struct sk_buff' has no member named 'h'
> /vol/git/openswan.ikev2/modobj26/ipcomp.c:626: error: 'struct sk_buff' has no member named 'nh'
> make[3]: *** [/vol/git/openswan.ikev2/modobj26/ipcomp.o] Error 1
> 
> What kernel source are you using? Is this a modified or backported kernel?
> 
> There is surely something fishy going on with ipcomp, but I'm not sure yet
> what the problem is.

Yep,  on 2.6.20 something is amiss and I am working on it.

I did however run an older system against an openswan 2.6.20 and get
ipcomp in one direction.  At least I think so,  bit of a blur ;-)

For whatever reason 2.6.20 is not sending out the PROTO_IPCOMP transform
proposal.  Hopefully I find the culprit soon and then I planned on
testing Florian's patch,  unless you want to ;-)

I thought I had tested ipcomp with 2.4.12 as part of OCF,  but I have
really have no motivation to go back there at the moment :-)

Cheers,
Davidm

-- 
David McCullough,  david_mccullough at securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com