Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+2\/3\]\s+ipvs\:\s+Fix\s+faulty\s+IPv6\s+extension\s+header\s+handling\s+in\s+IPVS\s*$/: 13 ]

Total 13 documents matching your query.

1. Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: Jesper Dangaard Brouer <brouer@xxxxxxxxxx>
Date: Tue, 04 Sep 2012 23:25:18 +0200
[cut] (small correction ipv6_find_hdr() is not that costly for the general case of no exthdrs) This passing the "struct ip_vs_iphdr" actually makes sense. It reminds me of the way netfilter/iptables
/html/lvs-devel/2012-09/msg00003.html (10,109 bytes)

2. Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: Jesper Dangaard Brouer <brouer@xxxxxxxxxx>
Date: Fri, 31 Aug 2012 12:22:26 +0200
[...cut...] [...cut...] I've been looking at the code for ip6t_do_table() and it already calls ipv6_find_hdr(). ip6t_do_table() calls ip6_packet_match() And ip6_packet_match() already calls ipv6_find
/html/lvs-devel/2012-08/msg00065.html (13,974 bytes)

3. Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: Patrick McHardy <kaber@xxxxxxxxx>
Date: Wed, 29 Aug 2012 14:34:34 +0200 (MEST)
To Patrick, 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 s
/html/lvs-devel/2012-08/msg00057.html (13,346 bytes)

4. Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: Jesper Dangaard Brouer <brouer@xxxxxxxxxx>
Date: Wed, 29 Aug 2012 13:46:10 +0200
To Patrick, Okay, but then I do need some help and guidance, especially from Patrick, think. First of all, where in the netfilter code, should we update the new fields in inet6_skb_parm? -- To unsubs
/html/lvs-devel/2012-08/msg00055.html (12,863 bytes)

5. Re[3]: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: Patrick McHardy <kaber@xxxxxxxxx>
Date: Mon, 27 Aug 2012 14:02:41 +0200 (MEST)
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
/html/lvs-devel/2012-08/msg00028.html (11,754 bytes)

6. Re[3]: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: "Hans Schillstrom" <hans@xxxxxxxxxxxxxxx>
Date: Mon, 27 Aug 2012 13:58:18 +0200 (CEST)
I guess that's the problem, adding it to the skb will not be popular .... Right now I don't have a good solution, maybe a more generic netfilter ptr in the skb ... -- To unsubscribe from this list:
/html/lvs-devel/2012-08/msg00027.html (11,810 bytes)

7. Re[2]: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: Patrick McHardy <kaber@xxxxxxxxx>
Date: Mon, 27 Aug 2012 13:13:44 +0200 (MEST)
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
/html/lvs-devel/2012-08/msg00025.html (11,049 bytes)

8. Re[2]: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: "Hans Schillstrom" <hans@xxxxxxxxxxxxxxx>
Date: Mon, 27 Aug 2012 12:55:14 +0200 (CEST)
I think that would be great, maybe it should be global i.e. not only a netfilter issue. -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@
/html/lvs-devel/2012-08/msg00024.html (10,096 bytes)

9. Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: Patrick McHardy <kaber@xxxxxxxxx>
Date: Sun, 26 Aug 2012 23:13:45 +0200 (MEST)
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
/html/lvs-devel/2012-08/msg00022.html (11,884 bytes)

10. Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Thu, 23 Aug 2012 19:06:33 +0300 (EEST)
Hello, The way you prefer. We can fix it after this patchset. For example: ciph = (struct ip_vs_iphdr) { .len = iph->len + sizeof(_icmph), .saddr = iph->saddr, .daddr = iph->daddr, }; ciph.protocol =
/html/lvs-devel/2012-08/msg00018.html (18,315 bytes)

11. Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: Jesper Dangaard Brouer <brouer@xxxxxxxxxx>
Date: Thu, 23 Aug 2012 14:50:51 +0200
Okay. Wondering if we should keep these cleanup changes to a separate patch. Good catch, I'll re-add the NULL pointer check. (notice that &ciph.len can get updated by ipv6_find_hdr()) I'm not sure I
/html/lvs-devel/2012-08/msg00017.html (23,727 bytes)

12. Re: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Tue, 21 Aug 2012 17:14:49 +0300 (EEST)
Hello, Patch 1 looks ok, following are some small comments for patch 2 and 3. There is already #if IS_ENABLED(CONFIG_IPV6) that can replace #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) It
/html/lvs-devel/2012-08/msg00014.html (19,949 bytes)

13. [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS (score: 1)
Author: Jesper Dangaard Brouer <brouer@xxxxxxxxxx>
Date: Mon, 20 Aug 2012 15:08:40 +0200
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
/html/lvs-devel/2012-08/msg00010.html (78,634 bytes)


This search system is powered by Namazu