TCPServer or Webserver library crashing?

I have a Photon running the Webserver library that hosts a simple configuration web page. This had been very stable earlier this year when I was developing the code. Given a strong Wi-Fi signal I could access the page any time, day after day.

Now, the page comes up fine after rebooting the Photon. However, once it’s loaded, after about an hour or so it becomes inaccessible. I get the message in Chrome, “192.168.1.150 refused to connect.”

The device is still connected to the cloud, and I can run my exposed functions. It’s just that the web server is down.

Anyone else experiencing similar issues? Any suggestions about diagnosing the problem?

I think one problem is that the WebServer library does not handle the case when the Wi-Fi network becomes disconnected. When that happens, all server listeners (TCPServer or UDP, but TCPServer for the web server) have to reinitialize their socket listeners when the Wi-Fi comes back up.

I didn’t test it, but if you’re using SYSTEM_THREAD(ENABLED) or SEMI_AUTOMATIC or MANUAL mode, you could probably monitor WiFi.ready() from loop. If it goes to not ready, then back to ready, when it becomes ready again call the web server object’s begin() method. I think that should work.

1 Like

Thanks, I’ll give that a try.

No luck. I can wait until the web server stops responding and then execute a cloud function that runs webserver.begin(); and it has no effect. Any other suggestions?

Hi @rickkas7 and @Jerware , I have similar problems with my system. Unfortunately, loosing the Wi-Fi connection is a quite common problem for some people and that eventually crashes the servers. I always saw this issue myself and I frequently see reports about it from other users. The problem was much worse before, but it still happens.

I’m running 0.5.3 Automatic mode, that makes more difficult to monitor WiFi connection. Do you or someone from Particle @ScruffR @Dave know of any way to at least test/monitor if the server listener still active? The TCP server in my case.

Thanks

Hi @bacichetti,

Hmm, over time I’ve found the best way to test if a server is still listening, or if a socket is still valid, is to try and connect to it, or send some data to it / get some data back. Could you do something like a loopback connection in your firmware to your local ip address on the port you’re listening on? I haven’t tried that myself on a Photon, but I think that should work?

I hope that helps!

Thanks,
David

1 Like

Hi @Dave

That was my idea too, but for some reason it doesn’t work. The client’s connection fails trying to connect to its own IP address and server port.
I checked the implementation using 2 photons then, one connecting and sending message to the other’s IP address. That works fine.

    static byte server[] = { 192, 168, 2, 7};

    if (tcpClient.connect(server, 8839)) {
        Serial.println("connected");
        tcpClient.println("ping");
    }
    else {
        Serial.println("connection failed");
    }
1 Like

Hmm, what about loopback? 127.0.0.1 ?

Same result.

I’m not using thread(enable), so i thought it could be simply because tcpClient.connect(IP,port) blocks the application from the connection with its own server and not a network routing issue. I’m not sure about that though.

I enabled thread, but the result still the same, with both IPs (127… and 192…).

More suggestions?