Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\s+1\/2\]\s+IPVS\s+Bug\s+IPv6\s+extension\s+header\s+handling\s+faulty\.\s*$/: 8 ]

Total 8 documents matching your query.

1. Re: [PATCH 1/2] IPVS Bug IPv6 extension header handling faulty. (score: 1)
Author: Hans Schillstrom <hans@xxxxxxxxxxxxxxx>
Date: Fri, 2 Mar 2012 13:18:17 +0100
I have big problems with some "corner cases" with ICMPv6 the localhost thing makes it real hard to determine where to send ... I'm testing ICMPv6 packet to big right now. mtu 1500 on incoming iface e
/html/lvs-devel/2012-03/msg00000.html (14,615 bytes)

2. Re: [PATCH 1/2] IPVS Bug IPv6 extension header handling faulty. (score: 1)
Author: Hans Schillstrom <hans@xxxxxxxxxxxxxxx>
Date: Thu, 23 Feb 2012 10:46:07 +0100
Another solution which might be more clear is to make conn_schedule() fragment aware then the "&& !iph.fragoffs" check can be removed. PACKET_TO_BIG needs to be sent at least making conn_schedule() f
/html/lvs-devel/2012-02/msg00018.html (16,318 bytes)

3. Re: [PATCH 1/2] IPVS Bug IPv6 extension header handling faulty. (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Thu, 23 Feb 2012 11:03:52 +0200 (EET)
Hello, OK, then let's just keep the !cp check and later if cp is NULL just to NF_ACCEPT packets with iph.fragoffs != 0, the check should be before calling conn_schedule. In the case after calling ip_
/html/lvs-devel/2012-02/msg00017.html (15,022 bytes)

4. Re: [PATCH 1/2] IPVS Bug IPv6 extension header handling faulty. (score: 1)
Author: Hans Schillstrom <hans@xxxxxxxxxxxxxxx>
Date: Thu, 23 Feb 2012 08:34:23 +0100
cp = pp->conn_in_get(af, skb, &iph, 0); if (unlikely(!cp) && !iph.fragoffs) { No it is working pretty well, because conn_in_get() is fragment aware. if cp is null it's a new connection and in that ca
/html/lvs-devel/2012-02/msg00016.html (21,470 bytes)

5. Re: [PATCH 1/2] IPVS Bug IPv6 extension header handling faulty. (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Thu, 23 Feb 2012 01:16:35 +0200 (EET)
Hello, I see, ip_vs_skb_hdr_ptr needs it. This is not going to work. You are trying to track any locally delivered fragments. If cp is NULL it will crash. There is no need to add check for !iph.frago
/html/lvs-devel/2012-02/msg00015.html (18,381 bytes)

6. Re: [PATCH 1/2] IPVS Bug IPv6 extension header handling faulty. (score: 1)
Author: Hans Schillstrom <hans@xxxxxxxxxxxxxxx>
Date: Wed, 22 Feb 2012 08:46:52 +0100
That's true offs, fragoffs and flags can be skipped. Maybe fragoffs still should be set to zero... because it is used in some places I mean for future changes, (it's not needed today) Like this place
/html/lvs-devel/2012-02/msg00014.html (18,833 bytes)

7. Re: [PATCH 1/2] IPVS Bug IPv6 extension header handling faulty. (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Wed, 22 Feb 2012 03:07:54 +0200 (EET)
Hello, May be there is no need ip_vs_fill_ip4hdr to initialize the new fields that are IPv6 specific. Can we avoid adding ports to ciph.len? May be we can use the offset var and to provide it to ip_v
/html/lvs-devel/2012-02/msg00013.html (14,421 bytes)

8. [PATCH 1/2] IPVS Bug IPv6 extension header handling faulty. (score: 1)
Author: Hans Schillstrom <hans.schillstrom@xxxxxxxxxxxx>
Date: Tue, 14 Feb 2012 13:48:08 +0100
IPv6 headers must be processed in order of apperence, 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 SNA
/html/lvs-devel/2012-02/msg00010.html (86,379 bytes)


This search system is powered by Namazu