Re[2]: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS

2 messages, 2 authors, 2012-08-27 · open the first message on its own page

Re[2]: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS

From: Hans Schillstrom <hidden>
Date: 2012-08-27 10:55:14

On Mon, 20 Aug 2012, Jesper Dangaard Brouer wrote:
quoted
Based on patch from: Hans Schillstrom

IPv6 headers must be processed in order of appearance,
neither can it be assumed that Upper layer headers is first.
If anything else than L4 is the first header IPVS will throw it.

IPVS will write SNAT & DNAT modifications at a fixed pos which
will corrupt the message. Proper header position must be found
before writing modifying packet.

This patch contains a lot of API changes.  This is done, to avoid
the costly scan of finding the IPv6 headers, via ipv6_find_hdr().
Finding the IPv6 headers is done as early as possible, and passed
on as a pointer "struct ip_vs_iphdr *" to the affected functions.
How about we change netfilter to set up the skb's transport header
at an early time so we can avoid all (most of) these header scans
in netfilter?
I think that would be great, maybe it should be global i.e. not only a netfilter issue.

Re[2]: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS

From: Patrick McHardy <hidden>
Date: 2012-08-27 11:13:44

On Mon, 27 Aug 2012, Hans Schillstrom wrote:
quoted
On Mon, 20 Aug 2012, Jesper Dangaard Brouer wrote:
quoted
Based on patch from: Hans Schillstrom

IPv6 headers must be processed in order of appearance,
neither can it be assumed that Upper layer headers is first.
If anything else than L4 is the first header IPVS will throw it.

IPVS will write SNAT & DNAT modifications at a fixed pos which
will corrupt the message. Proper header position must be found
before writing modifying packet.

This patch contains a lot of API changes.  This is done, to avoid
the costly scan of finding the IPv6 headers, via ipv6_find_hdr().
Finding the IPv6 headers is done as early as possible, and passed
on as a pointer "struct ip_vs_iphdr *" to the affected functions.
How about we change netfilter to set up the skb's transport header
at an early time so we can avoid all (most of) these header scans
in netfilter?
I think that would be great, maybe it should be global i.e. not only a netfilter issue.
I think in most other cases the headers are supposed to be processed 
sequentially. One problem though - to be useful for netfilter/IPVS
we'd also need to store the transport layer protocol somewhere.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help