4 years, 1 month ago.
UIPServer stops responding
Hi, it's me again :)
In the beggining let me appologize for the wall of text and thank you for all your work in this library :)
I've been using UIPEthernet since you kindly helped me to run it on Nucleo F411RE and it was fun. But when I started to run stability tests on it I noticed something strange. When I start UIPServer it begins to do its job and then just stops. By "stops" I mean it doesn't indicate that there are valid requests waiting (and there are). As a starting point to my further research I used your
HTTP Server serving a simple webpage which enables to remotely turn LED1 on/off. Compile, download, run and type 'IP_address/secret/' (don't forget the last '/') into your web browser and hit ENTER.
and added a simple DS1820 to read data from.
When first time I saw that I was afraid that something in my code breaks and that Nucleo hangs, so I have added a Ticker to blink LED1 and to my surprise - it was still blinking even when http reqests stop being processed. Then I added a simple printf:
size = client.read(buf, size); string received((char*)buf); free(buf); // printf added here, commandCount starts at 0 // and is incremented after each reqest parsed after this point printf("%d", commandCount); printf(" - %s", received.c_str());
And again - LED1 blinks, but after few requests (and that number is not constant, sometimes it runs for 60+ requests, sometimes goes silent after only 2; for now it looks quite random) console stops logging new requests and web clients can't connect to Nucleo (both web browser and my C# service that connects to Nucleo). After that point no new connections to Nucleo succeed and the only solution is to restart it (in fact as a failsafe I have added a Ticker that restarts it if there was no request registered after 100 seconds, but of course that is a temporary solution).
My next guess was that maybe the ENC28J60 does hang or stops parsing packets, but I've enabled printf's in UIPEthernet.cpp in void UIPEthernetClass::tick(void) and it in fact does receive them (and a lot of them to be honest, it logs both IP and ARP packets incoming).
And so I went and asked uncle google what he thinks and after many, many, maaaaaany hours I found this: https://github.com/ntruchsess/arduino_uip/issues/30 and boy I was glad - I wasn't the only one hitting my head :) It looks like Norbert Truchsess was able to fix this behaviour (https://github.com/ntruchsess/arduino_uip/commit/027171ee990ee8a54e40a102f56cdf17897e45a0) in his andruino library and I was even happier... But when I tried to modify your version of the library I have noticed two things: first of all your library was created after that fix was implemented and secondly - you have modified the code a lot and I couldn't figure out how to include his fix into your code and if it is necessary in the first place.
What I tried was to change #define's as he did in UIPClient.h and modify UIPClient.cpp to reflect that but I was aware that changing this won't fix the problem. Then I have changed UIPClient.cpp from:
if (data && data->state)
but that didn't help neither. Then I've tried to change UIPServer.cpp in UIPClient UIPServer::available(void) from:
if(UIPClient::_available(u) && u->state & UIP_CLIENT_REMOTECLOSED)
and now I got some results... But "not perfect" is a mild understatement :) While requests are being logged (in that first place I have showed at the beggining), the clients don't receive any response :/ So I've reverted all my changes and as a temporary solution right after http_send I call client.stop(). That somehow helps, server stops after more requests but still stops nevertheless. I tried to make requests that have "Connection: Close" header (previously I tried with "Connection: Keep-Alive" - same result) but that didn't help neither.
While I'll try to work on that some more I was hoping you may be willing to look into that as well :)
On a side note - do you have by any chance mbed version of the HardwareSerial.h that can easily be used to debug this library? Out of hurry I ended up replacing Serial.print's with simple printf's, but that is a tedious work and before I start to write my own version of that helper I prefer to ask first, reinvent the wheel later :)
Question relating to:
4 years, 1 month ago.
I have updated the UIPEthernet library to be in line with the one released for Arduino (version 1.09). Thanks to the tremendous work done by Norbert this should now fix the leaking client-data caused by race-condition on remote close. Unfortunately I did not have time to run a thorough long term test. Please let me know how it works.
To post an answer, please log in.