[Feature Request] scan “retry” until mark as device down

[huuscript]

Is there an option to state how many request before mark as device down?

In previous fork there is this option:

Scan Cycle: Select the scan cycle: 0, 1', 15'
Some devices do not respond to all ARP packets, for this cases is better to use a 15' cycle.
For Apple devices I recommend using 15' cycle

now there is only 0,1
has it been move somewhere or a different implementation for this feature?

thanks

[stanelie]

+1, I would like this feature as well, some of my devices are unreliable and I get many false positives (down alerts) with them.

Thanks!

[leiweibau]

I can understand the request, but I would also like to point out the problems that are not seen here:

More retries mean significantly more time for the scan. What does an additional longer scan mean, as in the original project?

• There are certainly several scans running at the same time (short scan, long scan)
• WIFI-IoT devices or other “weak” clients that are connected to WIFI will have significant connection problems or even disconnections during the scans. This is not an assumption, but has been tested with Raspberry Zero and 2b via WIFI. A scan can therefore even be the cause if a device goes down.
• If these scans run in parallel, they may slow each other down and therefore run in parallel for even longer and in increasing numbers
• The database can be blocked if several scans try to write their results
• The front end can become unusable if the arp scans build up because the database is no longer available for access

Who then has to deal with bug reports and troubleshooting messages?
No, there will be no additional cycle. What I might still agree to would be a self-configurable “retry” parameter.

[huuscript]

ahh Yes i agree, now i understand why you remove the 15’ scan. Yes.. We need something like a setting which take more “retry” before report as down. I think retry are more useful then the scan interval anyway, as no mater which interval we set there is always a chance to ping right at dead time of the device. So let change the heading to retry instead of interval. Thanks for considering it.

[stanelie]

In my case, there is no need for more scans running in parallel. All that is needed it a counter of failed attempts per devices. Each time a scan runs, the counter is incremented. Whenever the counter reaches the "allow x failed attempts" setting of the devices, a notification is sent. I accept that if the device fails, I will get a delayed notification that has x times (scan interval) total time delay.

[leiweibau]

I have the impression that there is a lack of clarity about how it works.

Once again for explanation:
The arp-scan tool sends an ARP request to each IP of the local network, to which the corresponding device behind the IP responds with its Mac address. If the request times out, the request (retry) is sent again. If there is no response after the defined number of retries, there is no host behind the IP for the arp-scan tool. At the end, arp-scan displays a list of MAC addresses and IPs that have responded. This list is compared with the database. All devices found by arp-scan are online, the others are offline

Whenever the counter reaches the "allow x failed attempts" setting of the devices, a notification is sent.

This request makes no sense in view of how arp-scan works. Firstly, the tool does not indicate how many retries it has used per device and secondly, you end up with the message for the corresponding event for the device.

[stanelie]

Hum... Maybe I was not clear.

Let's say I've set a device to allow for one failure before saying the device is offline. Regardless of the number of retries from arpscan during a unique scan cycle, if the device fails to respond during this scan cycle, note that it has failed once but leave it's status as "online", and do not send the alert yet. Then, at the next arpscan cycle, if it fails again, and only then, send an alert. If it is back online, reset the "failed attempts" counter and leave it as "online".

Does this make sense?

[leiweibau]

@huuscript
Do you and @stanelie mean the same thing, or are you talking about different things

[huuscript]

yes same thing. no need to change the scan cycle, just when to mark that device is down. Let say we have 2 scenarios.
1 1 1 1 1 o 1 1 1 1 o 1 1 1 o 1 o 1 1 1 1 o 1
1 1 1 1 1 1 1 1 1 1 o o o o o o o o o o o o o
^
the first scenario would have 5 offline notifications and second scenario would have one “offline” notification.
if we can adjust the number “failed attempts” (let say 3 in above example at ^)
then the first scenario would not show as “offline” and second scenario would show as offline at the third “failed attemps”

[upD8R]

Not sure what the best approach is but I'd also like to see some (configurable) behavior for offline notifications.

Especially, my Shellys are unreliable, therefore I turned off the down notification. Usually, they work just fine. But a few days ago I realized one of them was offline for a few weeks (it is rarely used).

I'm my case I'd like to turn on the Down notification but I want to be notified only if the device is down for e.g. 3 scans in a row. Because what usually happens, it's down and up at the next scan and this can happen a dozen times per day.

So an additional counter in the DB might help with that? Don't know ...

[leiweibau]

Even though it may seem like I've forgotten about the topic, I'm still looking into it, but I'm still struggling with the approach. 😔