libretiny configures obsolete lwip setting to disable ARP/ACD after DHCP

[devsaurus]

Observed with libretiny 1.7.0 as part of esphome 2025.2.2.

I"ve been debugging intermittent WIFI connection issues of the wb2s and cb2s devices against (some of) my OpenWrt APs. Problem is that the ARP handshake following the DHCP sequence sometimes hangs for a long time (> 10ths of minutes). Symptoms in this state are

• Device is associated with the WIFI network
• Device is assigned an IP from the DHCP server
• Device's IP and name are registered with mDNS and DNS
• Esphome dashboard shows device is online
• Homeassistant reports the device offline in the device tab
• Device doesn't respond to pings and its web interface cannot be reached

Also reviewed the lwip configuration and noticed that libretiny configures DHCP_DOES_ARP_CHECK in lwipopts.h. However, the respective configuration setting was changed to LWIP_DHCP_DOES_ACD_CHECK after lwip-tcpip/lwip@7d1c26c

Adapting lwipopts.h accordingly results in a change of the DHCP/ARP sequence that doesn't emit ARP requests to the device's IP from the device itself anymore.

[bennydiamond]

@devsaurus I can't figure out where DHCP_DOES_ARP_CHECK is defined in libretiny's repo.

Do you have a branch that illustrate the change?

I too am having similar connectivity issues with my CB2S devices.
On Unifi APs tho.

[devsaurus]

Do you have a branch that illustrate the change?

No, I couldn't figure out how to set up a branched repo and include it in the esphome yaml.

For debugging I changed the file directly on homeassistant's filesystem. And checked multiple times before/after compilation that it wasn't overwritten by some background magic.

1. Log into bare-metal OS
   ssh -p 22222 root@homeassistant
2. Find the file at a path like this
   /mnt/data/supervisor/addons/data/<some tag>_esphome/cache/platformio/packages/library-lwip/port/lwipopts.h
3. The define is at/around line 428

A clean setup with a branch would be very helpful, indeed.

[bennydiamond]

OK, I see it.

Unfortunately, examples in Lwip repo still make mention of DHCP_DOES_ARP_CHECK rather than the new LWIP_DHCP_DOES_ACD_CHECK, which seems to be the defacto macro used throughout lwip's source code.

Maybe adding a build flag in esphome's device config would "cleanly" solve the issue?

esphome:
  name: test
  friendly_name: test
  platformio_options:
    build_flags:
      - -DLWIP_DHCP_DOES_ACD_CHECK=0

I'll try it and report if the defined macro is indeed taken into account

[bennydiamond]

Alright, to follow-up on my previous comment, adding the build flag does indeed alter the compile behavior of lwip_bdk.

Without it, function dhcp_conflict_callback() is present in the binary; validated present in raw_firmware.map.
With the build flag set with value "0", that function isn't in the map file.

dhcp_conflict_callback() gated by #if LWIP_DHCP_DOES_ACD_CHECK preprocessor directives.

EDIT:
Just to be sure, the goal here is to re-instate intended behavior in libretiny of having DHCP_DOES_ARP_CHECK set to a value of "0" right?

[devsaurus]

Without it, function dhcp_conflict_callback() is present in the binary

Interesting. Maybe the logic around this function was never tested/looked at, since it wasn't supposed to be included in libretiny's stack in the first place?

Just to be sure, the goal here is to re-instate intended behavior in libretiny of having DHCP_DOES_ARP_CHECK set to a value of "0" right?

Yes, that's my goal as well.

[devsaurus]

Thanks a lot for digging up a clean approach to set the define!
I did some pass/fail testing on my setup and the build_flag works for me.

First, reproduce the issues with an unmodified lwip:

• reverted my local modification of lwipopts.h
• executed Clean Build Files in ESPHome dashboard for the device
• compiled and installed the binary

The issues were back and I observed the quirky DHCP/ARP sequence with tcpdump.

Next, test the build flag approach:

• added the build_flag to the device's yaml
• executed Clean Build Files
• compiled and installed the binary

The issues are gone and the DHCP/ARP sequence looks the same as with my local modification.