Hi Herbert,
Have you had a chance to look this, or are you working on something else for
it?
On Friday 08 February 2008 18:12, Joakim Koskela wrote:
Hi,
This patch fixes the ipv6 mode of ipsec beet. It has been using logic
similar to tunnel mode, making it crash during esp packaging
Hi,
This patch fixes the ipv6 mode of ipsec beet. It has been using logic
similar to tunnel mode, making it crash during esp packaging.
Signed-off-by: Joakim Koskela [EMAIL PROTECTED]
---
net/ipv6/xfrm6_mode_beet.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git
On Friday 19 October 2007 17:25:49 Herbert Xu wrote:
Joakim Koskela [EMAIL PROTECTED] wrote:
I'm not sure I follow. This affects the ipv6 bundling only where the
struct (fl_tunnel) has previously been used for ipv6 addresses. Not that
we are using the same block for holding the ipv4 info
On Friday 19 October 2007 17:22:22 Herbert Xu wrote:
Please hold onto this. I've got a more generic version of this
that doesn't duplicate the inter-family logic between BEET mode
and tunnel mode.
Instead I've created a generic function that reads info from the
inner header and puts them
On Friday 19 October 2007 15:55:55 Herbert Xu wrote:
While I agree that this is definitely a problem, I've already
got a solution for it which we happen to need for async crypto
anyway.
Basically xfrm_output will invoke a continuation function based
on the external mode/family which will
that both address pairs in the SA
were of the same family. This patch enables mixing ipv4 and ipv6
addresses. All combinations (4-4, 4-6, 6-4, 6-6) have been tested.
The generic interfamily fixes have been chopped off from this into
separate patches.
Signed-off-by: Joakim Koskela [EMAIL PROTECTED
the larger patch dealing with the problems
related to creating the bundles for inter-family tranformations.
Signed-off-by: Joakim Koskela [EMAIL PROTECTED]
--
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index 82e27b8..386a762 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6
output to be
based on the current address family of the packet instead of what it
will be transformed to.
Signed-off-by: Joakim Koskela [EMAIL PROTECTED]
---
diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
index c4a7156..8b0c6bd 100644
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4
On Friday 19 October 2007 16:09:05 Herbert Xu wrote:
On Fri, Oct 19, 2007 at 02:40:16PM +0300, Joakim Koskela wrote:
This bit was chopped off the larger patch dealing with the problems
related to creating the bundles for inter-family tranformations.
This changes behaviour. Previously
On Friday 14 September 2007 23:42:52 David Miller wrote:
From: Joakim Koskela [EMAIL PROTECTED]
Date: Thu, 6 Sep 2007 19:00:10 +0300
This patch addresses a couple of issues related to interfamily ipsec
modes. The problem is that the structure of the routing info changes
with the family
of these structs could comment.
Signed-off-by: Joakim Koskela [EMAIL PROTECTED]
---
diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
index 4ff8ed3..7410c0d 100644
--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@ -72,6 +72,7 @@ __xfrm4_bundle_create(struct xfrm_policy *policy
Hi,
Does anybody know of any effort put into implementing support for the TCP user
timeout option in Linux?
The related draft:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-06.txt
Basically its a per-connection parameter which says how long data can remain
unacknowledged before
On Friday 03 August 2007 01:01:14 David Miller wrote:
Joakim, TEST YOUR PATCHES, and not just with your BEET test cases,
before submitting them in the future. Having normal configurations of
both PF_KEY and XFRM_USER ipsec totally break as a result of your
changes is totally unacceptable and
On Tuesday 17 July 2007 17:30:21 Joakim Koskela wrote:
Joakim Koskela wrote:
diff --git a/net/ipv4/xfrm4_input.c b/net/ipv4/xfrm4_input.c
index fa1902d..7a39f4c 100644
--- a/net/ipv4/xfrm4_input.c
+++ b/net/ipv4/xfrm4_input.c
@@ -108,7 +108,8 @@ int xfrm4_rcv_encap(struct sk_buff
On Monday 06 August 2007 15:08:12 Patrick McHardy wrote:
It's been a while, but as a fyi in case there are comments / suggestions
before submitting the whole patch again - it seems that this had some
problems after all. Works ok for normal cases, but fails when using ip
options for the
On Thursday 19 July 2007 17:46:42 Patrick McHardy wrote:
Joakim Koskela wrote:
+ skb_push(skb, hdrlen);
+ iphv6 = ipv6_hdr(skb);
+
+ skb_reset_network_header(skb);
+ top_iphv6 = ipv6_hdr(skb);
+
+ protocol = iphv6-nexthdr
On Tuesday 31 July 2007 13:51:42 Patrick McHardy wrote:
Joakim Koskela wrote:
I'm not sure I really got this. IPv6/IPv4 means IPv6 inner, IPv4 outer,
right? Isn't that called from xfrm4_output_one and subsequently passed
through the right filters as well (as it has a ipv4 header
On Tuesday 31 July 2007 14:14:30 Patrick McHardy wrote:
Joakim Koskela wrote:
Ok, so changing int xfrm[46]_output(struct sk_buff*) to use the right PF
hook based on the skb's [current] family should put things through the
right hoops, right?
Almost, in xfrm4_output the conditional
This patch modifies the xfrm state selection logic to use the inner
addresses where the outer have been (incorrectly) used. This is
required for beet mode in general and interfamily setups in both
tunnel and beet mode.
Signed-off-by: Joakim Koskela [EMAIL PROTECTED]
Signed-off-by: Herbert Xu
implementation required that both address pairs in the SA
were of the same family. This patch enables mixing ipv4 and ipv6
addresses. All combinations (4-4, 4-6, 6-4, 6-6) have been tested
using manual key setups.
Signed-off-by: Joakim Koskela [EMAIL PROTECTED]
Signed-off-by: Herbert Xu [EMAIL
On Thursday 19 July 2007 17:46:42 Patrick McHardy wrote:
-
+ if (xfrm[i]-props.mode != XFRM_MODE_TRANSPORT) {
+ encap_family = xfrm[i]-props.family;
+ if (encap_family == AF_INET) {
+ remote.in = (struct in_addr *)
not thoroughly enough. Anyway, merged back the
latest non-interfamily versions and rolling with those now. Should have a
fixed version ready soon..
Some other comments:
Joakim Koskela wrote:
diff --git a/net/ipv4/xfrm4_input.c b/net/ipv4/xfrm4_input.c
index fa1902d..7a39f4c 100644
The previous implementation required that both address pairs in the SA
were of the same family. This patch enables mixing ipv4 and ipv6
addresses. All combinations (4-4, 4-6, 6-4, 6-6) have been tested
using manual key setups.
Signed-off-by: Joakim Koskela [EMAIL PROTECTED]
Signed-off-by: Herbert Xu
address pairs in the SA
were of the same family. This patch enables mixing ipv4 and ipv6
addresses. All combinations (4-4, 4-6, 6-4, 6-6) have been tested
using manual key setups.
Signed-off-by: Joakim Koskela [EMAIL PROTECTED]
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Signed-off-by: Diego
).
Signed-off-by: Joakim Koskela [EMAIL PROTECTED]
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Signed-off-by: Diego Beltrami [EMAIL PROTECTED]
Signed-off-by: Miika Komu [EMAIL PROTECTED]
---
diff --git a/net/ipv4/xfrm4_input.c b/net/ipv4/xfrm4_input.c
index 5ceca95..969d79d 100644
--- a/net
On Friday 11 May 2007 19:13:41 Patrick McHardy wrote:
Joakim Koskela wrote:
I'm running a system where there might be multiple simultenously
active ipsec states between two hosts (ipv6, but guess it applies to
v4 as well) where the outer ip is the same for all states, but the
inner differ
, j
--
Joakim Koskela
Helsinki Institute for Information Technology, http://www.hiit.fi
-
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
27 matches
Mail list logo
