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 *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).
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 inner packet as they don't get processed after being
extracted from the pseudoheader. Calling something like ip_options_compile
from beet_mode's input when handling ipv4 would do the trick, but seems a bit
ugly & perhaps unsafe, I'd rather just put the whole packet through the loop
again.
br, j
-
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
