[IDF5.x] Client remoteIP incorrect

[TD-er]

Board

ESP32 (classic)

Device Description

WROOM ESP32

Hardware Configuration

Version

other

IDE Name

PlatformIO

Operating System

Windows 11

Flash frequency

40MHz

PSRAM enabled

yes

Upload speed

115200

Description

When calling web_server.client().remoteIP() I no longer get the IP-adres of the connected client.
In my project (ESPEasy) I try to block connections not coming from the local subnet.
In some occasions the browser doesn't seem to provide the client IP, so there was an exception for 0.0.0.0 to be allowed.
This has been working fine for years and doesn't seem to be a problem on ESP32-S2/C3
But on the ESP32 classic, I'm now experiencing blocks even with random looking reported remote IP-addresses like 35.0.6.0. (I'm on the same subnet as my ESP node)

On ESP32-S3/C3 running ESP32 SDK 5.1.1.230920 I noticed I never see the client IP (remoteIP()) anymore.
On recent builds using the same code build with ESP32 SDK 4.4.5.230614 I can get the client IP just fine.

I use @Jason2866 's packaged platform packages:

• IDF 5.1: platform = https://github.com/Jason2866/platform-espressif32.git#ae949bcf416213717662095f67cd76d85a810529
• IDF 4.4.5:

platform                    = https://github.com/tasmota/platform-espressif32/releases/download/2023.10.03/platform-espressif32.zip
platform_packages           = framework-arduinoespressif32 @ https://github.com/Jason2866/esp32-arduino-lib-builder/releases/download/1645/framework-arduinoespressif32-release_v4.4_spiffs-e3fc63b439.zip

Sketch

-

Debug Message

-

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[VojtechBartoska]

Hi, seems this is caused by breaking changes in migration from 2.X to 3.X. We will soon finish migration guide and I will create one issue, where we will collect all the questions and possible issue to not overflow project issue tracker.

[TD-er]

OK, can you maybe already tell me which function I should use here so I can already test with it?
I may have other related issues and I guess it would be useful if I already understand where to look, to save you time and perhaps I can then also help completing that new migration guide as I already have done a lot of the migration myself in my project.

[VojtechBartoska]

#8716 here is the Migration Guide PR

[TD-er]

OK, so it wasn't an API change.

I suspect it may have something to do with clientSocketHandle.
And if this is true, then this function will also not work when checking 2 of such clients:

bool WiFiClient::operator==(const WiFiClient& rhs)

Here is the client being set in the WebServer:

void WebServer::handleClient() {
  if (_currentStatus == HC_NONE) {
    _currentClient = _server.available();

However....

WiFiClient WiFiServer::available(){
  if(!_listening)
    return WiFiClient();

This function also returns a default WiFiClient() when client_sock < 0 (may happen when sockfd is has not been set?) or either of the setsockopt calls return false.

N.B. I do not (yet) use IPv6 and it seems like sockfd is only set when you can create a socket for the AF_INET6 domain.

So it seems like either the sockfd is the culprit here or _listening ??

N.B.2: _listening is only set to true when the WiFiServer::begin does not return before the end of the function.
So that makes sockfd the main suspect here I guess?

[TD-er]

By the way, this seems to be fixed, so I will close it now.