----- Original Message -----
> From: "Joe Stringer" <j...@ovn.org>
> To: "Lance Richardson" <lrich...@redhat.com>
> Cc: "ovs dev" <dev@openvswitch.org>
> Sent: Tuesday, May 31, 2016 8:29:44 PM
> Subject: Re: [ovs-dev] conntrack - FTP test case failure
>
> On 31 May 2016 at 15:54, Lance Richardson <lrich...@redhat.com> wrote:
> > With a recent kernel (4.6-ish) and current OVS master, I'm seeing failures
> > in several system-traffic.at test cases under "make check-kernel".
> >
> > For the "conntrack - FTP" test failure, all seems to be well up to the
> > last test case, which is a passive FTP request with flows2.txt policy
> > installed.
> >
> > The test case is expecting the output of "ovs-appctl dpctl/dump-conntrack"
> > to include two entries matching:
> >
> > tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=<cleared>,dport=<cleared>),reply=(src=10.1.1.2,dst=10.1.1.1,sport=<cleared>,dport=<cleared>),protoinfo=(state=TIME_WAIT)
> > tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=<cleared>,dport=<cleared>),reply=(src=10.1.1.2,dst=10.1.1.1,sport=<cleared>,dport=<cleared>),protoinfo=(state=TIME_WAIT),helper=ftp
> >
> > But it is finding:
> >
> > tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=34148,dport=21),reply=(src=10.1.1.2,dst=10.1.1.1,sport=21,dport=34148),protoinfo=(state=TIME_WAIT),helper=ftp
> > tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=38742,dport=39537),reply=(src=10.1.1.2,dst=10.1.1.1,sport=39537,dport=38742),protoinfo=(state=TIME_WAIT),helper=ftp
> >
> > So the test case is expecting only one of the two entries to have
> > "helper=ftp" attached, but is finding that both have "helper=ftp".
> >
> > Should both the control and data connections have "helper=ftp"
> > in the passive FTP case? It seems plausible to me (based on very
> > limited experience with ovs+conntrack) that they should since both
> > are initiated on port 1 and the installed rules don't seem to care
> > about TCP ports:
> >
> > priority=1,action=drop
> > priority=10,arp,action=normal
> > priority=10,icmp,action=normal
> > priority=100,in_port=1,tcp,ct_state=-trk,action=ct(table=0)
> > priority=100,in_port=1,tcp,ct_state=+trk+new,action=ct(commit,alg=ftp),2
> > priority=100,in_port=1,tcp,ct_state=+trk+est,action=2
> > priority=100,in_port=2,tcp,ct_state=-trk,action=ct(table=0)
> > priority=100,in_port=2,tcp,ct_state=+trk+new+rel,action=ct(commit),1
> > priority=100,in_port=2,tcp,ct_state=+trk+est,action=1
> > priority=100,in_port=2,tcp,ct_state=+trk-new+rel,action=1
>
> Hi Lance,
>
> Can you tell me if you have commit 16ec3d4fbb96 ("openvswitch: Fix
> cached ct with helper.") in your Linux tree? This fixes a bug, which
> also causes this test to fail. The test actually looks for the buggy
> behaviour, and it should be updated.
>
I do have 16ec3d4fbb96 (looking closer, my "4.6-ish" kernel is
actually a net-next kernel pulled on May 20).
> Strictly speaking the flow table as above should attach the "FTP" ALG
> to both the control and data connections for the FTP session, however
> due to the above bug this was not guaranteed to occur. When the data
> connection goes through the datapath and flows are already created,
> the initial ct() will create a conntrack entry, then the
> ct(commit,alg=ftp) would fail to attach the FTP alg, leading to one of
> the connections not reporting that it's attached.
>
> We haven't backported this fix quite yet, but we should do that soon,
> and update the tests.
>
> For reference, I'm trying a kernel with the above commit and I'm
> getting similar sorts of failures for the following tests:
>
> conntrack - FTP
> conntrack - FTP with multiple expectations
>
Yes, I'm seeing those fail as well.
Makes sense, thanks for the explanation!
Regards,
Lance
> Cheers,
> Joe
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
