On Monday 16 July 2007 21:47:40 Patrick McHardy wrote:

I lost interest here, but the reintroduced bugs make me think that
some old version was simply rediffed without even checking the
output and the state initialization also seems to need a bit more work.

Thanks for reviewing the code, really appreciate it (whoa, would have been a 
lot of problems [re-]introduced)! And yes, you're right - it seemed at the 
time easier to just convert the old code to run in the new kernel as it's 
been working fine for us. Quickly scanned the existing (non-interfamily) beet 
implementation, but I guess 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:

quoted

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 *skb, __u16

encap_type) if (x->mode->input(x, skb))
 			goto drop;

-		if (x->props.mode == XFRM_MODE_TUNNEL) {
+		if (x->props.mode == XFRM_MODE_TUNNEL ||
+		    x->props.mode == XFRM_MODE_BEET) {
 			decaps = 1;
 			break;
 		}

I was under the impression that one of the main points of BEET is that
it offers tunnel semantics but does only transport mode processing.
Its necessary for inter-family tunnels, but shouldn't this be avoided
for normal use?

Yes, this is actually quite a nice improvement to the interfamily processing I 
(at least) haven't thought of before. Tested it & works fine (ipv4-ipv4).

quoted

diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
index 44ef208..8db7910 100644
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4/xfrm4_output.c

@@ -53,7 +53,8 @@ static int xfrm4_output_one(struct sk_buff *skb)
 			goto error_nolock;
 	}

-	if (x->props.mode == XFRM_MODE_TUNNEL) {
+	if (x->props.mode == XFRM_MODE_TUNNEL ||
+	    x->props.mode == XFRM_MODE_BEET) {
 		err = xfrm4_tunnel_check_size(skb);

Its not a real tunnel and all packets are generated locally, why
does it need to send ICMPs?

Guess not. I'll have to still trace through, but can probably be removed.

quoted

+		if (xfrm[i]->props.mode != XFRM_MODE_TRANSPORT) {
+			encap_family = xfrm[i]->props.family;
+			if (encap_family == AF_INET) {
+				remote.in = (struct in_addr *)
+					&xfrm[i]->id.daddr.a4;
+				local.in  = (struct in_addr *)
+					&xfrm[i]->props.saddr.a4;
+			} else if (encap_family == AF_INET6) {
+				remote.in6 = (struct in6_addr *)
+					xfrm[i]->id.daddr.a6;
+				local.in6 = (struct in6_addr *)
+					xfrm[i]->props.saddr.a6;
+			}

No ifdefs here?

Thanks for noticing!

quoted

 static int ipip_init_state(struct xfrm_state *x)
 {
-	if (x->props.mode != XFRM_MODE_TUNNEL)
+	if (x->props.mode != XFRM_MODE_TUNNEL ||
+	    x->props.mode != XFRM_MODE_BEET)
 		return -EINVAL;

Looks like a bug fix that should be seperated.

Probably. This has been there for a while, don't know what's the story behind 
it, have to check..

br, j