Hi all, I have a script that does a flood-ping to all of my IoT devices once an hour and sends me an E-Mail if one does not respond. This works just fine EXCEPT for my Amazon Echo devices which do not respond to an ICMP ping. Doing some searching around, someone suggested using an ARP Ping rather than ICMP Ping. Tried that and only get timeout. As a sanity check, I tried ARP Ping to several other devices on my IoT LAN that DO respond to an ICMP Ping just fine, and they also do not respond to an ARP Ping. I have tried this both from the WinBox Ping tool window and also from a command line - /ping a4:da:22:34:a9:fd (with either all lower case and all upper case letters)
When trying from the WinBox ping window, you must specify which interface the command should go out on - which I did correctly or each test. I have tried many devices on several different LANs, and so far the only device that will respond to an ARP Ping is my other Mikrotik router. There is nothing in the IP firewall that should affect this, but I would not expect so since an ARP is not IP traffic...

Am I missing something obvious?

I have tried this both from the WinBox Ping tool window and also from a command line - /ping a4:da:22:34:a9:fd (with either all lower case and all upper case letters)

Is this ARP ping or MAC ping ???

There is IP PING and MAC PING (not all interfaces are set to respond to MAC requests by default).
Both have the option of ARP Ping, and then do require the interface to be specified.
. . .
. Just exploring the user-interfaces, and seeing "/ping a4:da:22:34:a9:fd" as different from a regular ARP request ("who has ip xxxxxx")
And now the wiki makes sense :-) ... https://wiki.mikrotik.com/wiki/Manual:Tools/Ping

On images you ping the RouterBOARD, is not the same with Amazon devices:

How to ping Echo Plus:

I should have been more specific - and titled this thread a bit different.... Your last screen capture (klembord-2.jpg) was exactly what I was doing when trying from the WinBox ping command. I have tried it both with and without the "ARP Ping" checkbox set. Same result - timeout on every device I have tried on every interface except my other router.
The router I am trying this on is a RB750Gr3 with 6.48.2. Ether-1 is the Internet WAN interface, Ether-2 and -3 are separate LANs (untagged), and Ether-4 is a VLAN trunk with about a dozen VLANs on it. Ether-5 is an untagged LAN that directly connects to a similar port on router #2. All other ports connect to a CSS326 switch. There is no bridge in the router.

Your CPU is on same vlan as the Echo?

EDIT: The routerboard used for test has linked the CPU with the VLAN where echo is placed?

What DHCP server are used for echo device?
On what vlan/bridge/interface are that DHCP server?

Klembord-2.jpg is a regular ICMP PING, or is a normal ARP request (if ARP Ping is ticked) based on IP address.
For the regular ICMP PING specifying the interface is not needed, normal routing is used.
For the ARP Ping option, the interface is needed, as this is not normal IP traffic, but a supporting L2 protocol. (ARP and RARP)

I hope you defined and selected the various VLAN interfaces in the RB750Gr3 , if you want to scan the VLAN devices. (I do not expect this to work if Ether-4 is set as interface for ARP Ping).
But all this is just an open door to you. Just thinking loud.

...Hi all, I have a script that does a flood-ping to all of my IoT devices once an hour and sends me an E-Mail if one does not respond...

You can just use other methods ... try asking ... don't just insist on your solution, it may happen that someone has another idea ...

Rextended is on the right track, but confirm that this is not actually pinging the device, but rather querying the ARP table? The reason I ask is because I was getting 0mSec response time - which over my WiFi does not make sense for pinging the device. Further I did a test shown below where I was ARP Pinging one of my Echo Dots and at SEQ 10, I unplugged the Echo and the pings continued to work for about the next 30 seconds. After that, the ping command was showing that it was pinging the IP and failing.
I did one more test where I was watching the router ARP list for this Echo Dot and pulled power on it. In about 20 seconds, the listing for this device changed status from DC to D, but the listing remained for at least the couple minutes before plugging the Echo back in. I see there are devices listed in the ARP list with a status of Dynamic (not Competed) that have not been on my LAN for many hours (WiFi cameras in my truck which has been at the mechnic's shop for about six hours).
So let's see if I understand what was going on. When I did the arp-ping to the IP, all that was happening was the router looked up that IP in the ARP table and returned up MAC. After about 30 seconds, the ARP table dropped the Completed status, so the ping now had to use the IP address, which we all know will not respond from an Echo device.
If that is correct, I should be able to rework my script to detect the expected MAC vs timeout - which will accomplish what I am trying to do.

I'm just trying to make sure I understand what is going on...

Fact: Echo use DHCP server
Fact: Some static DHCP server leases can be made, with personalized lease time

Concept: set lease time to 5 min and later check if lease:
are bound: the device is online
are not bound (waiting, etc.): the device is offline

Simply and clear.

P.S.: Some automation can be maded directly on DHCP Server lease script (launched only on bound and release/waiting, not on renew) to set directly one global var or launch some script (for example send email/sms/whatsapp with warning)

is not the same with Amazon devices:

The IP address based PING and ARP Ping .... I don't see the difference with Amazon Echo. MAC Ping was only there because OP wanted ARP Ping but used the MAC Ping syntax.

the ARP table dropped the Completed status, so the ping now had to use the IP address, which we all know will not respond from an Echo device.

Does this mean the Echo device is not answering an ARP request ? (ARP ping should just be an ARP request) How does the ARP table get filled then ?

Because the table "see" the IP on local broadcast, sync with cloud, and when get is own IP from DHCP Server

Damn, I had a really nice response all typed up and it went into oblivion...

Short answer is that I will work with checking DHCP status with a short lease time. Thanks for that suggestion.

Maybe it is not what it sounds like, but at least.
ARP Ping from 192.168.2.21 (MT) to 192.168.2.25 (MT connected via wifi-ether-switch-ether) ... I see some things

1. The 192.168.2.25 is NOT in the ARP list (it only appears when I do a regular ping, it is not triggered by an ARP Ping)
2. My laptop on the same L2 networks, sees the ARP requests from 192.168.2.21 asking for the MAC of 192.168.2.25 , when the ARP PING is running
3. Sometimes there is a regular ping to 192.168.2.24 (my laptop). The ARP answer is also send to the 192.168.2.24 from the 192.168.2.21 (my laptop is connected with winbox)
4. If I check a device that is connected to ethernet interface or WLAN interface of 21, the time is zero or near zero. (23 is wifi connected). The MAC addresses are not in the ARP list.
And to conclude. If The 192.168.2.25 is active in the ARP table , but removed (in this case rebooted), then the ARP ping goes in timeout instantly, while the entry is still in the ARP List
So the ARP list is not used by ARP PING , is my deduction.

.
Consistent with Linux Arping after all. https://devconnected.com/arping-command ... explained/