New firmware 1.18RC1
-
No problem
If I can be of any help for testing, let me know as I have access to multiple Duets of varying versions on a range of setups… 4x v0.6, 3x 0.8.5, and a WiFi running deltas, Cartesian, and 5-axis.In the near future I'm also going to be looking at upgrading a 3DP workbench with a duet ethernet. However, I need to know that this current issue won't occur on that setup too, as it'll be on the same network and will need need to be able to function pretty much indefinitely without being power cycled.
FWIW, when I got into work this morning the Fisher that sits on my desk was unresponsive again although after a power cycle now seems to be working again (touch wood).
-
str8up, those bed probe heights look wrong to me. I will do some tests.
ChrisP, please can you load 1.16RC1 on one of your wired Duets and run M122 so that we can see how much free memory it has.
The Duet Ethernet uses a different network stack from the older Duets, so it is most unlikely to suffer from the same problem.
-
I'm going to assume that you meant 1.18RC1….
[[language]] M122 === Diagnostics === Used output buffers: 2 of 32 (8 max) === Platform === Static ram used: 45844 Dynamic ram used: 39916 Recycled dynamic ram: 256 Stack ram used: 1088 current, 4944 maximum Never used ram: 7344 Last reset 00:04:47 ago, cause: power up Last software reset code 0x7003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0042f00f, BFAR 0xe000ed38, SP 0xffffffff Spinning module during software reset: GCodes, available RAM 5848 bytes (slot 1) Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 21.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 36.4, current 40.7, max 48.3 Date/time: 2017-03-30 11:28:46 Slowest main loop (seconds): 0.060730; fastest: 0.000110 === Move === MaxReps: 3, StepErrors: 0, MaxWait: 972ms, Underruns: 0, 0 Scheduled moves: 5, completed moves: 5 Bed compensation in use: mesh Bed probe heights: 0.000 0.000 -0.057 -0.011 -0.002 === Heat === Bed heater = -1, chamber heater = -1 === GCodes === Segments left: 0 Stack records: 1 allocated, 0 in use 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 serial is idle in state(s) 0 aux is idle in state(s) 0 daemon is idle in state(s) 0 queue is idle in state(s) 0 Code queue is empty. === Network === Free connections: 15 of 16 Free transactions: 23 of 24 === Webserver === HTTP sessions: 1 of 8 FTP connections: 0, state 0 Telnet connections: 0, state 0 -
Thanks, that looks good in particular the never used RAM.
-
Ok, so it's died again (as in the web interface just sits loading indefinitely) having not been touched at all since the log I got for you before. I can still connect to it using USB though. Running M122 again gives the log below. I notice that it has 255 telnet connections. Could this be whats killing it?
[[language]] === Diagnostics === Used output buffers: 1 of 32 (17 max) === Platform === Static ram used: 45844 Dynamic ram used: 39916 Recycled dynamic ram: 256 Stack ram used: 3240 current, 4944 maximum Never used ram: 7344 Last reset 02:55:59 ago, cause: power up Last software reset code 0x7003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0042f00f, BFAR 0xe000ed38, SP 0xffffffff Spinning module during software reset: GCodes, available RAM 5848 bytes (slot 1) Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 21.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 38.6, current 49.8, max 54.7 Date/time: 2017-03-30 14:19:59 Slowest main loop (seconds): 0.060425; fastest: 0.000000 === Move === MaxReps: 0, StepErrors: 0, MaxWait: 0ms, Underruns: 0, 0 Scheduled moves: 5, completed moves: 5 Bed compensation in use: mesh Bed probe heights: 0.000 0.000 -0.057 -0.011 -0.002 === Heat === Bed heater = -1, chamber heater = -1 === GCodes === Segments left: 0 Stack records: 1 allocated, 0 in use 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 serial is ready with "M122" in state(s) 0 aux is idle in state(s) 0 daemon is idle in state(s) 0 queue is idle in state(s) 0 Code queue is empty. === Network === Free connections: 1 of 16 Free transactions: 24 of 24 === Webserver === HTTP sessions: 0 of 8 FTP connections: 0, state 0 Telnet connections: 255, state 1 okedit: So I just disabled Telnet using USB and now I can get the web interface to load a basic text version that looks pretty awful. Every time I try to load / re-load the page, the terminal gives the following message too.
[[language]] Network::ConnectionAccepted() - no free ConnectionStates! ```and occasionally this:[[language]]
Network: Connection error, code -11And finally, power cycling fixed everything again. -
Indeed it looks like it kept opening new Telnet connections and that used up all the network resources, which didn't all get freed when you disabled Telnet. Did you have any Telnet sessions to the Duet?
-
No I didn't have any sessions open. That's not to say that someone else on the network wasn't trying to gain access though…
For the time being, I've just disabled Telnet in the config and I'll see how it goes. -
Here is the heightmap.csv data.
RepRapFirmware height map file v1 generated at 2017-02-30 10:19, mean error -0.01, deviation 0.12
xmin,xmax,ymin,ymax,radius,spacing,xnum,ynum
-100.00,100.10,-100.00,100.10,105.00,20.00,11,11
0, 0, 0, 0, -0.107, -0.261, -0.329, 0, 0, 0, 0
0, 0, 0.041, -0.028, -0.038, -0.016, -0.050, -0.051, -0.177, 0, 0
0, -0.032, -0.144, -0.122, -0.152, -0.150, -0.120, -0.119, -0.113, -0.012, 0
0, -0.034, -0.019, 0.040, 0.043, 0.100, 0.131, 0.080, 0.059, 0.122, 0
0, -0.098, -0.132, -0.081, -0.059, -0.030, 0.039, -0.010, 0.059, 0.109, 0.153
0, -0.078, -0.041, 0.017, 0.089, 0.109, 0.170, 0.161, 0.193, 0.159, 0.202
0, -0.140, -0.159, -0.080, -0.032, 0.050, 0.067, 0.137, 0.160, 0.151, 0.121
0, -0.071, -0.059, -0.039, -0.068, -0.018, 0.012, 0.077, 0.191, 0.270, 0
0, 0, -0.122, -0.237, -0.149, -0.061, 0.020, 0.060, 0.117, 0.102, 0
0, 0, 0, -0.128, -0.093, -0.043, -0.021, 0.048, 0.090, 0, 0
0, 0, 0, 0, 0, -0.052, -0.069, 0, 0, 0, 0 -
Here is the heightmap.csv data.
RepRapFirmware height map file v1 generated at 2017-02-30 10:19, mean error -0.01, deviation 0.12
xmin,xmax,ymin,ymax,radius,spacing,xnum,ynum
-100.00,100.10,-100.00,100.10,105.00,20.00,11,11
0, 0, 0, 0, -0.107, -0.261, -0.329, 0, 0, 0, 0
0, 0, 0.041, -0.028, -0.038, -0.016, -0.050, -0.051, -0.177, 0, 0
0, -0.032, -0.144, -0.122, -0.152, -0.150, -0.120, -0.119, -0.113, -0.012, 0
0, -0.034, -0.019, 0.040, 0.043, 0.100, 0.131, 0.080, 0.059, 0.122, 0
0, -0.098, -0.132, -0.081, -0.059, -0.030, 0.039, -0.010, 0.059, 0.109, 0.153
0, -0.078, -0.041, 0.017, 0.089, 0.109, 0.170, 0.161, 0.193, 0.159, 0.202
0, -0.140, -0.159, -0.080, -0.032, 0.050, 0.067, 0.137, 0.160, 0.151, 0.121
0, -0.071, -0.059, -0.039, -0.068, -0.018, 0.012, 0.077, 0.191, 0.270, 0
0, 0, -0.122, -0.237, -0.149, -0.061, 0.020, 0.060, 0.117, 0.102, 0
0, 0, 0, -0.128, -0.093, -0.043, -0.021, 0.048, 0.090, 0, 0
0, 0, 0, 0, 0, -0.052, -0.069, 0, 0, 0, 0Thanks. The bed probe heights are correct, because after G29 you will see the first 5 points from the height map. The first 4 are zero because you are probing a circular bed.
-
No I didn't have any sessions open. That's not to say that someone else on the network wasn't trying to gain access though…
For the time being, I've just disabled Telnet in the config and I'll see how it goes.If this is a corporate network there could be all sorts of port scanners, vulnerability assessment tools or even, unfortunately, compromised machines looking to spread a virus or malware. These may well see the Duet as an 'interesting' target as telnet is a legacy protocol that used to be in use by network infrastructure vendors a great deal. There a huge lists of default passwords and usernames out there that these programs use to brute force the telnet connection and take over such devices. One example of such a list:
http://www.defaultpassword.com/
If this is a smaller office or home network then the malware/virus case is more likely. It might be possible to identify the source traffic, either by binary search (Switch half of the machines off, if the problem recurs, switch half of the remainder off, etc). Alternatively, you could use a tool like Wireshark to look for the offending node but this is more complex with WiFi in the mix.
Hope this helps.
David
edit - clarity
-
This is why I added the facility to support http but not telnet or ftp, with telnet and ftp turned off by default. But it doesn't explain why earlier versions of firmware worki for ChrisP.
-
I'm on a university network, so I'm pretty certain that there's at least one machine that will have been hacked and is scanning all the ports. To be honest, I probably should have figured out the problem sooner as it's not the first time it's happened.
As for it working with other firmware, I wonder whether it was just an unfortunate coincidence. When I had the problem back on Wednesday, I had tried older firmware versions and had those fail too - that's what initially made me wonder whether it was a hardware problem.
Anyway, having turned off Telnet (which I didn't use anyway), all is fine again… hopefully
-
Hi David, I know previously we discussed using G30 to reset the z height after grid levelling/calibration and you mentioned doing this on a grid point. I just installed this firmware and after calibration I did a G30. I noticed the nozzle change x,y position fractionally before the G30 executed, does the firmware auto position on a grid point for this in this version?
-
No it doesn't, but in this version bed compensation and orthogonal axis compensation are disabled during homing moves.
-
I've just released firmware 1.18RC2. I am particularly keen for Duet 0.6/0.8.5 users to test it, to see if it resolves the network issues that some users had with beta3 and RC1.
-
ChrisP, thanks for your patience. Please can you try the Duet06/085 firmware at https://dl.dropboxusercontent.com/u/19369680/RepRapFirmware.bin and let me know if you have stability problems with it. If you find that you are unable to connect via HTTP at all, then please run M122 from USB and report the Network section of the diagnostic report.
-
No problem.
I updated a couple of Duet 06 boards at work to 1.18RC2 and disabled Telnet and haven't had any stability problems since. Unusually, I haven't actually used those printers in the past day or so, but they have been left on 24/7 and I haven't had any problems connecting via HTTP. I'll try the FW in your link anyway, in particular with my old Duet 06 at home that I never managed to get to work on anything beyond 1.17e. -
ChrisP, I think I found the problem. Does your home network have a zero in the IP addresses it uses?
-
Yes it does. 192.168.0.x
-
Thanks for confirming that. The problem is fixed in the 1.18 release.
