WiFi Unreliable
-
@phaedrux I initially tried
M589with a custom SSID and password, but that didn't initially work so I triedM589 S"DuetSSID" P"password" I192.168.0.1 C1from the example. It disconnected from my modem, but it wasn't broadcasting the SSID so I couldn't connect to it. -
Did you try sending M552 S2 after that? That should enable the module in AP mode.
-
@phaedrux I'm trying this now, but the second I send
M589the duet goes offline and is unreachable. I'll have to try via USB. -
@dessiverse This may not be your problem. On a previous firmware for my ASUS RT-AX56U, I had to reboot the router once in a while to get back my wifi connections to my printers. Duet 3 6HC with a PI 4 and Mini 5+.
-
@stephen6309 That's, concerning.
-
@phaedrux Hello, finally got to test it, and using the Duet in AP mode there were 0 speed issues. Any ideas as to the causality of the original problem?
-
So AP mode the speed is great, but when connecting through your router the speed is poor?
That would tell me there might be something going on with your router settings maybe. What kind of wifi router are you using?
-
@phaedrux It's the Xfinity Modem / Router combo. I don't think it's an issue with the router only because no devices on my network have any speed issues. Even 2.4GHz devices. I have a Pi 3 that runs on 2.4GHz mode that I was using with SBC and it had no issues with speed.
EDIT: Is there any diagnosing things I can do to confirm if that is the case somehow?
-
I'm not saying the router has a problem in and of itself, other than it might not be playing nicely with the duet wifi module. Though any time there have been issues like this it's been with ISP provided gear. Off the shelf stuff usually works without issue.
You mentioned a wifi repeater as well. What is it and how is it configured? Is the Duet using the repeater or direct to the router?
-
@phaedrux The repeater is like a pod Xfinity offers? I'm not really sure how it is configured. The Duet is using the repeater as well
-
@phaedrux Question, is it possible to view the dashboard via OctoPrint or another way? I'm trying to see if I can bridge the connection to mitigate the WiFi issue
-
@dessiverse said in WiFi Unreliable:
Is there any diagnosing things I can do to confirm if that is the case somehow?
Maybe try tracert (win) or traceroute (linux) to the Duet from other machines may give some clues. If there are repeaters involved the results may (or not
) point to some differences.
Also - is the repeater a bridge (same ip subnet on either side of the repeater) or is there a different subnet to the router? If the latter - what happens when everything is on the router side with the repeater turned off (just for luck
) ? -
@stuartofmt I tried SSHing into the duet but it wasn't letting me connect? It kept saying connection refused so I couldn't diagnose most things at its end
-
@dessiverse, here is how you can test whether it is the WiFi or the SD card writing that is slowing down the upload speed in standalone mode:
-
To test the upload speed, rename a large GCode file (or any other file) to a name ending in ".dummy", then try to upload it on the Jobs page. You will need to set the file filter to "all files" to allow you to select that file. This will upload the file without writing it to SD card.
-
To test the SD card write speed, send M122 P104.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
-
@dc42 It's not the SD Card because when using the duet in AP mode the upload speed was perfectly fine. So that loops it back to, how do I narrow down what's causing the WiFi on the duet to be slow when it isn't a problem with other devices on the network?
-
@dessiverse said in WiFi Unreliable:
I tried SSHing into the duet
I'm not aware that Duet supports SSH so that error makes sense
What I had in mind was from some other machine (like the one that you are trying to upload from) to the Duet. e.g. tracert Ip-address-of-duet.
What you want to see is a direct connection - something like this (from my win machine to my Duet (at 192.168.1.150:C:\Users\stuar>tracert 192.168.86.235 Tracing route to 192.168.86.235 over a maximum of 30 hops 1 164 ms 7 ms 9 ms 192.168.1.150 Trace complete.Thinking about this - better commands may be pathping (win) or tracepath (linux). They basically combine tracert and ping in one command. For example - my equivalent of the above is:
C:\Users\stuar>pathping 192.168.86.235 Tracing route to 192.168.1.150 over a maximum of 30 hops 0 Stuart [192.168.1.5] 1 192.168.1.150 Computing statistics for 25 seconds... Source to Here This Node/Link Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address 0 Stuart [192.168.1.5] 0/ 100 = 0% | 1 9ms 0/ 100 = 0% 0/ 100 = 0% 192.168.1.150 Trace complete.and throw in the results of ping for good measure.
Basically just trying to rule out any strange network routing.
-
@dc42 said in WiFi Unreliable:
M122 P104.
Result of this is
Send: M122 P104 Recv: Testing SD card write speed... Recv: SD write speed for 10.0Mbyte file was 2.66Mbytes/sec Recv: Testing SD card read speed... Recv: SD read speed for 10.0Mbyte file was 1.54Mbytes/sec -
@stuartofmt here's the results of that test:
destinybonavita@MacBook-Pro ~ % traceroute 10.0.0.201 traceroute to 10.0.0.201 (10.0.0.201), 64 hops max, 52 byte packets 1 10.0.0.201 (10.0.0.201) 8.712 ms 13.885 ms 5.475 ms destinybonavita@MacBook-Pro ~ % ping 10.0.0.201 PING 10.0.0.201 (10.0.0.201): 56 data bytes 64 bytes from 10.0.0.201: icmp_seq=0 ttl=255 time=13.169 ms 64 bytes from 10.0.0.201: icmp_seq=1 ttl=255 time=11.783 ms 64 bytes from 10.0.0.201: icmp_seq=2 ttl=255 time=34.763 ms 64 bytes from 10.0.0.201: icmp_seq=3 ttl=255 time=6.772 ms 64 bytes from 10.0.0.201: icmp_seq=4 ttl=255 time=51.055 ms 64 bytes from 10.0.0.201: icmp_seq=5 ttl=255 time=9.359 ms 64 bytes from 10.0.0.201: icmp_seq=6 ttl=255 time=12.984 ms 64 bytes from 10.0.0.201: icmp_seq=7 ttl=255 time=8.528 ms 64 bytes from 10.0.0.201: icmp_seq=8 ttl=255 time=23.638 ms Request timeout for icmp_seq 9 64 bytes from 10.0.0.201: icmp_seq=10 ttl=255 time=15.351 ms 64 bytes from 10.0.0.201: icmp_seq=11 ttl=255 time=18.995 ms Request timeout for icmp_seq 12 64 bytes from 10.0.0.201: icmp_seq=13 ttl=255 time=34.696 ms 64 bytes from 10.0.0.201: icmp_seq=14 ttl=255 time=52.520 ms 64 bytes from 10.0.0.201: icmp_seq=15 ttl=255 time=4.912 ms 64 bytes from 10.0.0.201: icmp_seq=16 ttl=255 time=21.125 ms 64 bytes from 10.0.0.201: icmp_seq=17 ttl=255 time=13.998 ms 64 bytes from 10.0.0.201: icmp_seq=18 ttl=255 time=36.809 ms ^C --- 10.0.0.201 ping statistics --- 19 packets transmitted, 17 packets received, 10.5% packet loss round-trip min/avg/max/stddev = 4.912/21.792/52.520/14.487 ms -
@dessiverse said in WiFi Unreliable:
here's the results of that test
Don't like the timeouts on a LAN ... What happens when you ping the router ? Do you see time out's occurring there ?
-
@stuartofmt nope
destinybonavita@MacBook-Pro ~ % ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=5.392 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=7.069 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=4.732 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=5.586 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=4.150 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=3.499 ms 64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=4.984 ms 64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=10.994 ms 64 bytes from 10.0.0.1: icmp_seq=8 ttl=64 time=10.078 ms 64 bytes from 10.0.0.1: icmp_seq=9 ttl=64 time=1.937 ms 64 bytes from 10.0.0.1: icmp_seq=10 ttl=64 time=3.131 ms 64 bytes from 10.0.0.1: icmp_seq=11 ttl=64 time=3.873 ms 64 bytes from 10.0.0.1: icmp_seq=12 ttl=64 time=11.292 ms 64 bytes from 10.0.0.1: icmp_seq=13 ttl=64 time=5.367 ms 64 bytes from 10.0.0.1: icmp_seq=14 ttl=64 time=4.908 ms 64 bytes from 10.0.0.1: icmp_seq=15 ttl=64 time=10.782 ms 64 bytes from 10.0.0.1: icmp_seq=16 ttl=64 time=4.683 ms 64 bytes from 10.0.0.1: icmp_seq=17 ttl=64 time=2.373 ms 64 bytes from 10.0.0.1: icmp_seq=18 ttl=64 time=2.985 ms 64 bytes from 10.0.0.1: icmp_seq=19 ttl=64 time=2.831 ms 64 bytes from 10.0.0.1: icmp_seq=20 ttl=64 time=4.145 ms 64 bytes from 10.0.0.1: icmp_seq=21 ttl=64 time=5.388 ms 64 bytes from 10.0.0.1: icmp_seq=22 ttl=64 time=12.284 ms 64 bytes from 10.0.0.1: icmp_seq=23 ttl=64 time=5.878 ms 64 bytes from 10.0.0.1: icmp_seq=24 ttl=64 time=9.148 ms 64 bytes from 10.0.0.1: icmp_seq=25 ttl=64 time=10.261 ms ^C --- 10.0.0.1 ping statistics --- 26 packets transmitted, 26 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.937/6.067/12.284/3.055 ms destinybonavita@MacBook-Pro ~ %
