Duet 2 WiFi network slowdowns and board restarts

gloomyandy

@ProteanReverie That list of symptoms seems sounds more like a problem with your router rather than with the the Duet boards. Do you have other devices connected to the same 2.4GHz WiFi network? Do they also slow down? Many routers have an option to have them restart at a preset time (usually in the middle of the night) every week, if yours does you might want to try enabling it.

ProteanReverie

@gloomyandy thank you for your response.

I do suspect there is something going on with our router/network causing this since this is not a more widely reported issue, but we have not been able to successfully diagnose thus far as well as it being more connected to router resets than duet resets. Several months ago we did try changing various router settings as well as adding a range extender and having the Duets connect to that, but we would still encounter the issue. Unfortunately, I do not have information on what changes were attempted at that time.

The hardfault crash reset of Duet boards does seem like an issue/concern on the Duet end.

We currently have 4 windows PCs, 2-3 cellphones, 3 blink cameras, 2 tablets, and 3 office phones also on the network, as well as anywhere from 2-8 total Duets. I have seen this happen with 2PCs, 1 cell, 2 tablets, 1 office phone and 2 duets in the past. Nothing else on the network has ever had issues with network slowdown or showing any issue that we have been able to detect, even when then the issue is present with DWC.

A regular reset bandaid could work for our office, but as a printer OEM building machines with these boards to be sold to customers, a better understanding would be preferred in case customers encounter such issues.

droftarts

@ProteanReverie It's a long shot, but... it does seem possible that Duets are a bit susceptible to malformed Ethernet packets coming from the network. Some other users have reported similar issues, and the Hardfaults seem to be related to networking, and occasionally oddly setup browsers. @dc42 has often asked what extra languages are installed in these cases, as it seems foreign characters or character sets can trigger the Duet crash.

What made me think of this is when you say you have '3 blink cameras' on your network. Security cameras are a favourite target for hackers, that can then be used to snoop on the local network (strange packets) as well as launch DoS attacks. The Blink camera does seem susceptible: https://www.electronicshub.org/can-blink-cameras-be-hacked/

Running a WireShark scan of the network for a while, and capturing any strange packets, particularly at the point when the Duet crashes, may be useful. It would be great to track this one down!

Ian

dc42

@ProteanReverie it might be worth setting up a macro that disables wifi using M552 S-1, delays for a few seconds using G4, then restarts wifi using M552 S1. Resetting the connection in this way may be simpler than resetting the Duet or the router.

ProteanReverie

@droftarts said in Duet 2 WiFi network slowdowns and board restarts:

@ProteanReverie It's a long shot, but... it does seem possible that Duets are a bit susceptible to malformed Ethernet packets coming from the network. Some other users have reported similar issues, and the Hardfaults seem to be related to networking, and occasionally oddly setup browsers. @dc42 has often asked what extra languages are installed in these cases, as it seems foreign characters or character sets can trigger the Duet crash.

What made me think of this is when you say you have '3 blink cameras' on your network. Security cameras are a favourite target for hackers, that can then be used to snoop on the local network (strange packets) as well as launch DoS attacks. The Blink camera does seem susceptible: https://www.electronicshub.org/can-blink-cameras-be-hacked/

Running a WireShark scan of the network for a while, and capturing any strange packets, particularly at the point when the Duet crashes, may be useful. It would be great to track this one down!

Ian

No extra languages are set up on any of the PCs or tablets, or any other devices to my knowledge.

I am aware to some extent the security issues present with networked cameras and will keep an eye on that. Nothing that I have seen so far has indicated to me that they have been compromised at any point, but those kinds of things not being able to be noticed is usually a key point so can't say for sure.

I have got wireshark set up, and next time I see issues I will run a capture focused on the IP of one of the machines to share here. I plan to take it through a file upload (which will likely fail) as well as some network interface resets which hopefully cause the restart while doing that capture. If there are other actions I should take during that capture, please let me know.

@dc42 said in Duet 2 WiFi network slowdowns and board restarts:

@ProteanReverie it might be worth setting up a macro that disables wifi using M552 S-1, delays for a few seconds using G4, then restarts wifi using M552 S1. Resetting the connection in this way may be simpler than resetting the Duet or the router.

I actually wrote that exact macro a couple of years ago when having other issues which were later resolved. I still use it from time to time when I see this issue crop up, though often times when the issue is present the interface will be so inaccessible that I cannot activate the macro so it is easier to connect via serial to send commands or just power cycle the machine. Thank you for the recommendation.

ProteanReverie

I happened to encounter the issue again this morning. I did not get a board reset this time, but did get data from Wireshark. At the start of this capture I was able to upload a file of size 70kb. This was followed by attempts to upload a file of size 11,365kb. This file never succeeded in uploading, and was transfering at speeds under 5kb/s, as low as 300b/s from what I observed. The first upload attempt reached about 45% before restarting and then failing at about 5%. After each failed upload I tried the M552 commands a couple of times to try and induce a board reset, but this did not occur. There are multiple upload attempts with multiple M552s in between each upload attempt within the packet capture. Near the end of the capture I had done another M552 S0 which the console responded to by letting me know that the WiFi module was idle, as expected. However, the M552 S1 that followed that and subsequent S0/S1s only responded with "ok" and I could not get it to reconnect, so I power cycled the machine and ended the capture.

During this capture I was able to normally use the network outside of DWC without issue, including an internet speed test from the PC that was uploading the files, which looked normal without any speed concerns. 3 other people were present in the office and working online without noticing any issues with the network. Whatever is happening only seems to impact the Duets/DWC.

The Duet is IP 10.1.10.38, and my PC is 10.1.10.9. All captures below were taken with a filter for 10.1.10.38.

Here is the packet capture discussed above:
6-27-24-uploads-M552s-nocrash-failconnectatend.pcapng

Here is an additional capture, taken after the first one. During this the machine was printing, and while I still had DWC up on my PC it was not connected, with the blue "Connecting..." popup sitting at a static 0% for the duration.
6-27-24-printing-notconnected-issuepresent.pcapng

In case it helps for comparison, here is a packet capture I took yesterday when the issue was not occurring, where I uploaded a file of size 27066kb at over 250kb/s without issue:
6-26-24.pcapng

droftarts

@ProteanReverie this starts to sound more like an SD card writing issue, now. Please can you run the tests described in this section of the wiki, and post the results: https://docs.duet3d.com/en/User_manual/RepRapFirmware/SD_card#troubleshooting-sd-card-issues

Ian

ProteanReverie

@droftarts said in Duet 2 WiFi network slowdowns and board restarts:

@ProteanReverie this starts to sound more like an SD card writing issue, now. Please can you run the tests described in this section of the wiki, and post the results: https://docs.duet3d.com/en/User_manual/RepRapFirmware/SD_card#troubleshooting-sd-card-issues

Ian

I have run those test on two Duets/machines, after a 3+ hour print on each, with results below. Do note that the issue was not occurring at the time these tests were done. Also, when the issue occurs it seems to impact all machines. I can confirm both of the tested machines were having the issue at the same time this morning.

The machine that the packet captures came from:
Test 1 - M122
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 7.4ms, write time 145.6ms, max retries 0

Test 2 - M39
SD card in slot 0: capacity 7.95GB, partition size 7.94GB, free space 7.47GB, speed 20.00MBytes/sec, cluster size 64kB

Test 3 - M122 P104 S10
SD write speed for 10.0MByte file was 2.87MBytes/sec
SD read speed for 10.0MByte file was 1.31MBytes/sec

Test 4 - M22
Error: M22: SD card has open file(s)

Other machine:
Test 1 - M122
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 12.3ms, write time 146.4ms, max retries 0

Test 2 - M39
SD card in slot 0: capacity 7.95GB, partition size 7.94GB, free space 7.54GB, speed 20.00MBytes/sec, cluster size 32kB

Test 3 - M122 P104 S10
SD write speed for 10.0MByte file was 2.40MBytes/sec
SD read speed for 10.0MByte file was 1.23MBytes/sec

Test 4 - M22
Error: M22: SD card has open file(s)

I did not get the chance today to remove the SD cards to try the windows application in those troubleshooting steps.

droftarts

@ProteanReverie Okay, thanks for testing the SD cards, both look pretty normal. I forgot you said that it affects multiple machines at once in your first post.

Is there any other sources of WiFi interference around? Microwave ovens, cordless phones, baby monitors, or noisy electric motors (eg old fridge)? Re-reading the whole thread, it does feel like it's an issue with the router.

Ian

ProteanReverie

@droftarts said in Duet 2 WiFi network slowdowns and board restarts:

@ProteanReverie Okay, thanks for testing the SD cards, both look pretty normal. I forgot you said that it affects multiple machines at once in your first post.

Is there any other sources of WiFi interference around? Microwave ovens, cordless phones, baby monitors, or noisy electric motors (eg old fridge)? Re-reading the whole thread, it does feel like it's an issue with the router.

Ian

Interference could be a possibility. We do have a couple of cordless office phones, though they aren't used often. We do also have a microwave, but timing of usage does not line up. However, we are in a multi-business building and wedged in between two other companies. It is unknown what interference generators they may have.

ProteanReverie

Had another case today. This time it only appeared to only be an issue one Duet system, but it seemed like the usual issue from this thread. The slowdown/inaccessibility issue persisted through multiple power-cycles, multiple uses of [M552 S-1] followed by [M552 S1], and switching to host mode with [M552 S2] and then going back to client mode. Everything seemed to work just fine in host mode, as usual. There were no resets during this.

This Duet 2 was running on firmware version 3.6.0A2+3. A Duet 3 also running 3.6.0A2+3 did not appear to be affected. Additionally, two Duet 2s running 3.5.2 did not seem to exhibit symptoms and DWC stayed connected the whole time I was monitoring them while the one with the issue was having its problem.

I ran a packet capture, the Duet is 10.1.10.38. Before long this devolved into only showing requests from my PC (10.1.10.9) to find the Duet, while the Duet seemed completely unreachable. I stopped the capture in case the connection would not be recovered to prevent a needlessly long file. That is the first packet capture here. Then, in case it did reconnect I started a new capture, which did see a point where the Duet was able to re-establish communications, though it continued to disconnect from DWC shortly after any time it did connect.

8-9-24-A3-D2-idle-disconnect.pcapng
8-9-24-A3-D2-idle-reconnect.pcapng

I was also able to get M122 data via serial console, which I have pulled to share here from the log file. The first M122 was run during the period of time where the packet capture showed the board as completely unreachable, right around where the capture was stopped and then restarted. The second M122 was run shortly after it reconnected, while still being too unstable to get the M122 through DWC.

Disconnected:

2024-08-09 12:09:57 [debug] WiFi module is connected to access point SD3D-24, IP address 10.1.10.38
ok
2024-08-09 12:24:13 [debug] === Diagnostics ===
2024-08-09 12:24:13 [debug] RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-alpha.2+3 (2024-07-17 20:03:21) running on Duet WiFi 1.02 or later + DueX5v0.11
2024-08-09 12:24:13 [debug] Board ID: 0JD2M-9F8TA-GJ4TN-6J1DD-3S46S-17SU6
2024-08-09 12:24:13 [debug] Used output buffers: 1 of 26 (24 max)
2024-08-09 12:24:13 [debug] === RTOS ===
2024-08-09 12:24:13 [debug] Static ram: 23368
2024-08-09 12:24:13 [debug] Dynamic ram: 70144 of which 12 recycled
2024-08-09 12:24:13 [debug] Never used RAM 24192, free system stack 134 words
2024-08-09 12:24:13 [debug] Tasks:
2024-08-09 12:24:13 [debug]  NETWORK(1,ready,64.1%,217)
2024-08-09 12:24:13 [debug]  ACCEL(6,nWait 5,0.0%,249)
2024-08-09 12:24:13 [debug]  HEAT(3,nWait 5,0.1%,328)
2024-08-09 12:24:13 [debug]  Move(4,nWait 5,0.0%,274)
2024-08-09 12:24:13 [debug]  DUEX(5,nWait 5,0.0%,23)
2024-08-09 12:24:13 [debug]  MAIN(1,running,35.8%,501)
2024-08-09 12:24:13 [debug]  IDLE(0,ready,0.0%,29)
2024-08-09 12:24:13 [debug] , total 100.0%
Owned mutexes:
2024-08-09 12:24:13 [debug]  WiFi(NETWORK)
2024-08-09 12:24:13 [debug]  USB(MAIN)
2024-08-09 12:24:13 [debug] === Platform ===
2024-08-09 12:24:13 [debug] Last reset 01:18:37 ago, cause: power up
2024-08-09 12:24:13 [debug] Last software reset at 2024-08-06 15:49, reason: HeatTaskStuck, Gcodes spinning, available RAM 26972, slot 0
2024-08-09 12:24:13 [debug] Software reset code 0x4143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x20004818 Task ACCE Freestk 4294954872 ok
2024-08-09 12:24:13 [debug] Stack: 00000000 200041bc 10000000 e000e000 006dc7e3 0045d535 0045dc80 61000000 0045dc69 20005370 2000d448 00011d4a 2000d478 200041a8 200041b0 20004c78 0042f4a5 2000d448 a5a5a5a5 a5a5a5a5 20004c78 a5a5a5a5 0042f54b a5a5a5a5 0045c459 a5a5a5a5 a5a5a5a5
2024-08-09 12:24:13 [debug] Error status: 0x00
2024-08-09 12:24:13 [debug] MCU temperature: min 32.3, current 33.0, max 34.3
2024-08-09 12:24:13 [debug] Supply voltage: min 24.1, current 24.3, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
2024-08-09 12:24:13 [debug] Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/12/12, gc cycles 0
2024-08-09 12:24:13 [debug] Events: 0 queued, 0 completed
2024-08-09 12:24:13 [debug] Date/time: 
2024-08-09 12:24:13 [debug] 2024-08-09 12:24:13
2024-08-09 12:24:13 [debug] Slowest loop: 1005.96ms; fastest: 0.21ms
2024-08-09 12:24:13 [debug] I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
2024-08-09 12:24:13 [debug] === Storage ===
Free file entries: 9
2024-08-09 12:24:13 [debug] SD card 0 detected, interface speed: 20.0MBytes/sec
2024-08-09 12:24:13 [debug] SD card longest read time 104.0ms, write time 101.0ms, max retries 0
2024-08-09 12:24:13 [debug] === Move ===
Segments created 15, maxWait 1915146ms, bed comp in use: none, height map offset 0.000, hiccups added 0 (0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00, mcet 0.025
2024-08-09 12:24:13 [debug] Pos req/act/dcf: 80000.00/79999/1.00 -4.00/-3/-1.00 6400.00/6400/0.00 88056.00/88056/0.00
2024-08-09 12:24:13 [debug] no step interrupt scheduled
2024-08-09 12:24:13 [debug] === DDARing 0 ===
Scheduled moves 4, completed 4, LaErrors 0, Underruns [0, 0, 0]
2024-08-09 12:24:13 [debug] Driver 0: standstill, SG min 0
2024-08-09 12:24:13 [debug] Driver 1: standstill, SG min 5
2024-08-09 12:24:13 [debug] Driver 2: standstill, SG min n/a
2024-08-09 12:24:13 [debug] Driver 3: standstill, SG min n/a
2024-08-09 12:24:13 [debug] Driver 4: standstill, SG min n/a
2024-08-09 12:24:13 [debug] Driver 5: standstill, SG min n/a
2024-08-09 12:24:13 [debug] Driver 6: standstill, SG min n/a
2024-08-09 12:24:13 [debug] Driver 7: standstill, SG min n/a
2024-08-09 12:24:13 [debug] Driver 8: standstill, SG min n/a
2024-08-09 12:24:13 [debug] Driver 9: standstill, SG min n/a
2024-08-09 12:24:13 [debug] Driver 10: 
2024-08-09 12:24:13 [debug] Driver 11: 
2024-08-09 12:24:13 [debug] === Heat ===
2024-08-09 12:24:13 [debug] Bed heaters 0 1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
2024-08-09 12:24:13 [debug] Heater 2 is on, I-accum = 0.0
2024-08-09 12:24:13 [debug] === GCodes ===
2024-08-09 12:24:13 [debug] Movement locks held by null
2024-08-09 12:24:13 [debug] HTTP is idle in state(s) 0
2024-08-09 12:24:13 [debug] Telnet is idle in state(s) 0
2024-08-09 12:24:13 [debug] File is idle in state(s) 0
2024-08-09 12:24:13 [debug] USB is ready with "m122" in state(s) 0
2024-08-09 12:24:13 [debug] Aux is idle in state(s) 0
2024-08-09 12:24:13 [debug] Trigger is idle in state(s) 0
2024-08-09 12:24:13 [debug] Queue is idle in state(s) 0
2024-08-09 12:24:13 [debug] LCD is idle in state(s) 0
2024-08-09 12:24:13 [debug] Daemon is idle in state(s) 0
2024-08-09 12:24:13 [debug] Autopause is idle in state(s) 0
2024-08-09 12:24:13 [debug] Q0 segments left 0
2024-08-09 12:24:13 [debug] Code queue 0 is empty
2024-08-09 12:24:13 [debug] === Filament sensors ===
check 0 clear 14997920
2024-08-09 12:24:13 [debug] Extruder 0 sensor: ok
2024-08-09 12:24:13 [debug] Extruder 1 sensor: ok
2024-08-09 12:24:13 [debug] === DueX ===
Read count 1, 0.01 reads/min
2024-08-09 12:24:13 [debug] === Network ===
2024-08-09 12:24:13 [debug] Slowest loop: 302.78ms; fastest: 0.00ms
2024-08-09 12:24:13 [debug] Responder states:
2024-08-09 12:24:13 [debug]  HTTP(0)
2024-08-09 12:24:13 [debug]  HTTP(0)
2024-08-09 12:24:13 [debug]  HTTP(0)
2024-08-09 12:24:13 [debug]  FTP(0)
2024-08-09 12:24:13 [debug]  Telnet(0)
2024-08-09 12:24:13 [debug] HTTP sessions: 0 of 8
2024-08-09 12:24:13 [debug] === WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 16435, noresp 41
2024-08-09 12:24:13 [debug] Failed to get WiFi status
2024-08-09 12:24:13 [debug] Socket states:
2024-08-09 12:24:13 [debug]  6
2024-08-09 12:24:13 [debug]  6
2024-08-09 12:24:13 [debug]  0
2024-08-09 12:24:13 [debug]  4
2024-08-09 12:24:13 [debug]  0
2024-08-09 12:24:13 [debug]  0
2024-08-09 12:24:13 [debug]  0
2024-08-09 12:24:13 [debug]  0
2024-08-09 12:24:13 [debug] ok

Post re-connect, unstable:

2024-08-09 12:49:30 [debug] === Diagnostics ===
2024-08-09 12:49:30 [debug] RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-alpha.2+3 (2024-07-17 20:03:21) running on Duet WiFi 1.02 or later + DueX5v0.11
2024-08-09 12:49:30 [debug] Board ID: 0JD2M-9F8TA-GJ4TN-6J1DD-3S46S-17SU6
2024-08-09 12:49:30 [debug] Used output buffers: 1 of 26 (24 max)
2024-08-09 12:49:30 [debug] === RTOS ===
2024-08-09 12:49:30 [debug] Static ram: 23368
2024-08-09 12:49:30 [debug] Dynamic ram: 70144 of which 12 recycled
2024-08-09 12:49:30 [debug] Never used RAM 24192, free system stack 134 words
2024-08-09 12:49:30 [debug] Tasks:
2024-08-09 12:49:30 [debug]  NETWORK(1,ready,48.4%,217)
2024-08-09 12:49:30 [debug]  ACCEL(6,nWait 5,0.0%,249)
2024-08-09 12:49:30 [debug]  HEAT(3,nWait 5,0.1%,328)
2024-08-09 12:49:30 [debug]  Move(4,nWait 5,0.0%,274)
2024-08-09 12:49:30 [debug]  DUEX(5,nWait 5,0.0%,23)
2024-08-09 12:49:30 [debug]  MAIN(1,running,51.5%,501)
2024-08-09 12:49:30 [debug]  IDLE(0,ready,0.0%,29)
2024-08-09 12:49:30 [debug] , total 100.0%
Owned mutexes:
2024-08-09 12:49:30 [debug]  WiFi(NETWORK)
2024-08-09 12:49:30 [debug] === Platform ===
2024-08-09 12:49:30 [debug] Last reset 01:43:54 ago, cause: power up
2024-08-09 12:49:30 [debug] Last software reset at 2024-08-06 15:49, reason: HeatTaskStuck, Gcodes spinning, available RAM 26972, slot 0
2024-08-09 12:49:30 [debug] Software reset code 0x4143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x20004818 Task ACCE Freestk 4294954872 ok
2024-08-09 12:49:30 [debug] Stack: 00000000 200041bc 10000000 e000e000 006dc7e3 0045d535 0045dc80 61000000 0045dc69 20005370 2000d448 00011d4a 2000d478 200041a8 200041b0 20004c78 0042f4a5 2000d448 a5a5a5a5 a5a5a5a5 20004c78 a5a5a5a5 0042f54b a5a5a5a5 0045c459 a5a5a5a5 a5a5a5a5
2024-08-09 12:49:30 [debug] Error status: 0x00
2024-08-09 12:49:30 [debug] MCU temperature: min 32.4, current 33.3, max 33.8
2024-08-09 12:49:30 [debug] Supply voltage: min 24.1, current 24.3, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
2024-08-09 12:49:30 [debug] Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/12/12, gc cycles 0
2024-08-09 12:49:30 [debug] Events: 0 queued, 0 completed
2024-08-09 12:49:30 [debug] Date/time: 
2024-08-09 12:49:30 [debug] 2024-08-09 12:49:30
2024-08-09 12:49:30 [debug] Slowest loop: 673.42ms; fastest: 0.21ms
2024-08-09 12:49:30 [debug] I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
2024-08-09 12:49:30 [debug] === Storage ===
Free file entries: 9
2024-08-09 12:49:30 [debug] SD card 0 detected, interface speed: 20.0MBytes/sec
2024-08-09 12:49:30 [debug] SD card longest read time 104.0ms, write time 100.8ms, max retries 0
2024-08-09 12:49:30 [debug] === Move ===
Segments created 15, maxWait 0ms, bed comp in use: none, height map offset 0.000, hiccups added 0 (0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00, mcet 0.000
2024-08-09 12:49:30 [debug] Pos req/act/dcf: 79999.00/79999/1.00 -3.00/-3/-1.00 6400.00/6400/0.00 88056.00/88056/0.00
2024-08-09 12:49:30 [debug] no step interrupt scheduled
2024-08-09 12:49:30 [debug] === DDARing 0 ===
Scheduled moves 4, completed 4, LaErrors 0, Underruns [0, 0, 0]
2024-08-09 12:49:30 [debug] Driver 0: standstill, SG min n/a
2024-08-09 12:49:30 [debug] Driver 1: standstill, SG min n/a
2024-08-09 12:49:30 [debug] Driver 2: standstill, SG min n/a
2024-08-09 12:49:30 [debug] Driver 3: standstill, SG min n/a
2024-08-09 12:49:30 [debug] Driver 4: standstill, SG min n/a
2024-08-09 12:49:30 [debug] Driver 5: standstill, SG min n/a
2024-08-09 12:49:30 [debug] Driver 6: standstill, SG min n/a
2024-08-09 12:49:30 [debug] Driver 7: standstill, SG min n/a
2024-08-09 12:49:30 [debug] Driver 8: standstill, SG min n/a
2024-08-09 12:49:30 [debug] Driver 9: standstill, SG min n/a
2024-08-09 12:49:30 [debug] Driver 10: 
2024-08-09 12:49:30 [debug] Driver 11: 
2024-08-09 12:49:30 [debug] === Heat ===
2024-08-09 12:49:30 [debug] Bed heaters 0 1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
2024-08-09 12:49:30 [debug] Heater 2 is on, I-accum = 0.0
2024-08-09 12:49:30 [debug] === GCodes ===
2024-08-09 12:49:30 [debug] Movement locks held by null
2024-08-09 12:49:30 [debug] HTTP is idle in state(s) 0
2024-08-09 12:49:30 [debug] Telnet is idle in state(s) 0
2024-08-09 12:49:30 [debug] File is idle in state(s) 0
2024-08-09 12:49:30 [debug] USB is idle in state(s) 0
2024-08-09 12:49:30 [debug] Aux is idle in state(s) 0
2024-08-09 12:49:30 [debug] Trigger is idle in state(s) 0
2024-08-09 12:49:30 [debug] Queue is idle in state(s) 0
2024-08-09 12:49:30 [debug] LCD is idle in state(s) 0
2024-08-09 12:49:30 [debug] Daemon is idle in state(s) 0
2024-08-09 12:49:30 [debug] Autopause is idle in state(s) 0
2024-08-09 12:49:30 [debug] Q0 segments left 0
2024-08-09 12:49:30 [debug] Code queue 0 is empty
2024-08-09 12:49:30 [debug] === Filament sensors ===
check 0 clear 21956288
2024-08-09 12:49:30 [debug] Extruder 0 sensor: ok
2024-08-09 12:49:30 [debug] Extruder 1 sensor: ok
2024-08-09 12:49:30 [debug] === DueX ===
Read count 0, 0.00 reads/min
2024-08-09 12:49:30 [debug] === Network ===
2024-08-09 12:49:30 [debug] Slowest loop: 302.74ms; fastest: 0.08ms
2024-08-09 12:49:30 [debug] Responder states:
2024-08-09 12:49:30 [debug]  HTTP(0)
2024-08-09 12:49:30 [debug]  HTTP(0)
2024-08-09 12:49:30 [debug]  HTTP(0)
2024-08-09 12:49:30 [debug]  FTP(0)
2024-08-09 12:49:30 [debug]  Telnet(0)
2024-08-09 12:49:30 [debug] HTTP sessions: 1 of 8
2024-08-09 12:49:30 [debug] === WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 22587, noresp 91
2024-08-09 12:49:30 [debug] Firmware version 2.1.0
2024-08-09 12:49:30 [debug] MAC address 48:55:19:09:31:80
2024-08-09 12:49:30 [debug] Module reset reason: Power up, Vcc 3.38, flash size 2097152, free heap 23616
2024-08-09 12:49:30 [debug] WiFi IP address 10.1.10.38
2024-08-09 12:49:30 [debug] Signal strength -59dBm, channel 1, mode 802.11n, reconnections 0
2024-08-09 12:49:30 [debug] Clock register 00002002
2024-08-09 12:49:30 [debug] Socket states:
2024-08-09 12:49:30 [debug]  4
2024-08-09 12:49:30 [debug]  0
2024-08-09 12:49:30 [debug]  4
2024-08-09 12:49:30 [debug]  4
2024-08-09 12:49:30 [debug]  0
2024-08-09 12:49:30 [debug]  0
2024-08-09 12:49:30 [debug]  0
2024-08-09 12:49:30 [debug]  0

Since then, I had the Duet in host mode for about a half an hour to get some other things done, and then switched back to client mode. The issue was no longer present after switching back that time.