[BUG] `ipconfigDHCP_FALL_BACK_AUTO_IP` does not perform ARP clash detection

[george-palmsens]

Describe the bug
When automatically getting a link local IP, the stack is supposed to detect if somebody is already using the randomly chosen address.

It does this by issuing a gratuitous ARP claim, and seeing if it gets responded to.

The code attempts to do this, but it doesn't work. Because the network stack is not up yet, vARPSendGratuitous does not lead to any message being sent. Therefore there's no reply, and no clash is detected. The network stack comes up on a conflicted address.

Target
STM32H7
Arm Cortex M
GCC 15.2

To Reproduce

In order to reliably get a clash on the randomly chosen link local address, you'll need to modify prvPrepareLinkLayerIPLookUp to generate a clashing address on purpose.

I used the following patch:

void prvPrepareLinkLayerIPLookUp( NetworkEndPoint_t * pxEndPoint )
{
    uint8_t ucLinkLayerIPAddress[ 2 ];
    uint32_t ulNumbers[ 2 ];

    static uint32_t generate_n_clashes = 1;

    /* After DHCP has failed to answer, prepare everything to start
        * trying-out LinkLayer IP-addresses, using the random method. */
    EP_DHCPData.xDHCPTxTime = xTaskGetTickCount();

    ( void ) xApplicationGetRandomNumber( &( ulNumbers[ 0 ] ) );
    ( void ) xApplicationGetRandomNumber( &( ulNumbers[ 1 ] ) );
    ucLinkLayerIPAddress[ 0 ] = ( uint8_t ) ( 1 + ( ulNumbers[ 0 ] % 0xFDU ) ); /* get value 1..254 for IP-address 3rd byte of IP address to try. */
    ucLinkLayerIPAddress[ 1 ] = ( uint8_t ) ( 1 + ( ulNumbers[ 1 ] % 0xFDU ) ); /* get value 1..254 for IP-address 4th byte of IP address to try. */

    if (generate_n_clashes) {
        ucLinkLayerIPAddress[0] = 131;
        ucLinkLayerIPAddress[1] = 160;
        generate_n_clashes--;
    }
    /* rest snipped */
}

• Connect to a network with no DHCP server, and make sure ipconfigDHCP_FALL_BACK_AUTO_IP is set
• Wait for the DHCP attempts to timeout, then watch for ARP resolution

Expected behavior

• The device should sent an ARP announcement for the clashing IP
• The clashing host will send a duplicate IP detected ARP message
• The device should pick a new link local IP, and send an ARP announcement for it
• This IP should stick

Current behaviour

• The device sends no ARP announcement during IP acquisition
• Once the stack is "up", ARP announcements start going out for the clashed address
• Despite the clashing host sending duplicate IP detected ARP messages, the device never changes IP

[gmtt]

Thanks for the detailed report and for digging into the root cause — calling vARPSendGratuitous before the network stack is up does indeed mean the gratuitous ARP frame is never queued for transmission, which is consistent with what you're observing.

To make sure we're reproducing the exact code path you hit, could you share two more details:

1. The FreeRTOS-Plus-TCP version (tag, commit SHA, or a git describe from your tree) and the FreeRTOS-Kernel version it's paired with.
2. The relevant section of your FreeRTOSIPConfig.h — specifically ipconfigDHCP_FALL_BACK_AUTO_IP, ipconfigUSE_DHCP, ipconfigARP_USE_CLASH_DETECTION (if defined in your build), and any related ARP / DHCP timing options.

With those in hand we can confirm the affected path against mainline and look at the right fix shape (e.g. deferring the gratuitous ARP until xNetworkInterfaceOutput is wired up, or providing a clash-detection hook that runs at the right point in the IP-task lifecycle).

[george-palmsens]

V4.4.1

#define ipconfigUSE_DHCP               1
#define ipconfigDHCP_FALL_BACK_AUTO_IP 1
// #define ipconfigARP_USE_CLASH_DETECTION // this is not defined by me, so defaults to enabled

The resolution I used locally was to replace vARPSendGratuitous with FreeRTOS_OutputARPRequest_Multi, but maybe that's not principled.