Log incoming client IP addresses for API connections

[miketweaver]

Problem

Currently, only a single client can connect at once to the ApiServer. When multiple clients (e.g., mobile app, web interface, CLI tool) attempt to connect simultaneously, they will compete for the connection, often resulting in confusing disconnection issues. The existing logs only show "Incoming API connection" without identifying which client is connecting, making it difficult to troubleshoot these scenarios.

Solution

This PR modifies the connection logging in three API server implementations to include the remote client's IP address.

By adding this logging it makes for easier troubleshooting to quickly identify which client is connecting or causing connection conflicts.

Before

INFO  | Incoming API connection
INFO  | Incoming wifi connection
INFO  | Incoming ethernet connection

After

INFO  | Incoming API connection from 192.168.1.100
INFO  | Incoming wifi connection from 192.168.1.100
INFO  | Incoming ethernet connection from 192.168.1.100

Testing

Note:
I do not have an ipv6 network to test with and I am unsure what this would do in that situation. This is UNTESTED with ipv6. Also, meshtastic does not currently support IPV6.

I have tested these changes on the following hardware:

• ✅ M5Stack Cardputer ADV (ESP32-S3)
• ✅ Portduino

Minimal testing, but it worked and I didn't see anything wrong.

• ✅ Heltec V3 (minimal testing)
• ✅ Xiao nRF kit (minimal testing)

All devices correctly log the connecting client's IP address when API connections are established via WiFi and Ethernet interfaces.

🤝 Attestations

• I have tested that my proposed changes behave as described.
• I have tested that my proposed changes do not cause any obvious regressions on the following devices:
  • Heltec (Lora32) V3
  • RAK WisBlock 4631 (Xiao nRF kit)
  • Other: M5Stack Cardputer ADV (ESP32-S3), Portduino

[Copilot]

Pull request overview

This PR improves Meshtastic’s TCP API-server troubleshooting by including the remote client’s IP address in connection logs across the core ServerAPI and the WiFi/Ethernet server wrappers.

Changes:

• Log the connecting client’s remote IP address in the generic ServerAPI connection message.
• Log the connecting client’s remote IP address for WiFi API connections.
• Log the connecting client’s remote IP address for Ethernet API connections.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/mesh/api/ServerAPI.cpp	Adds remote client IP to the base “Incoming API connection” log.
src/mesh/api/WiFiServerAPI.cpp	Adds remote client IP to the WiFi-specific connection log.
src/mesh/api/ethServerAPI.cpp	Adds remote client IP to the Ethernet-specific connection log.

[Copilot]

The IP logging here is hard-coded to IPv4 octets ("%u.%u.%u.%u"). If this code ever runs on an IPv6-capable stack, the output will be incorrect/misleading. Consider formatting via toString() when available (with an ARCH_PORTDUINO fallback), ideally via a shared helper to keep formatting consistent across API servers.

Suggested change

	LOG_INFO("Incoming API connection from %u.%u.%u.%u", ip[0], ip[1], ip[2], ip[3]);
	LOG_INFO("Incoming API connection from %s", ip.toString().c_str());

[Copilot]

This repeats IPv4-only octet formatting for the remote address. To avoid duplication (and to support IPv6 where possible), consider using a shared IP formatting helper (or toString() with an ARCH_PORTDUINO fallback) so all API connection logs are consistent across WiFi/Ethernet/base ServerAPI.

Suggested change

	auto ip = _client.remoteIP();
	LOG_INFO("Incoming wifi connection from %u.%u.%u.%u", ip[0], ip[1], ip[2], ip[3]);
	auto ip = _client.remoteIP();
	#ifdef ARCH_PORTDUINO
	// ARCH_PORTDUINO may not support IPv6 or IPAddress::toString(), so use octet formatting.
	LOG_INFO("Incoming wifi connection from %u.%u.%u.%u", ip[0], ip[1], ip[2], ip[3]);
	#else
	LOG_INFO("Incoming wifi connection from %s", ip.toString().c_str());
	#endif

[Copilot]

This repeats IPv4-only octet formatting for the remote address. Consider routing all API-server IP logging through a shared helper (or toString() with appropriate fallbacks) so formatting is consistent and easier to extend (e.g., IPv6) across server implementations.

Suggested change

	LOG_INFO("Incoming ethernet connection from %u.%u.%u.%u", ip[0], ip[1], ip[2], ip[3]);
	LOG_INFO("Incoming ethernet connection from %s", ip.toString().c_str());