Web interface rejected my connection attempts

misan

@T3P3Tony One additional detail to the issue is this other capture, where pings can be seen responded with a huge time difference, suggesting the board receives the messages but respond to them abnormally late (once the issue has passed). Have a look at ICMP request issued at 130 and responded at 2020 (almost 50 seconds later).
capture5.pcapng.bin

misan

@T3P3Tony A recent M122 output:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3 (2021-06-15 21:44:54) running on Duet WiFi 1.02 or later
Board ID: 0JD0M-9K662-MGPSS-6J1FG-3S46Q-KVUGY
Used output buffers: 1 of 24 (18 max)
=== RTOS ===
Static ram: 23876
Dynamic ram: 74152 of which 0 recycled
Never used RAM 16388, free system stack 126 words
Tasks: NETWORK(ready,647.7%,237) HEAT(delaying,0.3%,386) Move(notifyWait,52.2%,307) MAIN(running,544.4%,546) IDLE(ready,14.3%,29), total 1258.9%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 05:12:00 ago, cause: power up
Last software reset at 2022-11-08 16:55, reason: User, GCodes spinning, available RAM 16388, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Step timer max interval 0
MCU temperature: min 18.8, current 24.2, max 24.8
Supply voltage: min 23.6, current 23.8, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: position 75056, standstill, SG min/max not available
Driver 1: position 42138, standstill, SG min/max not available
Driver 2: position 6103, standstill, SG min/max not available
Driver 3: position 0, standstill, SG min/max not available
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2023-01-16 12:09:06
Cache data hit count 4294967295
Slowest loop: 217.84ms; fastest: 0.11ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 4.4ms, write time 42.8ms, max retries 0
=== Move ===
DMs created 83, maxWait 366651ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 164159, completed moves 164120, hiccups 5, stepErrors 0, LaErrors 0, Underruns [27567, 0, 0], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X1172.75 Y718.41 Z42.40" in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 948.00ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(2), 1 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.25
WiFi MAC address 48:3f:da:48:b2:81
WiFi Vcc 3.43, reset reason Power up
WiFi flash size 4194304, free heap 19872
WiFi IP address 192.168.1.8
WiFi signal strength -56dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 2 0 0 0 0 0 0 0

T3P3Tony

@misan said in Web interface rejected my connection attempts:

Slowest loop: 948.00ms; fastest: 0.00ms

That looks long. not sure if it could be waiting for an SD card read or write which is why i suggested that test.

misan

@T3P3Tony I am going to test the SD replacement, but my order is in the mail

Anyway, what seems to be the cause is Dropbox's operation. It looks like some of the network traffic it broadcasts might be setting the ESP8266 into a weird state.

We know that the problem does not appear if we stop Dropbbox on our workshop computers from synchronizing.

I have a longer traffic capture, with the problem starting at 15.2 seconds (approx) but the file is too long for your system, so it can be downloaded from here (for a limited time) https://we.tl/t-m0dDrqfM2K

T3P3Tony

@misan ahh that's interesting, is dropbox doing some broadcast synchronisation on the LAN between your local computers? Maybe it has a setting that allows you to set the machines specifically and not broadcast?

misan

@T3P3Tony I have set the systems not to use LAN synchronization for a while to see if that helps or fixes the problem entirely. I will know more at the end of the day.

Please note I added a link to a more comprehensive network capture in the previous email I edited.

dc42

@misan you could try updating the wifi firmware to 2.1beta2 from https://github.com/Duet3D/RepRapFirmware/releases/tag/3.5.0beta1.

misan

@dc42 Sure. I will do it and report back.

Oops, I just saw I cannot do that remotely (wifi parameters must be re-entered). That means I have to go to the workshop. This will then take longer.

misan

@dc42 since I disabled Dropbox LAN synchronization and moved all cell phones to another Wi-Fi network, the problem I reported is gone.

Given 2.1beta2 is reported to feature slower upload speeds plus being a beta version, and our use case is a CNC farm where every bit counts, I have decided not to update wifi firmware on our boards.

dc42

@misan said in Web interface rejected my connection attempts:

Given 2.1beta2 is reported to feature slower upload speeds plus being a beta version, and our use case is a CNC farm where every bit counts, I have decided not to update wifi firmware on our boards.

The initial tests we did on just one Duet and one router indicated that 2.x was slower than 1.x; however some users are getting higher speeds with 2.x than they did with 1.x.

misan

@dc42 Hmm, maybe I will try it the next time I visit the workshop. Thanks for the clarification.