On 9 July 2015 at 04:59, John Hurley <john.hur...@netronome.com> wrote: > Hi, > > I have a few queries about the use of helper functions in ovs-conntrack. > I've tried multiple tests and cannot get the ftp expected flows to work > correctly. > > As an example, take the following rules: > > ovs-ofctl add-flow br0 "tcp,conn_state=-trk,action=ct(recirc)" > ovs-ofctl add-flow br0 > "priority=11,tcp,conn_state=+trk+new,action=ct(alg=ftp,commit),2" > ovs-ofctl add-flow br0 > "priority=12,tcp,conn_state=+trk+new+rel,action=ct(commit),2" > ovs-ofctl add-flow br0 "priority=11,tcp,conn_state=+trk-new+rel,action=2" > ovs-ofctl add-flow br0 "priority=10,tcp,conn_state=+trk-new,action=2" > > For an ftp session I would expect all packets to hit the top rule, new flows > to recirculate and be committed to the Conntrack tables with the ftp helper > assigned (nf_conntrack_ftp is running). Then the following packets in that > flow should have the helper function applied to them. New or realated flows > spawned from the controol channel should be picked up by the 3rd and 4th > rule. In my tests only the 1st, 2nd and last rule are hit. Is my > interpretation correct?
Your interpretation sounds correct. The main strange thing I see is that you aren't matching on in_port. So it seems like all of your packets will always go out port 2. If the control connection cannot be established, or if the relevant messages are not passing through conntrack, then it might not identify the FTP connection. There's a couple of examples in the "FTP" kernel module test from tests/kmod-traffic.at, perhaps you'll find this useful: https://github.com/justinpettit/ovs/blob/8aeba8479754750a0c0f8adc05458707ff301d44/tests/kmod-traffic.at#L473 Other useful debugging pieces would be things like: - Once you've run the test, is the nf_conntrack_ftp module loaded? - What does ovs-dpctl dump-flows show? - What packets do you see flow through OVS? > From tracing some of the code I can see that the helper is assigned > correctly on the first packet of a flow but this is not maintained across > following packets. These all fail to implement the helper function due to > the call of nfct_help(ct) returning NULL. The help function will be > correctly applied to each packet if a 'commit' is not used to in the 2nd > rule as all packets are assumed new and assigned the helper in the > nf_conntrack_in function. But doing this means that the state information is > incorrect for the packet and it will fail to match in nf_conntrack_ftp. The way that the templates work is that there is one template created when the flow is first created in the kernel. The FTP helper is attached to this template. For all of the packets which match this flow, they will take the template and use it for conntrack lookup - whether this is a new packet or a subsequent packet. If it's a new connection, that should allow the new connection tracking entry to inherit the helper from the template and use it; if it's an existing connection, then conntrack lookup should find a conntrack entry which has the helper associated. Does that make sense? > I would also like to understand more about the use of a nf_conntrack > template. It seems that the use of 'alg=ftp' is only for copying the correct > helper to a template that is set up with a new rule - the ftp helper module > will be added automatically based on port number in nf_conntrack_in? The > helper seems to be added to the template correctly but is never used again > from what I can see. The helper module is not based on port number, but based on a string literal passed through the OVS netlink interface. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
