Fix misleading arping error message when bond interface is not ready

[Copilot]

Problem

When running ifup on a bond interface while bond negotiation is incomplete, the arping command fails to send packets and outputs Sent 0 probes (0 broadcast(s)) Received 0 response(s). However, the error message incorrectly suggests an IP address conflict:

Error, some other host () already uses address 192.168.1.100

This is misleading because:

• The failure is not due to an IP address conflict
• The empty parentheses () where a MAC address should be looks like a bug
• Users waste time investigating a non-existent duplicate IP issue
• The actual problem (interface not ready) is not communicated

Root Cause

The existing code only checks if a MAC address is found in the arping output to detect duplicate IPs. When arping fails because the interface cannot send packets (bond negotiation incomplete), no MAC is extracted, but the code doesn't distinguish this case from other failures.

Solution

Enhanced the arping error handling logic to detect when the interface is not ready by checking for the Sent 0 probes pattern in arping output. The code now distinguishes between three failure scenarios:

1. Interface not ready (Sent 0 probes) → Provides helpful error with configuration guidance
2. Duplicate IP detected (MAC address found) → Reports the conflict (existing behavior preserved)
3. Other failures (timeout, etc.) → Shows generic error message

Changes

network-scripts/ifup-eth

Added detection inside the arping retry loop:

# Check if arping failed because interface is not ready (no packets sent)
if echo "$ARPING" | grep -q "Sent 0 probes"; then
    # Interface not ready, continue retrying
    continue
fi

After retries exhausted, provide specific error:

if echo "$ARPING" | grep -q "Sent 0 probes"; then
    net_log $"Failed to bring up ${DEVICE}: interface not ready (no packets sent). Try increasing ARPING_WAIT or LINKDELAY, or check interface status."
else
    net_log $"arping failed after $tries tries"
fi

network-scripts/ifup-aliases

Applied similar improvements for alias interface handling, with proper MAC detection before reporting duplicate IP errors.

po/initscripts.pot

Regenerated translation template to include the new error message string.

Error Message Comparison

Before:

Error, some other host () already uses address 192.168.1.100

After:

Failed to bring up bond0: interface not ready (no packets sent).
Try increasing ARPING_WAIT or LINKDELAY, or check interface status.

Configuration Guidance

Users experiencing this issue can now adjust these options in their ifcfg files:

ARPING_WAIT=5     # Wait 5 seconds for arping response (default: 3)
ARPING_TRIES=3    # Retry 3 times (default: 1)  
LINKDELAY=5       # Wait 5 seconds after bringing link up

Benefits

• ✅ Clear explanation of the actual problem
• ✅ Actionable guidance with specific configuration options
• ✅ Saves troubleshooting time by pointing to the real issue
• ✅ No breaking changes - all existing behavior preserved
• ✅ Duplicate IP detection still works correctly with MAC addresses
• ✅ Backward compatible with existing configurations

Testing

Validated three scenarios:

1. Interface not ready (Sent 0 probes) → Correct helpful error message
2. Duplicate IP detected (MAC found) → Correct duplicate IP error
3. Timeout (packets sent, no response) → Correct generic error

Fixes the issue reported in #XXX where @lnykryn suggested improving error messages based on arping output to better distinguish between different failure modes.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>When bond4 negotiation is not complete, the ifup script arping fails and the error information is misleading.</issue_title>
<issue_description>I run the ifup script while the bond4 negotiation process is running and not finished. The arping command fails to be executed. The command output is as follows:

Obviously, the up failure is not caused by an IP address conflict. I think such an error is misleading.

https://github.com/fedora-sysv/initscripts/blob/32f0ddf2efb7e02227febca5c43acae36a52f569/network-scripts/ifup-eth#L296C11-L296C11
Whether this can be optimized. You can correct the up error information based on the arping command output, or try again in this case.</issue_description>

Comments on the Issue (you are @copilot in this section)

@lnykryn Yeah, that part of the code is .... suboptimal. It is already stupid that we call some random sed on the output (and yeah I know it was my code). In the ideal case, we should find out if arping returns different return codes on different events and base the behavior on that. But to be honest, initscripts are no longer actively developed and almost nobody is using the network part these days, so this is not a priority for us. But I would be happy to review any patch to improve this. @lnykryn In your case, it might be enough to set ARPING_WAIT to some higher value in the ifcfg file.

Fixes #465

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.