Switch from non-forked version?

[hspindel]

Hello,

I recently installed pi.alert and ran into some install issues which I documented here:

pucherot/Pi.Alert#234

It seems like this fork is more actively maintained. Is that correct? Does it address any of the issues I mentioned?

What is the best way to migrate from the original pi.alert? Download the new source files and copy them over the existing? Or run the full installer?

Thank you.

[leiweibau]

python3 back/pialert.py
reports error: not found

In what context did this error occur? The statement is correct as such. The correct path is namely ~/pialert/back/pyalert.py

What does the owner field mean on the web page? Where does it get owner information? Same question for the Favorite and Group fields.

These are simply fields with organizational background.

The install process couldn't find two of the files. The files were usr/share/arp-scan/ieee-oui.txt and /usr/share/arp-scan/ieee-iab.txt.

This whole "vendor update" issue has been addressed in several issues. In my fork the problem was fixed.

Would be nice if there was a way to check if email notifications are configured correctly by causing a test email to be sent.

Yes, there is a test function in my fork. But besides email I have also integrated other notification services.

Very minor cosmetic only issue: In the file deviceDetails.php, the word Sessions is misspelled as Sesions on one of the web pages.

With the removal of this bug my fork started ;-)

What is the best way to migrate from the original pi.alert? Download the new source files and copy them over the existing? Or run the full installer?

pucherot/Pi.Alert#232 (comment)

[hspindel]

Hi,

Thank you very much for the detailed response. See comments below.

python3 back/pialert.py
reports error: not found

In what context did this error occur? The statement is correct as such. The correct path is namely ~/pialert/back/pyalert.py

I am issuing the command from a telnet session on debian/pihole device, stqrting in the root/pialert directory. Since pialert is working, I suspect this is user error on my part not understanding what it is supposed to do.

The install process couldn't find two of the files. The files were usr/share/arp-scan/ieee-oui.txt and /usr/share/arp-scan/ieee-iab.txt.

This whole "vendor update" issue has been addressed in several issues. In my fork the problem was fixed.

Confirm works now.

Would be nice if there was a way to check if email notifications are configured correctly by causing a test email to be sent.

Yes, there is a test function in my fork. But besides email I have also integrated other notification services.

Works great. The new features for SMTP_SKIP_TLS and SMTP_SKIP_LOGIN fixed all my email issues. Thank you for these badly needed additions.

Very minor cosmetic only issue: In the file deviceDetails.php, the word Sessions is misspelled as Sesions on one of the web pages.

With the removal of this bug my fork started ;-)

Confirm it's fixed.

Addition I'd suggest:

On the devices page, add ability to show the vendor (unless it's there and I'm somehow missing it).

[hspindel]

Ran into one new issue. I have pialert.conf with the following config line:

MAC_IGNORE_LIST = ['94:A6:7E:23:45:66', '84:1B:5E:28:7B:6B']

I still get reports like this:

84:1b:5e:28:7b:6b | 2023-07-08 20:36:00 | 192.1.1.200 | IP Changed | isyaccesspt.sci1.com | Previous IP: 192.1.1.252

So why is pialert telling me about a MAC address I told it to ignore? I wasn't sure about the syntax of the MAC_IGNORE_LIST, so I tried it both with a comma between entries and without.

[leiweibau]

So why is pialert telling me about a MAC address I told it to ignore?

Okay, I guess I didn't document properly here. In the ignore list, the entries must be lower case.
MAC_IGNORE_LIST = ['94:a6:7e:23:45:66', '84:1b:5e:28:7b:6b']

[hspindel]

Thank you for the reply. I updated my pialert.conf file to use lowercase MAC addresses, but I am still getting notifications for devices on the MAC_IGNORE_LIST. My config file looks like this now:

MAC_IGNORE_LIST = ['94:a6:7e:23:45:66', '84:1b:5e:28:7b:6b']

Here is a sample email notification:

84:1b:5e:28:7b:6b	2023-07-09 04:18:00	192.1.1.252	IP Changed	isyaccesspt.sci1.com	Previous IP: 192.1.1.200

I think it may be worthwhile for me to explain the problem I'm trying to solve, as even if the MAC_IGNORE_LIST worked it would only be a partial solution.

The MAC addresses I tried to exclude are the MAC addresses of two WiFi extenders. WiFi extenders have the unfortunate habit of spoofing the MAC address of all devices behind them to be the same as the MAC address of the extender itself. There is no way to disable that behavior. Apparently, the behavior is there so it looks like there are fewer devices connected to routers which limit the number of connected devices.

Anyway, this extender behavior results in pialert seeing multiple IP addresses with the same MAC address. This is dumb, of course, since MAC addresses should be unique. pialert gets (reasonably) confused and thinks that for a given MAC address the IP has changed and reports on that.

Since this isn't really pialert's problem, I'm not sure if anything can be done. Perhaps an option to poll certain IP addresses for up/down without reference to the MAC address? Would that make any sense? If the MAC_IGNORE_LIST option worked, I could at least disable all the alerts (even though that would eliminate the capability to see if the extender or any devices behind it were up/down).

---

In an unrelated issue, pialert is giving me frequent "down" notifications for a couple of my devices which are not in fact down. Perhaps pialert is just not waiting long enough for a response from those devices? Is this at all configurable?

[leiweibau]

I have to ask a dumb question:
Did you remove the leading "#" before MAC_IGNORE_LIST? The difference in the status box is then as follows:

MAC_IGNORE_LIST = OFF

MAC_IGNORE_LIST = ON (with example)

MAC addresses on this list are removed from all scans and subsequently also marked as "offline".

Did you enable this option on the affected devices?

[hspindel]

Not a dumb question. :-) The first time I configured it, I forgot to remove the hash mark. Here is my current MAC ignore section from the conf file copied verbatim:

MAC_IGNORE_LIST = ['94:a6:7e:23:45:66', '84:1b:5e:28:7b:6b']
SCAN_SUBNETS = '--localnet'

Do I have the syntax wrong? I tried to follow the default pialert.conf file in this regard.

Yes, Alert All Events is active for all devices.

Thank you.

[leiweibau]

For me the syntax looks correct. You can see if the list is recognized and processed in the scan log.

Maybe in your case it is better to disable this option for the devices in question.

Here is some background information.
"Alert All Event"
Here, as the name suggests, every change is reported (IP change, Down, Up). Nevertheless, the online/offline detection is still available. You will just not be informed anymore.

Option MAC_IGNORE_LIST
This function, which actually works in my environment, is used to exclude a device completely from Pi.Alert. If it is already in the database, it will be marked as "Offline". If it does not exist in the database yet, then it will not appear even if it is online. This feature was added because of a strange behavior of Pi-hole, which sometimes reports hosts that used to exist, but no longer do.

Even though it is interesting why the MAC_IGNORE_LIST option doesn't seem to work for you, I would recommend you to disable the notification for the devices in question, because it is simply the more practical thing to do.

[leiweibau]

I found the bug that affected the ignore list function in arp-scan.
With the next update package the error will be fixed.

[hspindel]

Hey, that's cool you found a bug with the MAC ignore. I was going to report that my logs do show two addresses ignored. I am switching notifications as you suggested.

Did you have any thoughts on the problem I posted earlier about duplicate MAC addresses for devices behind WiFi extenders?

One other question: I have one device for which I get a lot of "down" notifications. I can turn them off, but I am curious where to look for why I"m getting the notifications. It's a Cisco router which is always on.

[leiweibau]

Did you have any thoughts on the problem I posted earlier about duplicate MAC addresses for devices behind WiFi extenders?

No. As you have already noted, there is little you can do with Pi.Alert.

One other question: I have one device for which I get a lot of "down" notifications. I can turn them off, but I am curious where to look for why I"m getting the notifications. It's a Cisco router which is always on.

If the router does not always respond to the ARP requests in a timely manner, I would also recommend that you disable the notifications all together. Alternatively, if the router has a web interface, you can check the functionality of the router via the web service monitoring. Enter the URL of the router web interface and set the appropriate notification.

[hspindel]

Thank you for all of the excellent support.

[leiweibau]

Please. You are welcome.