Wifi module keeps disconnecting
-
OK, tried with my phone as a hotspot and the Duet connected first time to my phone, I could view the DWC via the same hotspot on my laptop.
So there's seems to be a problem with the router.
Next I tried to upgrade just the DuetWiFiServer to 1.21RC1. It did this, then disconnected. I now I can't connect at all to the wifi module. It's throwing up all kinds of errors that weren't there before. the M587 command keeps failing with
Turn off the current WiFi mode before selecting a new one
and M587: Failed to add SSID to remembered list.
God I'm growing weary of this.
There seems to be a bug in 1.21RC3 whereby you may need to send M552 S0 twice to get out of the current WiFi mode, or maybe you just need to wait longer after sending it. It's on my list to investigate. I wasn't aware of the same issue with 1.21RC1, but perhaps it's in that version too.
-
Might just be my weakish WiFi signal but after updating from 1.20 to 1.21RC3 I seem to be getting more random disconnections than I did prior to the upgrade.
Hitting connect usually gets me straight back in though there have been a couple of occasions where I struggled a bit.
Relevant bit of M122 diags in case there's anything in there that's of any use (as you can see the signal strength is weak but not that bad):
- WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.21RC3(28b1)
WiFi MAC address ec:fa:bc:0b:f7:33
WiFi Vcc 3.47, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 14952
WiFi IP address 192.168.0.25
WiFi signal strength -71dBm, reconnections 0, sleep mode modem
Socket states: 2 0 0 0 0 0 0 0
- WiFi -
-
Thanks. Your reported signal strength of -71dBm is rather low and likely to be a contributory factor.
1.21RC1 and later use a different wifi SDK version than 1.20 and earlier did, and there appear to have been major changes between the two versions. So it is quite likely that one will work better than the other in a particular environment. We had to make the change to get the fix for the KRACK vulnerability.
-
Nope, tried sending M552 S0 twice, with a pause. There's something wrong with that version, it doesn't write the SSID when you send M587, even though it replies "ok". When you ask it to list the SSIDs, it fails to retrieve them.
Looks like the SD card is my next option.
But I'd like to know how the printer connected to my phone's wifi hotspot with a glitch, but still fails to connect to my router's wifi. Every other device in our house works perfectly with the router. I put capital letters in my phone's hotspot password just to test it - worked fine. The Duet just cannot connect the main router for some reason. We have laptop, chromebook, chromecast, Nintendo Switch, TV, etc all connect fine. The only one that won't is the Duet. And this is with the correct network name and password in the config file.
-
OK, I have restored my Duet to the stable 1.20 firmware / wifi.
So, what I know is that the Duet connects to my phone as a wifi hotspot. I can send the config via a terminal emulator and it connects fine. It returns an IP address and I can view DWC.
If I repeat the exact same process with our router SSID and password - I get wrong password error. The password is correct obviously - I can cut and paste the same password when I connect to the router's web interface into the M587 command and it will fail.
However, if I cut and paste the same password into my phone's hotspot wifi config, repeat the terminal M587 with the new password for the phone, it connects. So the problem isn't the password.
There is something else preventing the Duet connecting to the home router.
Both Chromebook and phone, and every other device in the whole house connects fine to router wifi. Only the Duet is unable.
What is going on / going wrong, can someone please put my out of my misery?!!
-
I have heard rumours before that the wifi module we use may be incompatible with some routers (depending to some extent on the SDK firmware version). This thread https://github.com/esp8266/Arduino/issues/2795 appears to confirm it. One post near the bottom from a user says he got it to work by changing the encryption settings on his router, to WPA-personal and AES. The "wrong password" error does suggest that the issue may be with incompatible encryption settings on your router.
HTH David
closed Unable to connect to some Wi-Fi access points #2795
-
Hi David
Well, it does seem to be something like that. I disabled the security on the router, and the Duet connected fine. So it's something to do with the encryption modules. Unfortunately there is no WPA-Personal authentication setting.
This is proving to be a nightmare. I've wasted so much time - and I can't change the router. We've just got it and everything else works fine. In terms of the rest of the family, the 3D printer is right at the bottom of the list of priorities!
I really don't know what to do now. The printer is useless without a means to control it.
-
What WiFi encryption settings does your router offer, and what is it set to at present?
If you can't resolve it by changing your router settings, one option would be to buy a cheap WiFi extender and have the Duet connect to that.
-
Hi David
It only offers WPA-PSK/WPA2-PSK or WPA2-PSK on its own. There isn't one for WPA-PSK on it's own.
There already is a signal booster, as the router is only the ground floor and the printer is in the attic. But I don't think that's the issue.
I had a brief moment yesterday when I thought I'd cracked it. I realised I had used the same password for both admin on the router and the wifi SSID. Shouldn't make any difference, but in desperation I thought it might. I changed it, rebooted the router, and lo and behold the Duet connected first time. I was delighted!
Sadly, after an hour of messing about with my z stop, I decided to reboot it the printer to check it still worked. And you can guess the rest - back came the 'wrong password' error and I never got it to connect again.
Sigh…
It sounds crazy, but I'm wondering if I can use the new router in modem mode and run the wifi off the old BT router, but that is going to get pretty messy with cables etc. Really don't want to do that just to have a working printer.
I've been going through the ESP*** forums trying to find some answers. Some recommended a reset to the the defaults - is there any way of accessing the ESP module directly to reset it?
-
can you set the BT router to operate in AP Mode and use that just for your printer/s
-
Hi Dougal - could you explain a little more what you mean?
-
Don't suppose there's any way to enable WPS for the ESP module?
-
Well some routers like the TP-Link one that DC mentioned have a AP Mode where they connect to your main router on a cable and then act as a WiFi access point that routes stuff to your main router. It's a while since I looked at the settings on a BT Hub?
-
Ah, might have solved it. I've moved the wifi booster to a new location and reset. Rebooted the router, WPS the booster in the new spot, fired up the Duet and it connected. Turned the Duet off and on several times, and it's reconnected each time… :-0
I think what may have been happening is that the booster was intermittently losing the wifi from the router. It doesn't give any indication the signal has been lost, it just reconnects immediately. But I noticed once I got it connected, that it dropped and the Duet claimed it was still connected because it had an IP address. Then after a few minutes it got back on as the booster sorted itself out. This is just a complete guess though - TBH I have no idea and I have no intention to move the booster back to the old spot to find out!!
Fingers crossed this is it!
-
I just want to give a heads up to anyone who might suffer similar issues to this.
I did get a robust solution eventually. My wifi signal booster, a cheap tp-link model, gives you the option to not only boost the wifi signal, but to also to "extend" it by giving it another name (but still sharing the same password). You'll need the tp-link app to set this up.
I placed the signal booster in the same room as my printer. Using the app, I then added an 'x' to the SSID name of my wifi extension. I then set the Duet to only connect to the wifi extension, not the general wifi. Provided you connect your laptop or whatever to the same extension, you should guarantee a robust connection with the DWC.
I think all the issues I had were some sort of signal interference or configuration between the router's wifi and the booster wifi. I never got to the bottom of the issues, but creating the wifi extension via the signal booster cured all the issues. The Duet never drops the connection now.
I hope this might help someone at some point - the dropped connections had me tearing my hair out and it's so hard to find out what's wrong.
The TP-link app for the wifi signal booster really saved the day for me in this instance!
-
Thanks for sharing your solution.
-
I've had 1.20 installed for 2 days now. After say 15mins of use get an unrecoverable wifi disconnect. Which is to say am unable to reconnect again. If I open a new browser window and try to go to the IP address the error will be "the server unexpectedly dropped the connection". So it is there but not responding. Also unable to ping from that point on.
In addition have noticed that no longer see the network name for the Duet at the wifi router. Before nor after the "disconnect". Just a "*".
Here's the moment Pinging stopped:
[c]
64 bytes from 192.168.0.128: icmp_seq=23555 ttl=255 time=8.044 ms
64 bytes from 192.168.0.128: icmp_seq=23556 ttl=255 time=113.279 ms
64 bytes from 192.168.0.128: icmp_seq=23557 ttl=255 time=40.027 ms
64 bytes from 192.168.0.128: icmp_seq=23558 ttl=255 time=29.561 ms
64 bytes from 192.168.0.128: icmp_seq=23559 ttl=255 time=19.960 ms
64 bytes from 192.168.0.128: icmp_seq=23560 ttl=255 time=4.129 ms
64 bytes from 192.168.0.128: icmp_seq=23561 ttl=255 time=4.433 ms
64 bytes from 192.168.0.128: icmp_seq=23562 ttl=255 time=4.404 ms
64 bytes from 192.168.0.128: icmp_seq=23563 ttl=255 time=6.956 ms
64 bytes from 192.168.0.128: icmp_seq=23564 ttl=255 time=5.140 ms
64 bytes from 192.168.0.128: icmp_seq=23565 ttl=255 time=4.366 ms
64 bytes from 192.168.0.128: icmp_seq=23566 ttl=255 time=4.298 ms
64 bytes from 192.168.0.128: icmp_seq=23567 ttl=255 time=4.431 ms
64 bytes from 192.168.0.128: icmp_seq=23568 ttl=255 time=4.811 ms
ping: sendto: Network is down
Request timeout for icmp_seq 23569
Request timeout for icmp_seq 23570
Request timeout for icmp_seq 23571
Request timeout for icmp_seq 23572[/c]
And here's the M122 that I get whilst printing and after the Duet is no longer responding to web requests. Have connected by USB.
Have been through the wifi/ajax help page a dozen times. Any further suggestions much appreciated.
[c]
SENT: m122
SENT: M105
READ: === Diagnostics ===
READ: Used output buffers: 2 of 32 (14 max)
READ: === Platform ===
READ: RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0
READ: Board ID: 08D6M-91AST-L23S4-7JTDL-3SD6N-96X5K
READ: Static ram used: 15448
READ: Dynamic ram used: 99064
READ: Recycled dynamic ram: 176
READ: Stack ram used: 3576 current, 8592 maximum
READ: Never used ram: 7792
READ: Last reset 01:18:15 ago, cause: power up
READ: Last software reset at 2018-03-11 05:37, reason: User, spinning module GCodes, available RAM 11904 bytes (slot 3)
READ: Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
READ: Error status: 0
READ: Free file entries: 9
READ: SD card 0 detected, interface speed: 12.0MBytes/sec
READ: SD card longest block write time: 40.6ms
READ: MCU temperature: min 27.5, current 31.1, max 31.4
READ: Supply voltage: min 24.1, current 24.3, max 24.8, under voltage events: 0, over voltage events: 0
READ: Driver 0: ok, SG min/max 0/192
READ: Driver 1: ok, SG min/max 0/1023
READ: Driver 2: ok, SG min/max 65/278
READ: Driver 3: ok, SG min/max 0/1023
READ: Driver 4: standstill, SG min/max not available
READ: Date/time: 2018-03-11 08:38:16
READ: Cache data hit count 4294967295
READ: Slowest main loop (seconds): 0.160038; fastest: 0.000042
READ: === Move ===
READ: MaxReps: 4, StepErrors: 0, FreeDm: 227, MinFreeDm 120, MaxWait: 463565ms, Underruns: 0, 0
READ: Scheduled moves: 6152, completed moves: 6147
READ: Bed compensation in use: mesh
READ: Bed probe heights: 0.000 0.000 0.000 0.000 0.000
READ: === Heat ===
READ: Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
READ: Heater 0 is on, I-accum = 0.3
READ: Heater 1 is on, I-accum = 0.5
READ: === GCodes ===
READ: Segments left: 1
READ: Stack records: 1 allocated, 0 in use
READ: Movement lock held by null
READ: http is idle in state(s) 0
READ: telnet is idle in state(s) 0
READ: file is doing "G1 E1.6000 F2700" in state(s) 0
READ: serial is ready with "m122" in state(s) 0
READ: aux is idle in state(s) 0
READ: daemon is idle in state(s) 0
READ: queue is idle in state(s) 0
READ: autopause is idle in state(s) 0
READ: Code queue is empty.
READ: Network state is running
READ: WiFi module is idle
READ: Failed messages: pending 0, notready 0, noresp 0
READ: WiFi firmware version 1.20
READ: WiFi MAC address 5c:cf:7f:2b:ee:bb
READ: WiFi Vcc 3.42, reset reason Turned on by main processor
READ: WiFi flash size 4194304, free heap 18344
READ: HTTP sessions: 1 of 8
READ: Socket states: 0 0 0 0 0 0 0 0
READ: Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
READ: ok
READ: ok T:204.6 /205.0 B:70.0 /70.0
[/c]What seems to have changed vis a vis when it was working are the nearly last lines. Before they read:
[c]
Socket states: 2 0 0 0 0 0 0 0
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
[/c] -
HTTP(1) means that one HTTP responder is processing a request.
Suggestions:
1. Work through https://duet3d.dozuki.com/Wiki/WiFi_disconnections_and_AJAX_timeout_errors if you haven't already.
2. Try upgrading to main firmware 1.21RC3 (or RC4 which I hope to release later today) and wifi firmware 1.21RC4. Read the upgrade notes first.
-
Thanks. The wifi help page already done many times. Eager to try the upgrades.
The links to the Betas at the following address do not work and haven't been able to find them browsing/searching Github?
https://duet3d.dozuki.com/Wiki/Firmware_Overview#Section_Betas
-
OK have figured out that the correct URL for the Betas is:
https://github.com/dc42/RepRapFirmware/tree/dev/EdgeRelease
(Note: @dc42 - links in the guide need updating)
