For those that don't know, netfirc provides an apipa.sh module that is intended to implement APIPA (RFC 3927). This entails provisioning an interface with a random IPv4 address from the reserved 169.254.0.0/16 block, provided that it is found not to be in use. Unfortunately, the implementation in netifrc doesn't work. It contains a _random() function which is never executed because Roy employed invalid command substitution syntax and never noticed his mistake. So, what happens at present is that, if a user tries to use this module, arping will be needlessly executed exactly 64516 times, with no address ever being considered as a valid candidate. It also has the following issues: • there are actually 65534 valid candidates, not 64516 • the main loop is painfully slow • it relies on bash for entropy, falling back to a non-standard utility In summary, it is broken and, in my estimation, not written to a particularly high standard. I have re-written it and shall attach a patch for review soon.
Hi Lars. I'm copying you in as previously discussed. Hi Steve. I hope you are well. I'm copying you in because you were the original reporter of this bug way back when and I rewrote it just for you. It is only now that I am finally getting around to formally reporting it.
Created attachment 684522 [details, diff] netifrc-net-apipa.sh-fix-broken-implementation.patch See the lengthy commit message and code comments for further details.
Following a caffeine dose, it occurs to me that it's actually possible to do what I'm doing without a temp file and simplify the patch. I'll attach a revised one shortly.
Created attachment 684528 [details, diff] netifrc-net-apipa.sh-fix-broken-implementation-r1.patch Here is the revised patch, as promised. Please ignore the previous one and review this one. Thank you.
My apologies. Now that I've got a non-hanging net-misc/iputils per bug 766974 and been able to test the latest patch properly, I just realised that I introduced a silly regression that didn't exist in the first version of my patch. My third and final patch will be attached momentarily. (In case anyone cares, I forgot to enclose the "exit 1" statement within the scope of a relevant compound command. Easy fix.)
Created attachment 684543 [details, diff] netifrc-net-apipa.sh-fix-broken-implementation-r2.patch New patch, from the "third time's the charm" department.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/netifrc.git/commit/?id=31a05f1b3fb90a3b4e9c0e587bdd5a39e8236f6b commit 31a05f1b3fb90a3b4e9c0e587bdd5a39e8236f6b Author: Kerin Millar <kfm@plushkava.net> AuthorDate: 2021-01-25 02:40:29 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2021-01-27 14:05:54 +0000 net/apipa.sh: fix broken implementation by way of a rewrite Sadly, the present implementation has never functioned correctly. The original author employed incorrect syntax for what was intended to be a command substitution. As a result, the _random() function is never called. What actually happens is that arping is needlessly executed exactly 64516 times, with no address ever being considered as a valid candidate. Furthermore, this module has other bugs and is poorly designed. Here are the reasons as to why:- • the 169.254.0.0/16 block offers 65534 addresses, not 64516 • the main loop is horrendously slow at enumerating the address block • it counts to 64516 but doesn't ensure that each address is unique! • it prefers bash for generating entropy (fine, but non-standard) • it falls back to a non-standard utility for generating entropy Therefore, I decided to re-write most of it. The fundamental difference is that all 65534 octet pairs are generated up front before being processed by the main loop. At most, every possible address will now be tested exactly once. In fact, this approach turns out to be faster by an order of magnitude. The following synthetic tests - which calculate the time taken to enumerate the entire address space - demonstrate the tremendous difference between the existing code and mine. Of course, to ensure that the comparison was meaningful, I rectified the command substitution bug in the existing code. # time bash apipa-old-test.sh real 2m34.367s user 1m9.959s sys 1m37.502s # time bash apipa-new-test.sh real 0m1.119s user 0m0.965s sys 0m0.182s Note that the new _random_apipa_octets() function is responsible for generating all 65534 combinations of octet pairs in a random order. It mainly relies on awk(1) and sort(1). Where possible, a seed is obtained from /dev/urandom for the benefit of awk's RNG, but this is not required. I have isolated and tested the new functions on GNU/Linux, macOS, FreeBSD, NetBSD, OpenBSD and MirBSD. I have individually tested gawk, mawk, nawk, busybox awk and the awk implementations provided by the previously mentioned operating systems in the case that they are distinct. The only incompatiblity that I was personally able to find was with the awk implementation of MirBSD, which affects the final invocation of awk in the _random_apipa_octets function. However, MirBSD was forked from an old version of OpenBSD and seems sufficiently obscure so as not to be worth worrying about. If someone should try to integrate netifrc into MirBSD one day then the matter can be dealt with then. Finally, I want to thank Steve Arnold for bringing the original bug to my attention. Congratulations, Steve. You may be the only known user of net/apipa.sh on the planet. Signed-off-by: Kerin Millar <kfm@plushkava.net> Reported-by: Steve Arnold <nerdboy@gentoo.org> Closes: https://bugs.gentoo.org/766890 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> net/apipa.sh | 94 +++++++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 67 insertions(+), 27 deletions(-)
