DuetWifi-error: filename too long
-
I have a problem with the new Duet 1.04. Today I install it in printer wire it and start it up. Everything looks fine, soo I started upgrading the firmware to 3.01 RC04 with I have in all my printers. The procedure went with no problem, but after a few minutes in idle, I get an error : filename too long.
I check everything. All looks fine. I delete all my files from the sd card. The error still occurs. I upgrade firmware to the newest RC06. It doesn't help.
I erase board and write a new 3.01 RC04. No changes.
I erase it again and write 2.03 and install the original sd card with all test files.
It doesn't work. The problem is still there.Any ideas?
-
It looks like the problem files are in the WWW folder which would lead me to think the DWC files haven't been placed properly.
If you're using RRF3 RC6 I suggest you get DWC 2.1.1
https://github.com/chrishamm/DuetWebControl/releases/download/2.1.1/DuetWebControl-SD.zip
Extract that zip file directly into the empty WWW folder
-
I check it already. unfortunately, it doesn't work.
The SD card from the working printer doesn't work too. So I guess it is something with the board. -
Can you send an M122 and report the results?
-
m122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.01-RC6 running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F23T0-6JKDL-3SN6P-KD8NG
Used output buffers: 3 of 24 (9 max)
=== RTOS ===
Static ram: 28052
Dynamic ram: 93028 of which 20 recycled
Exception stack ram used: 264
Never used ram: 9708
Tasks: NETWORK(ready,184) HEAT(blocked,1244) MAIN(running,1904) IDLE(ready,80)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:01:23 ago, cause: software
Last software reset time unknown, reason: User, spinning module GCodes, available RAM 9676 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 32.5, current 33.2, max 33.6
Supply voltage: min 24.1, current 24.3, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2020-04-04 23:30:09
Cache data hit count 156758458
Slowest loop: 3.28ms; fastest: 0.12ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = 0 -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 idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 15.57ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8- WiFi -
Network state is active
WiFi module is providing access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 86:0d:8e:b3:b9:07
WiFi Vcc 3.39, reset reason Unknown
WiFi flash size 4194304, free heap 20112
WiFi IP address 192.168.1.100
Connected clients 1
Socket states: 0 0 0 0 0 0 0 0
- WiFi -
-
Can you post a photo of your /www folder?
-
I checked a few other things and error only occurs when the wifi module is working in access point mode. When I connected the printer to my wifi network problem stoped.
In a few hours, I will have free other printers so I will check it on another boards. -
Have you tried adding "/reprap.htm" (without the quotes) after the IP address in the address bar of your browser?
-
No result. But the error is on paneldue too, even if no pc is connected to access point.
I check older duetwifi(i think it is 1.04) board with rrf3.01cr4 firmware. The problem is still there.
In a few hours I will be able to check it on duetwifi 1.0 with 1.20 firmware.
-
@nikos did you find any solution? I'm getting the same error repeatedly with v 2.05.1 on multiple machines (Duet Wifi 1.04)
In my case it's also unmounting the internal SD card. I have to connect over USB and run M21 P0 to get it back to a normal state.
Disabling the network seems to be a workaround.
-
@nhof said in DuetWifi-error: filename too long:
@nikos did you find any solution? I'm getting the same error repeatedly with v 2.05.1 on multiple machines (Duet Wifi 1.04)
In my case it's also unmounting the internal SD card. I have to connect over USB and run M21 P0 to get it back to a normal state.
Disabling the network seems to be a workaround.
What's the longest file path+name on your SD card, starting from "0:/" and encoded in UTF8 ? The maximum supported by RRF is 120 bytes. Can you make an image or zip of the whole SD card available?
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 -
Hey David,
Longest filepath + name is 45 characters all ASCII chars, so it should be well under 120 bytes utf-8 if I'm not mistaken.
Zip was too large for the forum attachment, so here is a download link: https://drive.google.com/file/d/1dYvssTBlkf0g0Pk8fuPYB2s-CE1HpXLm/view?usp=sharing
-
It looks to me that something on your network is asking for that file from your Duet, and RRF is finding the path is too long when it tries to construct it. Could it be a virus on one of your computers or devices, that scans all the local IP addresses that it can find? Or perhaps some sort of discovery mechanism? If it turns out to be a discovery mechanism, then I could fix the webserver to just return a 404 error if it gets a request for a filename that is too long; but the random characters nature of the filename makes me suspect a virus. It might be trying to provoke a buffer overflow in the code for the web server in some particular device in order to install a virus, hence the long name.
You could use Wireshark or another network packet sniffer to see what device is making that request ti the Duet.
Another thing you could do is connect a PC to the Duet via USB, and send M111 S1 P2 from YAT or another terminal emulator. That should show you what HTTP requests the Duet is receiving.
-
@nikos, if you install the 3.01RC11+1 firmware binary from https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0 then it will report the IP address that is sending the strange request. That may help you to pin down what is causing the error. It will also send a 404 response back, so whatever is making that request may only make it once.
-
I am also getting filename too long errors in the WebControl window with Duet 2 Wifi in access point mode. Notably: not every time. But when I get them, they just continuously flush the screen.
send M111 S1 P2 from YAT or another terminal emulator. That should show you what HTTP requests the Duet is receiving.
I sent the M111 command, here is one screen worth of output (if anybody could comment on why it is formatted in such a weird way, that would be appreciated too (accessing from macOS via USB + Terminal))
HTTP req, command words { GET /ocsp-devid01/ME4wTK<superlongrandomstring>DOB0e/baLCF<longrandomstring2>ZgZo= HTTP/1.1 }, parameters { } Sending reply, file = yes Error: Filename too long: cap=120, dir=0:/www/ name=ocsp-devid01... HTTP connection accepted HTTP req, command words { GET /ocsp04-devid01/ME4wTK<longrandomstring1>DOB0e/baLC<longrandomstring3>Duog= HTTP/1.1 }, parameters { } Sending reply, file = yes Error: Filename too long: cap=120, dir=0:/www/ name=ocsp04-devid... HTTP connection accepted HTTP req, command words { GET /ocsp-devid01/ME4wTK<longrandomstring1>DOB0e/baLCF<longrandomstring2>ZgZo= HTTP/1.1 }, parameters { } Sending reply, file = yes Error: Filename too long: cap=120, dir=0:/www/ name=ocsp-devid01... HTTP connection accepted HTTP req, command words { GET /ocsp-devid01/ME4wTK<longrandomstring1>DOB0e/baLCF<longrandomstring2>ZgZo= HTTP/1.1 }, parameters { } Error: Filename too long: cap=120, dir=0:/www/ name=ocsp-devid01... Sending reply, file = yes HTTP connection accepted HTTP req, command words { GET /ocsp-devid01/ME4wTK<longrandomstring1>DOB0e/baLCF<longrandomstring2>ZgZo= HTTP/1.1 }, parameters { } Sending reply, file = yes Error: Filename too long: cap=120, dir=0:/www/ name=ocsp-devid01... HTTP connection accepted HTTP req, command words { GET /ocsp-devid01/ME4wTK<longrandomstring1>DOB0e/baLCF<longrandomstring2>ZgZo= HTTP/1.1 }, parameters { } Sending reply, file = yes Error: Filename too long: cap=120, dir=0:/www/ name=ocsp-devid01... HTTP connection accepted HTTP req, command words { GET /ocsp-devid01/ME4wTK<longrandomstring1>DOB0e/baLCF<longrandomstring2>ZgZo= HTTP/1.1 }, parameters { } Sending reply, file = yesLet me know if you need more info or things tested. Thanks for your help!
-
I wanted to correct my previous post, but I got the error message "Error: Post content was flagged as spam by Akismet.com" -- yeahhh...
If it matters: the "superlongrandomstring" should be a "longrandomstring1"
I did not want to post them in full -- just in case
-
Seems like the duet is getting ocsp requests (certificate checks), I guess you are using a Mac?
This is normal as the duet is the internet connection for the computer when the duet is in AP mode.
You can turn it off if you want, look here for more information. -
@printHorst said in DuetWifi-error: filename too long:
if anybody could comment on why it is formatted in such a weird way, that would be appreciated too
Change your terminal emulator program settings so that it accepts LF (linefeed) along as a line terminator, instead of expecting CR LF.
-
thanks again for your replies and explanations!
regarding CR and/or LF: I am surprised since macOS should use LF. either way, I did not find a setting in 'terminal' to somehow change how to interpret the text sent from the Duet. it's a bit annoying but not too critical and also, except for the initial setup (and this debugging), I do not need the USB+terminal communication.
the ocsp requests on the other hand are really bad. the status info 'filename too long ...' just completely flushes the screen in the WebControl and I did not find any systematics to when they appear and when not. when they do, it is impossible to work with the printer.
regarding switching the requests off: thanks for the link, however it is very outdated and the setting in the keychain manager does not exist anymore. it also seems like a bad idea to switch of this security feature of the OS(?). I guess that rather this behavior of the OS should be expected and dealt with by the Duet. It sounds like this might be taken care of in version 3.01?@dc42 said in DuetWifi-error: filename too long:
[...] It will also send a 404 response back, so whatever is making that request may only make it once.
Still, there must be many more users using the Duet 2 Wifi in Access Point Mode with macOS and I assume they are not all having this issue. Maybe I should start a new thread to ask around?
Any other hints/ideas are very welcome! Thanks again
-
Try the RRF 3.01 post RC11 firmware binary at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.
