[Openswan dev] Openswan 2.6.24 TCP traffic
David McCullough
david_mccullough at mcafee.com
Tue Feb 9 18:26:37 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...
Thats sounds good, though ftp put appears to be working fine for me.
Are you using a windows client ? From memory they insist on the DF stuff
while unix ones don't. Could also be our firwall doing MSS clamping or
something similar to avoid problems like this :-(
If I get time I'll have a look at this too, thanks for tracking it down.
I had been suspecting something like this was gogin on :-)
Cheers,
Davidm
> -----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
More information about the Dev
mailing list