-
Notifications
You must be signed in to change notification settings - Fork 7.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem in NetworkClient::connected() #10559
Comments
Ops ... Version v3.0.7 |
https://www.ennepisoft.it/test_esp32/test_esp32.php |
hi, this is a more 'elegant' solution to the problem. It is likely that the cause comes from using an SD card to read the site files from which could set errno to some error code. If the link (.php) to the site is a problem, I put the link directly to the zipped test_file |
uint8_t NetworkClient::connected() {
if (fd() == -1 && _connected) {
stop();
}
if (_connected) {
uint8_t dummy;
//#define RESET_ERRNO
#ifdef RESET_ERRNO
errno = ENOENT; // <= aggiunto
int res = recv(fd(), &dummy, 0, MSG_DONTWAIT);
if(res > 0)
Serial.printf("recv return %d byte\n", res);
#else
int res = recv(fd(), &dummy, 1, MSG_DONTWAIT | MSG_PEEK);
#endif
// avoid unused var warning by gcc
(void)res;
// recv only sets errno if res is <= 0
if (res <= 0) {
switch (errno) {
case EWOULDBLOCK:
case ENOENT: //caused by vfs
_connected = true;
break;
case ENOTCONN:
case EPIPE:
case ECONNRESET:
case ECONNREFUSED:
case ECONNABORTED:
_connected = false;
log_d("Disconnected: RES: %d, ERR: %d", res, errno);
break;
default:
log_i("Unexpected: RES: %d, ERR: %d", res, errno);
_connected = true;
break;
}
} else {
_connected = true;
}
}
return _connected;
} |
I compared the WebServer library with the 'cotestatnt' library and I saw that the main difference of the handleClient() (in web_server.cpp) is the presence, in the core, of the following piece of code: if (_currentClient.isSSE()) {
_currentStatus = HC_WAIT_CLOSE;
_statusChange = millis();
keepCurrentClient = true;
} I commented it and it didn't give that problem anymore, but if that code exists it has its reason and I think the solution I proposed is more valid. //---------------------------------------
char g_Buff2[1024 * 4];
#define chunk g_Buff2
#define sizeChunk (sizeof(chunk))
//---------------------------------------
template<typename T> void loadAndsendFile(AsyncWebServerRequest* request, T filename, int mime)
{
DEBUG_WEB(Serial.printf("FileToSend:%s, mime:%s\n", filename, getContentType(mime)))
if (!openFile(filename)) {
handle404(request);
return;
}
int32_t _dim = myFile.size();
AsyncClient* client = request->client();
DEBUG_WEB(Serial.printf("Client %s, dim:%d\n", (client ? "Ok" : "Err"), _dim))
sendHeader(client, mime, _dim, (eHTML == mime) ? no_cache : ok_cache);
int32_t dim = _dim;
int fail = 0;
while(dim > 0 && fail < 5) {
int len = min((unsigned int)dim, sizeChunk);
len = myFile.read((uint8_t*)chunk, len);
if (!len)
break;
bool inside = dim > sizeChunk;
const char* t = (const char*)chunk;
fail = 0;
do {
// non cambia nulla tra i due
// int sent = client->write(t, len);
int sent = client->write(t, len, inside ? ASYNC_WRITE_FLAG_MORE : 0);
DEBUG_WEB(Serial.printf("Dim =%d, Remain=%d, Len=%d, Sent=%d\n", _dim, dim, len, sent))
dim -= sent;
if(sent == len)
break;
t += sent;
len -= sent;
vTaskDelay(10);
if(!sent)
++fail;
} while(fail < 5);
}
DEBUG_WEB(if(dim) Serial.println(" Failed "); else Serial.println(" Done "))
myFile.close();
}
//------------------------------------------------------------------- I prepared a couple of logs, one when it tries to load the index, the other directly putting the name of a fairly large image. What could it depend on? If you want (and you are interested) I can prepare the whole folder or you can use the one already linked and I will add only the modified files |
It looks like I have the same issue that you have and you can find my one file project on this github page, https://github.com/EmileSpecialProducts/ESP-SPIFFS-Web-Server The project is a simple web server that servs files form the SPIFFS and has a Wifi-manager and OTA update. http://xxx.xxx.xxx.xxx/ I see the error also on the ESP32-C6. |
While waiting for them to insert the patch I suggested you can directly modify the code by changing, in 'NetworkClient.cpp' the line: int res = recv(fd(), &dummy, 0, MSG_DONTWAIT); with: int res = recv(fd(), &dummy, 1, MSG_DONTWAIT | MSG_PEEK); in the function 'uint8_t NetworkClient::connected()' |
👍 |
Could you create a minimal reproducible example and list what need to be done step-by-step to reproduce this issue ? I tried reproducing it but I did not found any issue (besides the debug message). The fix suggested also did not change anything for me. |
Sorry, I forgot to say that you need to set the specific bits to enable debugging, from serial you need to give the command: cmd=debug:80# or cmd=debug-bits:4,6,#. |
You can use my project ESP-LittleFS-Web-Server. and you only need the ESP-LittleFS-Web-Server.ino file and works on all ESP types ( i have seen the issue on C6/S3, have not tested it on other devices) |
I have prepared a minimal version that recreates the problem. It is in the same place as the 'almost complete' version: |
I still don't get any errors (besides the obvious missing files): |
Ok, managed to reproduce it. I will open a PR. |
ok thanks, but the return zero can be due in three cases:
|
Updated description |
Board
ESP32
Device Description
DOIT ESP32 DEVKIT V1
Hardware Configuration
almost all GPIO are connected
Version
v3.0.5
IDE Name
Arduino IDE
Operating System
Windows
Flash frequency
80 MHz
PSRAM enabled
no
Upload speed
921600
Description
With recv() in MSG_DONTWAIT the errno is not reset when recv() returns zero, not because the connection is terminated, but because there is no data. My solution is to reset errno before call to recv(). The full explanation is in 'https://forum.arduino.cc/t/errore-nel-file-appdata-local-arduino15-packages-esp32-hardware-esp32-3-0-x-libraries-network-src-networkclient-cpp/1317872/3'
Sketch
Debug Message
Other Steps to Reproduce
No response
I have checked existing issues, online documentation and the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: