Joakim Koskela wrote:
> 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 u
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
Joakim Koskela wrote:
> On Tuesday 17 July 2007 17:30:21 Joakim Koskela wrote:
>
@@ -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) {
+
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
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 condition
Joakim Koskela wrote:
> 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
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 by th
Joakim Koskela wrote:
> 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);
>>>+
>>>+
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->next
Joakim Koskela wrote:
On Thursday 19 July 2007 17:46:42 Patrick McHardy wrote:
And these two? Also look like bugfixes ..
Well yes if we're using interfamily anywhere. D'you think they deserve a patch
for themselves?
Yes, that looks worth it. And it will help reduce the size of
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 i
Joakim Koskela wrote:
> static int xfrm4_beet_output(struct xfrm_state *x, struct sk_buff *skb)
> {
[... ipv4 handling, looks fine ...]
> +#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
> + int delta = sizeof(struct ipv6hdr) - sizeof(struct iphdr);
> + u8 proto
Hi all,
Here's once again a corrected version of the patch adding support for
ipv4/ipv6 interfamily addressing for the ipsec BEET (Bound End-to-End
Tunnel) mode, as specified by the ietf draft found at:
http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-07.txt
The previous implemen
From: "Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]>
Date: Mon, 16 Jul 2007 09:56:59 -0300
> Sorry for not commented that the code you were using (and David said
> it was invalid) is in fact valid:
>
> skb->transport_header = skb->network_header;
>
> This works for both offsets and p
Joakim Koskela wrote:
> On Monday 16 July 2007 21:47:40 Patrick McHardy wrote:
>
>>>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(str
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,
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, s
On 7/16/07, Joakim Koskela <[EMAIL PROTECTED]> wrote:
Hi all,
Here's again a cleaned-up and corrected version of the patch adding
support for ipv4/ipv6 interfamily addressing for the ipsec BEET (Bound
End-to-End Tunnel) mode, as specified by the ietf draft found at:
http://www.ietf.org/internet
Hi all,
Here's again a cleaned-up and corrected version of the patch adding
support for ipv4/ipv6 interfamily addressing for the ipsec BEET (Bound
End-to-End Tunnel) mode, as specified by the ietf draft found at:
http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-07.txt
The previou
From: Joakim Koskela <[EMAIL PROTECTED]>
Date: Thu, 12 Jul 2007 12:25:23 +0300
> This (resubmitted) patch adds support for ipv4/ipv6 interfamily
> addressing for the ipsec BEET (Bound End-to-End Tunnel) mode, as
> specified by the ietf draft found at:
>
> http://www.ietf.org/internet-drafts/draft
Hi,
This (resubmitted) patch adds support for ipv4/ipv6 interfamily
addressing for the ipsec BEET (Bound End-to-End Tunnel) mode, as
specified by the ietf draft found at:
http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-07.txt
The previous implementation required that both addres
21 matches
Mail list logo
