[Openswan dev] Openswan 2.6.24 TCP traffic
David McCullough
david_mccullough at mcafee.com
Tue Feb 9 23:39:09 EST 2010
Jivin Ronen Shitrit lays it down ...
> I think I found the problem,
> There is a new flag IFF_XMIT_DST_RELEASE see commit
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=93f154b594fe47e4a7e5358b309add449a046cd3
>
> I believe this flag should be unset in our case,
> It will probably solve my problem, I will test it tomorrow...
Patch attached. Works AFAICT. Let us know how you go and I'll commit
this.
Not sure if we should look at klips and see if we can call
skb_dst_release(..) earlier than "when we are finished with the skb".
I fixed up the general nothing goes wrong case so that we do not need,
so perhaps after the last icmp/reply packet type cases we can release the
dst.
Cheers,
Davidm
>
> Regards
>
> -----Original Message-----
> From: dev-bounces at openswan.org [mailto:dev-bounces at openswan.org] On Behalf Of Ronen Shitrit
> Sent: Tuesday, February 09, 2010 6:25 PM
> To: David McCullough
> Cc: dev at openswan.org
> Subject: Re: [Openswan dev] Openswan 2.6.24 TCP traffic
>
> 2.6.30 works 2.6.31 fails... did diff on the entire net/ipv4/ and couldn't find the root cause getting NULL on the dst pointer on 2.6.31 :(
>
> BTW: rmmod of ipsec.ko get kernel BUG at net/core/dev.c on free_netdev,
> Don't have the time to dig into this one.
>
> Regards
>
> -----Original Message-----
> From: dev-bounces at openswan.org [mailto:dev-bounces at openswan.org] On Behalf Of Ronen Shitrit
> Sent: Tuesday, February 09, 2010 3:43 PM
> To: David McCullough
> Cc: dev at openswan.org
> Subject: Re: [Openswan dev] Openswan 2.6.24 TCP traffic
>
> Thanks for your reply.
> Did someone try doing ftp put on some machine using kernel 2.6.32 and Openswan 2.6.24?
>
> I also tried using kernel 2.6.31 and it still fails, any idea on which version should it work?
>
>
> Regards
> Ronen Shitrit
>
>
> -----Original Message-----
> From: David McCullough [mailto:david_mccullough at mcafee.com]
> Sent: Tuesday, February 09, 2010 2:10 PM
> To: Ronen Shitrit
> Cc: dev at openswan.org
> Subject: Re: [Openswan dev] Openswan 2.6.24 TCP traffic
>
>
> Jivin Ronen Shitrit lays it down ...
> >
> > Sorry if it mail was sent more then once, but I keep getting:
> > "Due to too much spam, the developer list has been closed for posting for non-members. Please subscribe to the list and then repost your message."
> >
> > Hi
> >
> > I'm working on latest Openswan release 2.6.24 with kernel 2.6.32 and I can't get ftp to work over an IPsec connection.
> >
> > I ramp up a connection in front of windows PC and I can ping the PC just fine, capturing the packets shows the connection was properly established.
> > When I try to ftp put a large file I get a recursive message of the following error:
> > klips_error:ipsec_xmit_send: ip_send() failed, err=90
> >
> > I enabled the openswan debug (see log below) and found that the IPsec receive an 1500 bytes packet size with DF set in the packet,
> > The openswan detect it and try to send an ICMP indicating packet size of 1500 can't be sent (ipsec_xmit line 1741), however the icmp_send fails since skb_dst(skb) is NULL.
> > Tracing the SKB to the beginning of the Openswan, I can see that ipsec_tunnel_start_xmit is being called with skb_dst(skb) set to NULL.
> >
> > When checking the same path on working setup using openswan 2.4.9 with kernel 2.6.22, I see that skb->dst is properly initialized when calling ipsec_tunnel_start_xmit.
> >
> > I'm wondering if the problem is the fact that skb_dst(skb) is initialized to NULL when calling ipsec_tunnel_start_xmit, or this is part of the changes done by the kernel on latest versions and the Openswan should be adjusted.
>
> Almost certainly kernel changes. There have been a few but I haven't met
> this one yet.
>
> Not sure how to get dst set other than doing the routing, but that seems
> excessive in this case. Perhaps someone else has some ideas ?
>
> Cheers,
> Davidm
>
>
> > ipsec_tunnel_start_xmit: STARTING
> > klips_debug:ipsec_xmit_strip_hard_header: >>> skb->len=1500 hard_header_len:14 45:08:05:dc:bc:02:40:00:40:06:00:74:0a:04
> > klips_debug: IP: ihl:20 ver:4 tos:8 tlen:1500 id:48130 DF frag_off:0 ttl:64 proto:6 (TCP) chk:116 saddr:10.4.50.135:35637 daddr:10.4.50.15:3139
> > klips_debug:ipsec_xmit_strip_hard_header: Original head,tailroom: 196,0
> > klips_debug:ipsec_findroute: 10.4.50.135:35637->10.4.50.15:3139 6
> > klips_debug:rj_match: * See if we match exactly as a host destination
> > klips_debug:rj_match: ** try to match a leaf, t=0pdfaec100
> > klips_debug:ipsec_xmit_SAlookup: checking for local udp/500 IKE packet saddr=a043287, er=0pdfaec100, daddr=a04320f, er_dst=a04320f, proto=6 sport=35637 dpor9
> > ipsec_sa_getbyid: linked entry in ipsec_sa table for hash=24 of SA:esp.21010568 at 10.4.50.15 requested.
> > ipsec_sa_get: ipsec_sa dd41c800 SA:esp.21010568 at 10.4.50.15, ref:1 reference count (3++) incremented by ipsec_sa_getbyid:566.
> > klips_debug:ipsec_xmit_init2: found ipsec_sa -- SA:<ESP_3DES_HMAC_SHA1> esp.21010568 at 10.4.50.15
> > klips_debug:ipsec_xmit_init2: calling room for <ESP_3DES_HMAC_SHA1>, SA:esp.21010568 at 10.4.50.15
> > klips_debug:ipsec_xmit_init2: Required head,tailroom: 16,20
> > klips_debug:ipsec_xmit_init2: existing head,tailroom: 196,0 before applying xforms with head,tailroom: 16,20 .
> > klips_debug:ipsec_xmit_init2: mtu:1500 physmtu:1500 tothr:16 tottr:20 mtudiff:36 ippkttotlen:1500
> > klips_info:ipsec_xmit_init2: dev ipsec0 mtu of 1500 decreased by 37 to 1463
> > klips_debug:ipsec_xmit_init2: fragmentation needed and DF set; sending ICMP and passing packet
> > klips_debug:ipsec_xmit_init2: hard header already stripped.
> > klips_debug:ipsec_xmit_init2: head,tailroom: 48,20 after allocation
> > klips_debug: IP: ihl:20 ver:4 tos:8 tlen:1500 id:48130 DF frag_off:0 ttl:64 proto:6 (TCP) chk:116 saddr:10.4.50.135:35637 daddr:10.4.50.15:3139
> > klips_debug:ipsec_xmit_encap_once: calling output for <ESP_3DES_HMAC_SHA1>, SA:esp.21010568 at 10.4.50.15
> > klips_debug:ipsec_xmit_encap_once: pushing 16 bytes, putting 20, proto 50.
> > klips_debug:ipsec_xmit_encap_once: head,tailroom: 32,0 before xform.
> > klips_debug:ipsec_alg_esp_encrypt: entering with encalg=3, ixt_e=bf051e5c
> > klips_debug:ipsec_alg_esp_encrypt: calling cbc_encrypt encalg=3 ips_key_e=de446200 idat=dfa30044 ilen=1488 iv=dfa3003c, encrypt=1
> > klips_debug:ipsec_alg_esp_encrypt: returned ret=1
> > klips_debug:ipsec_xmit_encap_once: after <ESP_3DES_HMAC_SHA1>, SA:esp.21010568 at 10.4.50.15:
> > klips_debug: IP: ihl:20 ver:4 tos:8 tlen:1536 id:48130 DF frag_off:0 ttl:64 proto:50 (ESP) chk:36 saddr:10.4.50.135 daddr:10.4.50.15
> > ipsec_sa_put: ipsec_sa dd41c800 SA:esp.21010568 at 10.4.50.15, ref:1 reference count (4--) decremented by ipsec_xmit_cont:1102.
> > klips_debug:ipsec_findroute: 10.4.50.135:0->10.4.50.15: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=0pdfaec100
> > klips_debug:ipsec_xmit_restore_hard_header: After recursive xforms -- head,tailroom: 32,0
> > klips_debug:ipsec_xmit_restore_hard_header: With hard_header, final head,tailroom: 32,0
> > klips_debug:ipsec_xmit_send: ...done, calling ip_send() on device:eth0
> > klips_debug: IP: ihl:20 ver:4 tos:8 tlen:1536 id:48130 DF frag_off:0 ttl:64 proto:50 (ESP) chk:36 saddr:10.4.50.135 daddr:10.4.50.15
> > klips_error:ipsec_xmit_send: ip_send() failed, err=90
> >
> >
> >
> > Regards
> > Ronen Shitrit
> > _______________________________________________
> > Dev mailing list
> > Dev at openswan.org
> > http://lists.openswan.org/mailman/listinfo/dev
> >
> >
>
> --
> David McCullough, david_mccullough at mcafee.com, Ph:+61 734352815
> McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
> _______________________________________________
> Dev mailing list
> Dev at openswan.org
> http://lists.openswan.org/mailman/listinfo/dev
> _______________________________________________
> Dev mailing list
> Dev at openswan.org
> http://lists.openswan.org/mailman/listinfo/dev
>
>
--
David McCullough, david_mccullough at mcafee.com, Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dst.diff
Type: text/x-diff
Size: 1474 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/dev/attachments/20100210/2684d199/attachment.bin
More information about the Dev
mailing list