DuetEth not responding to Pings until after reboot
-
@dougal1957
I don't know about the Duet, but I use my DNS server to assign DNS names to IPs. And my DHCP server to assign IPs to MACs. Most things on my network are DHCP, but set them to always receive the same IPs.
Even after I do the above, I still test by IPs and MACs... etc... Google OSI Model...Most of the time checking layers 1 to 3, and somethings 4 (IPs, routing) in that order will help resolve most networking problems. -
@bluedust As i say I am no expert in these matters I use a duet Wifi (i do have a ethernet for an in progress build) but I always give them static IP's and connect using they IP Address and have never come across this issue. But I do wish you luck in tracking it down).
I did have an issue a year or so ago when the Wifi connection suddenly stopped working and that was traced to the router not playing nicely at all used a cheap Tp-Link travel router as a AP Repeater and problem resolved since then I have replaced my main router and I am back to normal.
The router that was causing the issues was a nether one by the way
-
@dougal1957
In this case, no matter what, static on the Duet or not, the Duet MAC has to be on the switch port at all times. If not, the Switch will not know where/what port to send the packets. And your PC keeps an ARP table with every IP address and MAC of local devices, or MAC of Gateway for all devices that need to be reach via gateway/router. I maybe speaking a foreign language now.... But if the MAC isn't on the switch (and the switch is working properly), something maybe wrong with the NIC on the Duet. Funny thing is, it appears to stop working every 20 to 25 days and maybe more often during extended time prints over/around 30 hours. (I also do not shut my 3d Printer off) -
Happened again... Playing with this for a few now...
m122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3S0-7JTDL-3SN6N-TS6VG
Used output buffers: 1 of 20 (16 max)
=== RTOS ===
Static ram: 25524
Dynamic ram: 98316 of which 0 recycled
Exception stack ram used: 592
Never used ram: 6640
Tasks: NETWORK(ready,528) HEAT(blocked,1232) MAIN(running,3776) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 24:08:38 ago, cause: software
Last software reset at 2019-02-26 20:00, reason: User, spinning module GCodes, available RAM 6948 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 8
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 30.5, current 30.6, max 30.9
Supply voltage: min 21.7, current 23.9, max 24.5, 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
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2019-02-27 20:10:05
Cache data hit count 4294967295
Slowest loop: 1.22ms; fastest: 0.08ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 24, completed moves: 24
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.7
=== GCodes ===
Segments left: 0
Stack records: 2 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
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 1.05ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 0 of 8
Interface state 5, link 100Mbps full duplex -
I need to print stuff, and had to reboot it to fix the issue.... next time I guess.
-
@bluedust said in DuetEth not responding to Pings until after reboot:
Funny thing is, it appears to stop working every 20 to 25 days and maybe more often during extended time prints over/around 30 hours. (I also do not shut my 3d Printer off)
I wonder how long are the DHCP leases provided by your router?
-
Just following up to this.... Ever since I installed the Laser Filament Monitor this layer 2 issue hasn't reoccurred. I am not saying it is related to the monitor or by chance an update around that time or even something else... I just know I haven't experienced this issue since the week before I installed the Laser Monitor. Quite odd but I am not complaining.
And now that I said this outload, hoping it doesn't come back to bite me.Thanks!
-
FYI most ARP and MAC table entries are automatically removed after 5 minutes (or less), so not seeing an entry on a switch port usually just means the device hasn't received a frame on the port or from the a MAC address in the last few minutes. Sending (or attempting to send) usually has no effect on that, so its not a very reliable metric for determining which direction fails.
-
@bearer
Sure. But once you ping the IP, the switch would send it out all ports and wait for one to reply and then update its arp table. Saying that I also hard set the Mac on the switch port the printer was plugged into and the Duet2 would still not reply to pings or any other traffic. -
yeah, but you can't rely on arp or mac tables to be sure if the duet actually received the packet in the first place, that was my point. to be sure you need to set up a mirror port or a sniffing bridge.
-
@bearer
Your not wrong. At the time, I didn't have any reason to believe the packets where not going out that port.
I actually already have a mirror setup on that switch for a security appliance. When the problem occured, I manually put the Mac address on that port. When it wasn't on the port automatically, and the switch wouldn't know what port to send it, it would have broadcasted the packets to the Duet2 out of every port. By mirroring that specific port, all I would do was confirm the switch/port was working properly, pings were going out it and the Duet2 wasn't sending data. As everything else worked on the network (even putting a laptop on that port worked) it really looks like the Duet2 couldn't send any packets on the network. If I reset the Nic from the Paneldue or console cable, it still wouldn't connect or even send out a DHCP request. If it did that packet would have caused the switch to see it's Mac and save it in the arp table. I think I even looked for port activity, sending/receiving on the switch graph (managed business switch) but don't remember now as it's been awhile. Also changing the network cable or even to another working port didn't help.
If this happens again I can look at my port mirror data and see if it sees any packets trying to go out that port specifically to that Mac or even a broadcast from my PC trying to find it on the network. -
To be honest I just wanted to make sure anyone who find the thread searhing for their own solution didn't come to rely on all the information.
But unless you catch the problem early I don't see how the switch would even see the ping packet from the computer, as the computer would otherwise just be sending out ARP requests for the IP of the duet knowing nothing of its MAC address and I don't think the switch would respond to the ARP request of the Duet just because the MAC address is added to the port (maybe if its operating as an L3 device and also knowing the IP?).
Would be interesting to see if adding an ARP entry to your local computer made a difference the next time if it happens again.