RAMAllocator with default flags is stateless — it's just a dispatch
wrapper over heap_caps_malloc/realloc/free. Remove the stored member
from SpiRamAllocator, using stack-local instances at each call site.
Also make RAMAllocator constructors constexpr so the compiler can
fully evaluate flag logic at compile time.
Note: SpiRamAllocator was initialized with RAMAllocator::NONE (0),
which is equivalent to default construction since the constructor
preserves the default ALLOC_INTERNAL | ALLOC_EXTERNAL flags when
no valid allocation flags are provided.
Co-Authored-By: J. Nick Koston <nick@koston.org>
Cannot confirm wifi_station_disconnect() synchronously clears the
lwIP netif LINK_UP flag on ESP8266 NONOS SDK. The comment doesn't
need to make claims about link state since the fix is simply that
the hostname never changes at runtime, making dhcp_renew() pointless.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The dhcp_renew() loop was cargo-culted from Arduino ESP8266's
WiFi.hostname() which was designed for changing the hostname on
an already-connected system with multiple interfaces (WiFi+Ethernet).
In ESPHome, wifi_apply_hostname_() is only called from:
- setup_() — before WiFi connects (link never up)
- wifi_sta_connect_() — after wifi_disconnect_() (link always down)
The hostname is fixed at compile time and never changes at runtime.
Setting intf->hostname is sufficient — lwIP automatically includes
it in DHCP DISCOVER/REQUEST packets via LWIP_NETIF_HOSTNAME.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
DHCP_STATE_BOUND alone is insufficient — during reconnection, DHCP
can remain BOUND from a previous connection while the link is down
(wifi_disconnect_() doesn't stop DHCP). Both conditions are needed:
DHCP must be BOUND and the interface must have link.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
netif_is_link_up() is insufficient — if wifi_station_connect()
completes quickly (e.g. fast_connect), the setup() call at line 710
could reach dhcp_renew() with link up but DHCP still in SELECTING
or REQUESTING state, causing the same state corruption.
Check dhcp->state == DHCP_STATE_BOUND directly to ensure dhcp_renew()
is only called when there is an actual lease to renew.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
wifi_apply_hostname_() calls dhcp_renew() on all interfaces with DHCP
data, including when WiFi is not yet connected. lwIP's dhcp_renew()
unconditionally sets the DHCP state to RENEWING (line 1159 in dhcp.c)
before attempting to send, and never rolls back the state on failure.
This corrupts the DHCP state machine: when WiFi later connects and
dhcp_network_changed() is called, it sees RENEWING state and calls
dhcp_reboot() instead of dhcp_discover(). dhcp_reboot() sends a
broadcast DHCP REQUEST for IP 0.0.0.0 (since no lease was ever
obtained), which can put some routers into a persistent bad state
that requires a router restart to clear.
This bug has existed since commit 072b2c445c (Dec 2019, "Add ESP8266
core v2.6.2") and affects every ESP8266 WiFi connection attempt. Most
routers handle the bogus DHCP REQUEST gracefully (NAK then fallback
to DISCOVER), but affected routers get stuck and refuse connections
from the device until restarted.
Fix: guard the dhcp_renew() call with netif_is_link_up() so it only
runs when the interface actually has an active link. The hostname is
still set on the netif regardless, so it will be included in DHCP
packets when the connection is established normally.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace heap-allocated std::vector constants with static constexpr
std::array in MIFARE Classic and Ultralight write operations across
pn532, pn7150, and pn7160 components.
Changes:
- Convert write_mifare_classic_block_ and write_mifare_ultralight_page_
signatures from std::vector<uint8_t>& to const uint8_t*/size_t
- Replace 24 constant 16-byte vectors in format functions with
static constexpr std::array (data now lives in flash/rodata)
- Replace 3 constant 4-byte blank_data vectors with static constexpr
std::array
- Eliminate per-iteration vector copies in write_tag loops by passing
pointers directly into the encoded buffer
When USE_ENTITY_ICON is not defined, LOG_ENTITY_ICON and log_entity_icon
are now completely compiled out rather than calling a function that
checks an always-empty icon reference.
Two fixes for ESP8266 with noise encryption:
1. Cache socket ready() before the handshake loop. On ESP8266 LWIP raw
TCP, ready() returns the live state (false once rx buffer is consumed),
unlike ESP32 where it is cached until the next main loop. Re-checking
each iteration blocked handshake writes that must follow reads,
deadlocking the handshake.
2. Process client removal immediately after loop() instead of deferring
to the next server loop iteration. This closes the socket promptly
to free LWIP PCB resources and prevent retransmit crashes on ESP8266.
On ESP8266 (GCC 10.3), std::vector::push_back/emplace_back emit
separate _M_realloc_insert functions even when called from only
one site. Adding __attribute__((flatten)) inlines the realloc
path, saving the out-of-line function overhead.
Changes:
- wifi: Move set_sta_priority from header to .cpp (eliminates
duplicate instantiation at 2 call sites) and add flatten
- web_server_base: Flatten add_handler (single push_back site)
- api: Flatten accept_new_connections_ (single emplace_back site)
- api: Extract push_item_ as single flattened push_back site for
DeferredBatch (was 2 call sites in add_item/add_item_front)
Saves ~200 bytes of flash on ESP8266, ~40 bytes on ESP32.
