On 17 October 2015 at 00:52, Thomas Graf <tg...@suug.ch> 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. >> >> Reported-by: Jarno Rajahalme <jrajaha...@nicira.com> >> Signed-off-by: Joe Stringer <joestrin...@nicira.com> >> Acked-by: Pravin B Shelar <pshe...@nicira.com> >> --- >> v2: Acked. >> --- >> net/openvswitch/conntrack.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c >> index 80bf702715bb..480dbb9095b7 100644 >> --- a/net/openvswitch/conntrack.c >> +++ b/net/openvswitch/conntrack.c >> @@ -86,6 +86,8 @@ static u8 ovs_ct_get_state(enum ip_conntrack_info ctinfo) >> ct_state |= OVS_CS_F_ESTABLISHED; >> break; >> case IP_CT_RELATED: >> + ct_state |= OVS_CS_F_NEW; >> + /* Fall through */ >> case IP_CT_RELATED_REPLY: >> ct_state |= OVS_CS_F_RELATED; >> break; > > 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 implies that state is held, and therefore it cannot be NEW (where NEW means no state is available)". However, if you consider that the 'related' connection is an independent connection with its own state, but the 'reply' bit refers to the original connection, my original premise breaks. Furthermore, looking at how it's used in netfilter core and the ICMP proto handler, it looks like both of these cases should be considered NEW. I can respin. Do you have a specific case in mind here? It would be useful for extending the OVS testsuite. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
