Duet Wifi Webserver not responding
-
Maybe you can use M583 (Wait for pin) to wait for the release of the external switch before continuing to the M552 S1. I just ran into this issue as well on my first print with the Duet. It was fine for about the first hour and I was able to tweak the extrusion,etc but I was unable connect for the the last couple hours of the print (the print did complete successfully, though). LED on the Wifi module was still steady illuminated but my router indicated that the connection was not present. Pressing reset after the job completed reestablished the the link.
-
Sorry. That was out of context - I just now noticed there was a second page of discussion.
-
There're multiple different issues being reported on this thread. The one I'm experiencing is where the web gui goes offline but I can still ping the device.
Do you still need more logs for that one?
I'm seeing this on FW 1.21RC3 (2018-02-28 build 4), WiFi server 1.21RC3 (28b1), web interface 1.21-RC4.
I have a few logs I pulled, which I can supply if you need more info. Of note, though, I'm seeing this on the serial console:
[[language]] HTTP req, command words { GET /rr_status HTTP/1.1 }, parameters { type=3 } New conn on socket 7 for local port 80 HTTP connection accepted Found responder Received 459 bytes Sending reply, file = no HTTP req, command words { GET /rr_status HTTP/1.1 }, parameters { type=3 } WiFi: ../src/Listener.cpp(62): refused conn on port 80 no free conn WiFi: ../src/Listener.cpp(62): refused conn on port 80 no free conn WiFi: ../src/Listener.cpp(62): refused conn on port 80 no free conn
An M586 P0 cycle (S0/S1) did not resolve it:
[[language]] HTTP is disabled WiFi: recv../src/Listener.cpp(118): stopped listening on port 80 HTTP is enabled on port 80 WiFi: ../src/Listener.cpp(174): listening on port 80 WiFi: ../src/Listener.cpp(62): refused conn on port 80 no free conn
I also have a full network trace. When I refresh the browser, the gist of it is:
[[language]] --> TCP SYN <-- TCP SYN ACK --> TCP ACK --> HTTP GET <-- TCP ACK RST <-- TCP ACK RST
-
@daveidmx, thanks for that, the "no free conn" is the source of the problem. Which main and wifi firmware versions are you running? Please try 1.21RC3 + DuetWiFiServer 1.21RC4 if you are not already running those, because they include some relevant fixes.
-
Thanks! I'm running these:
@daveidmx:I'm seeing this on FW 1.21RC3 (2018-02-28 build 4), WiFi server 1.21RC3 (28b1), web interface 1.21-RC4.
Is that what you were suggesting to use? Or is there an RC4 of DuetWiFiServer I should test also? I'm looking here:
https://github.com/dc42/RepRapFirmware/tree/dev/EdgeRelease/1.21RC3 -
Please try RC4 of DuetWiFiServer, by following this link https://github.com/dc42/DuetWiFiSocketServer/blob/dev/Release/DuetWiFiServer-1.21RC4.bin and then pressing Download.
-
Got it! I will report back tomorrow.
-
I didn't get as much testing in today as I'd hoped, but I haven't seen any connection resets so far. Yesterday it was as often as 10 minutes, or as rare as 6 hours. I've had about 2 hours of prints so far today, so… looking good so far?
-
Does the DuetEthernet still use this, or is there something else equivalent that we DuetEthernet folk should be trying out?
-
Duet Ethernet doesn't use the DuetWiFiServer.bin file. If you are getting disconnections on the Duet Ethernet and they only happen when you are homing the printer or when printing a file, run M122 after you reconnect and check the MaxReps figure in the report. Note: MaxReps gets reset back to zero after you run M122.
-
I think my disconnects have all been during print processes, but I'm not super confident in that statement. I will look into the maxreps thing. While I'm waiting for another disconnect event, can you explain what the maxreps means? And is any non-zero value bad, or…?
-
MaxReps figures above about 50 are bad. The value gives an indication of the interrupt load of the step pulse generator. If it gets too high then the http responder gets starved of CPU time.
-
Got it, thanks.
I just had an ethernet drop out, and when I did an M122 afterwards, I got a maxreps of 4. So I'm guessing that's not my problem…
-
Sad news on my front. I'm still seeing the web console stop responding on 1.21RC4. Looks like the same issue still. The packet trace shows the same pattern as before (HTTP GET followed immediately by a connection reset) and the console indicates the same message ("refused conn on port 80 no free conn").
I tried to do an [c]M586 P0 S0[/c]/[c]S1[/c] cycle and it looks like it might have crashed the WiFi module. My print froze and I got this on the console:
M586 P0 S0 HTTP is disabled ok WiFi: ESP reported status change WiFi: Soft WDT reset ESP reported status change WiFi: WiFi: ctx: cont WiFi: sp: 3fff2fc0 end: 3fff32c0 offset: 01b0 WiFi: WiFi: >>>stack>>> WiFi: 3fff3170: 40233576 00000030 0000001c 40225893 WiFi: 3fff3180: 40225d11 3fff6cac 3fff5b3c 40225a2b WiFi: 3fff3190: 00000003 3fff31d0 00000000 40105f8d WiFi: 3fff31a0: 00000050 000000ff 00000000 00000000 WiFi: 3fff31b0: 3fff2125 3fff2190 3fff2194 00000000 WiFi: 3fff31c0: 00000000 3fff211c 3fff1900 40106542 WiFi: 3fff31d0: 00000000 005000ff 20000000 00000000 WiFi: 3fff31e0: 00000000 3fffc6fc 00000001 3fff22a0 WiFi: 3fff31f0: 00000000 3fffdad
-
You could use M552 S0/S1 instead of M586, worked for me every time without problems during printing. (probably used 30+ times)
I'm still on 1.21.RC1 and had no wifi problems in the last 2 weeks.
I just installed my PanelDue and added two macros for disabling/enabling wifi, so i can restart it without connecting the usb. -
I'm sorry to hear you are still having problems. Have you confirmed that you are running version 1.21RC4 of both the main firmware and the wifi firmware? Look on the Settings->General page of DWC to check.
You could try downloading and installing DuetWiFiServer 1.21RC4 again, in case the file got corrupted somewhere.
-
Here's what DWC says I'm running right now:
Firmware Version: 1.21RC4 (2018-03-11 build 1) WiFi Server Version: 1.21RC4(08b3) Web Interface Version: 1.21-RC4
I will re-download and re-flash and report back.
-
Confirmed it still stops responding.
New conn on socket 7 for local port 80 HTTP connection accepted Found responder Received 459 bytes Sending reply, file = no HTTP req, command words { GET /rr_status HTTP/1.1 }, parameters { type=3 } WiFi: ../src/Listener.cpp(62): refused conn on port 80 no free conn WiFi: ../src/Listener.cpp(62): refused conn on port 80 no free conn WiFi: ../src/Listener.cpp(62): refused conn on port 80 no free conn WiFi: ../src/Listener.cpp(62): refused conn on port 80 no free conn WiFi: ../src/Listener.cpp(62): refused conn on port 80 no free conn WiFi: ../src/Listener.cpp(62): refused conn on port 80 no free conn WiFi: ../src/Listener.cpp(62): refused conn on port 80 no free conn WiFi: ../src/Listener.cpp(62): refused conn on port 80 no free conn
-
Thanks, that gives me an idea of where to look. Do you use either FTP or Telnet, or just the web interface?
I'll add more debugging in RC5 so that M122 dumps the state of all the connections.
-
Just the web interface. Do you want me to test something on the others as well? (Or are you just wondering whether something else is also consuming sockets?)