Re: [PATCH] check connect(2) status for IPv6 UDP socket
From: Nicolas DICHTEL <[EMAIL PROTECTED]> Date: Thu, 09 Feb 2006 10:39:12 +0100 > Yes, that's what I mean ;-) It was the same problem for not-connected > socket in UDP. Ok, I see. Nicolas, can you resend your patch to me via private email? Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] check connect(2) status for IPv6 UDP socket
Herbert Xu a écrit : David S. Miller <[EMAIL PROTECTED]> wrote: From: Nicolas DICHTEL <[EMAIL PROTECTED]> Date: Mon, 06 Feb 2006 12:00:30 +0100 in the same way of this patch, why dst_entry are stored for RAW socket ? In case of specific IPSec rules for ICMPv6, xfrm state can be different for the same destination. Attached, a proposed patch. We cache the flow we used to store that dst into the socket, and we'll verify that on the next sendmsg() call so it's OK. See the checks done in ip6_dst_lookup() when we have a cached route attached to the socket. I think he's saying that the checks in ip6_dst_lookup is not enough for IPsec because it only checks the destination address and oif instead of all the addresses/protocol/ports. Yes, that's what I mean ;-) It was the same problem for not-connected socket in UDP. Regards, Nicolas - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] check connect(2) status for IPv6 UDP socket
David S. Miller <[EMAIL PROTECTED]> wrote: > From: Nicolas DICHTEL <[EMAIL PROTECTED]> > Date: Mon, 06 Feb 2006 12:00:30 +0100 > >> in the same way of this patch, why dst_entry are stored for >> RAW socket ? In case of specific IPSec rules for ICMPv6, >> xfrm state can be different for the same destination. >> Attached, a proposed patch. > > We cache the flow we used to store that dst into the socket, > and we'll verify that on the next sendmsg() call so it's OK. > > See the checks done in ip6_dst_lookup() when we have a cached > route attached to the socket. I think he's saying that the checks in ip6_dst_lookup is not enough for IPsec because it only checks the destination address and oif instead of all the addresses/protocol/ports. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] check connect(2) status for IPv6 UDP socket
From: Nicolas DICHTEL <[EMAIL PROTECTED]> Date: Mon, 06 Feb 2006 12:00:30 +0100 > in the same way of this patch, why dst_entry are stored for > RAW socket ? In case of specific IPSec rules for ICMPv6, > xfrm state can be different for the same destination. > Attached, a proposed patch. We cache the flow we used to store that dst into the socket, and we'll verify that on the next sendmsg() call so it's OK. See the checks done in ip6_dst_lookup() when we have a cached route attached to the socket. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] check connect(2) status for IPv6 UDP socket
Hi all, in the same way of this patch, why dst_entry are stored for RAW socket ? In case of specific IPSec rules for ICMPv6, xfrm state can be different for the same destination. Attached, a proposed patch. Regards, Nicolas [IPV6] Don't store dst_entry for RAW socket Signed-off-by: Nicolas DICHTEL <[EMAIL PROTECTED]> Mitsuru KANDA a écrit : Hello, I recreated a patch for unconnected udpv6 socket checking. (Fixed forgetting dst refcnt decrement from the previous patch.) Regards, -mk At Thu, 22 Sep 2005 23:44:05 -0700 (PDT), "David S. Miller" <[EMAIL PROTECTED]> wrote: ... I think you're patch adds a route leak. If we elide the ip6_dst_store() where does the 'dst' reference go? In fact, I think the UDPv6 change might have done the same thing. Mitsuru-san? ipv4 code like this does explicit dst_clone() when storeing the 'dst' to the socket, but I can't see where ipv6 is doing this. Perhaps ipv6 dst's work a little differently. :-) --- linux-2.6.15.2/net/ipv6/raw.c 2006-01-31 07:25:07.0 +0100 +++ linux-2.6.15.2-new/net/ipv6/raw.c 2006-02-06 11:46:13.0 +0100 @@ -814,10 +814,7 @@ err = rawv6_push_pending_frames(sk, &fl, rp); } done: - ip6_dst_store(sk, dst, - ipv6_addr_equal(&fl.fl6_dst, &np->daddr) ? - &np->daddr : NULL); - + dst_release(dst); release_sock(sk); out: fl6_sock_release(flowlabel);