On 10 April 2016 at 21:02, Ben Warren <b...@skyportsystems.com> wrote: > Hi, > > I’d like to use ALGs other than FTP (TFTP, and another one that I’m writing) > and see several barriers in OVS that appear to be mostly artificial. > Here’s my understanding - please correct where necessary: > > • the command-line parser will only allow “alg=ftp”, and if this is found it > encodes FTP’s control port (21) in the OF message. > • there’s some code in 'lib/ofp-actions.c’ that seems to allow use of other > ports: ‘format_alg()’, but it doesn’t seem to be used anywhere. > • the code where the netlink message to the kernel is constructed > (‘put_connhelper()’ in ofproto-dpif-xlate.c) converts the numeric 21, if > found, into the string “ftp” and sends it to the kernel, and has an error for > any other value. > • kernel code takes the string and does a lookup of registered conntrack > helpers based on name. > > I assume only FTP is allowed because it’s common and easy to test? I don’t > understand why there’s the intermediate numeric translation, since both ends > (command line and kernel code) work with a string. Why not allow an > arbitrary string (with a length limit) to go all the way through? Is the > concern that it’s hard to properly return errors if an invalid string is > entered? > > I’ll get started on coding up a patch, but am really interested in > understanding the design decision.
Right, FTP is just allowed because it's common/easy to test and it's a good proof of concept to look at the semantics around the "related" ct_state bit. I actually have a (very short) patch sitting around for TFTP support as well which I haven't pushed out yet because I haven't got around to writing up some tests for it yet. Well, and getting distracted by other things ;-) I wouldn't say there was a single strong consideration for exposing the ALG as a well-known port number, but a few smaller thoughts, such as: * Just because Linux exposes the ALG support as a string in the datapath interface doesn't mean all datapaths do. For example, this allows userspace datapath to avoid working with strings when support is added there. * The commandline interface wasn't considered for the OpenFlow API at all; commandline usability benefits from string representations, regardless of what sits behind it. * A 16-bit identifier was slightly simpler to encode in the (already variable-length) message. * To reflect an error during OpenFlow rule installation up to the controller (such as no support for this ALG), the ALG support would need to be probed in the datapath. In OVS this probing occurs during datapath creation, not rule installation, so all supported ALGs would need to be known ahead of time anyway. (We don't currently probe for ALG support, but this would be a fairly minimal extension that would provide more information to controllers) * The set of possible ALGs is not thought to be expanding: Making the code more flexible for continually adding new ALG support was not a consideration. The rough idea being once a limited set of ALGs are added, it's pretty much done. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
