The arping utility provided by net-misc/iputils can hang forever if invoked upon a link that has no carrier. It's not clear why this is because the arping.sh module specifies -w 5, meaning that it ought to time out after five seconds. This is going to be an issue once the apipa.sh module is fixed because it interacts heavily with the arping_address() function. That is, for a user to configure an interface to use apipa then start it will result in netifrc hanging indefinitely in the absence of a carrier. I don't have a suggestion as to how to fix this yet, but intend to look into it further once bug 766890 has been addressed.
So, the stable version of iputils, which is 20190709, has this bug. Version 20200821 does not. Time for a stabilisation request. Even so, enumerating an entire /16 block in the case that there is no carrier - and with a 5 second delay between each probe - is going to be very unproductive. As previously stated, I'll consider the options once my apipa.sh rewrite has been reviewed.
My fear regarding the enumeration of the "entire /16 block" is unfounded. Using iputils-20200821, all that happens in the case of NO-CARRIER is that arping (correctly) times out after 5 seconds, exiting non-zero. Given the revised apipa.sh code, it will simply take that as a cue to select the first address attempted. I don't see a problem with that. In summary, we just need to land everyone on the current version of iputils and it will turn out fine.
Stabilisation is done, so all done here?
(In reply to Sam James from comment #3) > Stabilisation is done, so all done here? Done and dusted. Thanks.
