Bug 766974 – net-misc/netifrc: net/arping.sh can hang forever in the case of NO-CARRIER

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description RumpletonBongworth 2021-01-25 01:33:51 UTC]

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.

[Comment 1 RumpletonBongworth 2021-01-25 01:46:10 UTC]

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.

[Comment 2 RumpletonBongworth 2021-01-25 02:52:05 UTC]

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.

[Comment 3 Sam James 2021-05-10 14:50:06 UTC]

Stabilisation is done, so all done here?

[Comment 4 RumpletonBongworth 2021-05-10 21:14:55 UTC]

(In reply to Sam James from comment #3)
> Stabilisation is done, so all done here?

Done and dusted. Thanks.