On 10/19/15 at 04:13pm, Joe Stringer wrote:
> I think that the proper solution instead of this patch is to set NEW
> if !nf_ct_is_confirmed(ct). This is more accurately the meaning for
> 'NEW' that we are actually trying to expose. As long as this is done
> before confirming the connection during a
On 19 October 2015 at 02:03, Thomas Graf wrote:
> On 10/19/15 at 12:07am, Joe Stringer wrote:
>> > I'm probably missing something obvious. Why is the reply direction
>> > not considered NEW? Wouldn't this consider an ICMPv6 as related+new
>> > depending on simply the direction?
>>
>> My thoughts w
On 10/19/15 at 12:07am, Joe Stringer wrote:
> > I'm probably missing something obvious. Why is the reply direction
> > not considered NEW? Wouldn't this consider an ICMPv6 as related+new
> > depending on simply the direction?
>
> My thoughts were along the lines "If something is a reply, that
> im
On 17 October 2015 at 00:52, Thomas Graf wrote:
> On 10/16/15 at 11:08am, Joe Stringer wrote:
>> New, related connections are marked as such as part of ovs_ct_lookup(),
>> but they are not marked as "new" if the commit flag is used. Make this
>> consistent by treating IP_CT_RELATED as new as well.
On 10/16/15 at 11:08am, Joe Stringer wrote:
> New, related connections are marked as such as part of ovs_ct_lookup(),
> but they are not marked as "new" if the commit flag is used. Make this
> consistent by treating IP_CT_RELATED as new as well.
>
> Reported-by: Jarno Rajahalme
> Signed-off-by: J
New, related connections are marked as such as part of ovs_ct_lookup(),
but they are not marked as "new" if the commit flag is used. Make this
consistent by treating IP_CT_RELATED as new as well.
Reported-by: Jarno Rajahalme
Signed-off-by: Joe Stringer
Acked-by: Pravin B Shelar
---
v2: Acked.
-
