DuetEth not responding to Pings until after reboot
-
your ping is actually not working by the look of it you are pinging.78 but looking for replies from .61 that doesn't look right to me but I am no expert with that side of things.
-
@dougal1957
.61 is the IP of the computer I am using. In Windows 10 (maybe in Win7 and 8 too), it was changed to show the local IP when it fails and then says detestation host unreachable.... , but have no idea why Microsoft changed to say this. At a first quick glance, its just confusing. If you read it, it looks like its saying your local computer is telling you the destination device in not responding pings. But telling me the ping failed/dropped like it used to in Win XP would tell me the same thing... If Microsoft wanted to be fancy, they could simply say ICMP failed, and force people to Google it, and make them learn something.ping 10.1.10.78
Pinging 10.1.10.78 with 32 bytes of data:
Reply from 10.1.10.61: Destination host unreachable.
Reply from 10.1.10.61: Destination host unreachable.
Reply from 10.1.10.61: Destination host unreachable.
Reply from 10.1.10.61: Destination host unreachable.Ping statistics for 10.1.10.78:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), -
@dc42
I am testing this from 2 different computers.
I wasn't able to find the MAC on the switch or my computers arp tables.
I rebooted the switch and that didn't fix it.I rebooted the DuetEth board, and everything is working again.
ping 10.1.10.78
Pinging 10.1.10.78 with 32 bytes of data:
Reply from 10.1.10.78: bytes=32 time=91ms TTL=128
Reply from 10.1.10.78: bytes=32 time<1ms TTL=128
Reply from 10.1.10.78: bytes=32 time<1ms TTL=128
Reply from 10.1.10.78: bytes=32 time<1ms TTL=128Ping statistics for 10.1.10.78:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 91ms, Average = 22msI can also now see the MAC on the switch, and it also shows up again in the arp tables on both computers.
Unless you have a different idea/test, next time this happens, I will add the MAC as static to port 8 on my switch and the arp table with IP on my PC to see if it works again. I don't know much about this side of things, but if that works, I am guessing the NIC isn't sending packets out with its mac, or stopped sending packets all together (if it doesn't work). If it stopped sending packets, I am not sure why the green light was blinking at all, unless that is only for receiving packets (and could have been broadcasts from other devices on my network).
Thanks for your help.
-
@bluedust Well you learn something every day lol I don't use Win10 so hadn't seen that change before how confusing! Have you tried setting a fixed IP on the Duet and I think I read somewhere that MDNS could be flakey.
In fact the following thread says mDNS is not supported on the Ethernet boards.
mDNS
although it is an old thread so things may have changed! -
@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.