"dsrtools" now available on "beta" branch

[qbarnes]

The beta branch now has dsrtools available.

dsrtools is a replacement for yvipagent. We've been using this tool internally for several years now on our RHEL 6 and RHEL 7 production systems.

As part of this latest update to beta, the tree has been reorganized. The directories and files that were immediately under the linux directory are now in a subdirectory named iptables-daddr. Also under linux is dsrtools.

Under the dsrtools directory, you'll find README, INSTALL, and USING documentation as well as man pages under the src directory for dsrctl(8) and dsr.conf(5).

Also under dsrtools is a tests directory. It is an extensive suite of tests. These tests can be used to validate changes to dsrtools to ensure they don't introduce regressions.

dsrtools is necessary for newer versions of iptables-daddr (1.9.0 and later) that use the raw table by default. If you wish to continue to use yvipagent, you'll have to force your version of iptables-daddr back to mangle. See Issue #5 on how to do that.

yvipagent is still available for now in the repository, but will be deprecated in a future release.

If you do any testing with these latest updates on the beta branch, for please let us know how it goes, for good or bad.

Once we get enough feedback, we'll merge the beta branch to master.

If you find any problems or have any questions with dsrtools, feel free to ask them here or contact Wayne Badger (badger@verizonmedia.com) or Quentin Barnes (qbarnes@verizonmedia.com).

[qbarnes]

If you build iptables-daddr for RHEL 8 with mock, note that the build will fail due to the %kernel_module_package macro missing. The macro used to be in /usr/lib/rpm/redhat/macros provided by redhat-rpm-config, which was in mock's 'chroot_setup_cmd' list.

Now %kernel_module_package macro is in the /usr/lib/rpm/macros.d/macros.kmp file which is provided by the kernel-rpm-macros package which is at present not in mock's 'chroot_setup_cmd' list. I'm currently working with mock's upstream devs to find the best solution for this shortcoming.

This problem is also present in later versions of Fedora, but will require a different long-term solution.

In the mean time, either alter your mock config file or use the --install option to mock to provide the kernel-rpm-macros package.

[dmitris]

@qbarnes - is this issue with kernel-rpm-macros package a show-stopper for merging the beta branch into master? Oe are there (other) reasons to hold it back for now?

[qbarnes]

The only problem had to do with the difference in https://github.com/yahoo/l3dsr/blob/beta/linux/iptables-daddr/kmod-xt/xt_DADDR.c between how inet_proto_csum_replace4() vs. inet_proto_csum_replace16() was being called.

On the beta branch, if you notice when calling inet_proto_csum_replace4(), the 5th argument (pseudohdr) is a "1". To me, it made sense for it to be a 1(true).

However, when calling inet_proto_csum_replace16(), its 5th argument (pseudohdr) is a "0". To me, this made no sense. Also, no where else in the kernel source is the function ever called with a 0 (false).

For months in our production environment, I exhaustively tested the code as it is on the beta branch with several different manufacturers and models of smart NICs including the challenging Mellanox MT27710 and several of its firmware versions. I found no problems at all with the driver. I also tested the code tinkering with the pseudohdr parameter to ensure that the code as it is on the beta branch must be exactly as it is to work for the way the code is written.

However, the unexplained difference in the pseudohdr parameter still concerned me. I was thinking that I was something important I wasn't understanding and that would come back to bite me. I wanted to dive deeper into understanding the interaction of the kernel algorithms with the networking stack's use of pseudo headers, but didn't get a chance with my other higher priority tasks.

Considering though that all the exhaustive testing came back good and the beta code was certainly testing better (less buggy) than what was on master, I had planned to just go ahead and merge beta to master. But Verizon Media and I parted ways last month, and that was one of many things that didn't get finished up in time. Since @wbadger's code is also in the mix as well, I'll check with him to see if he'd be up for the merging in my stead.

[qbarnes]

Back on your question about kernel-rpm-macros. The more I dug, the deeper the rabbit hole went.

I checked with the mock maintainers. After some back and forth, they convinced me it's not a bug with mock. What mock delivers is what the OS dev teams already choose to do in their respective build environments. The most correct fix then is to address the shortcoming with Red Hat, CentOS, and Fedora system maintainers. Once the problem is addressed there, it would be reflected back in mock's configuration for those systems.

Working with the Red Hat, CentOS, and Fedora system maintainers to address this problem is another one of those tasks that fell on the floor before my exit.

If/When users using mock to build l3dsr hit the kernel-rpm-macros problem, they'll need to push back to their OS devs, and/or they'll have to hack their mock configuration to work around the OS bug.