Pi alert show a device with a lot of mac address

VThang commented 1 year ago

Describe the issue After some issue with network of Docker host machine. Pi alert show a device with a lot of mac address and no way to delete.

Paste last few lines from pialert.log


[2023-03-24 15:10:21] Notifications: 0
[2023-03-24 15:10:21] Last action: network_scan
[2023-03-24 15:10:21] Process: Wait
     [API] Updating files in /front/api
[2023-03-24 15:10:26] Process: Start
[2023-03-24 15:10:26] Process: Wait
     [API] Updating files in /front/api
     [API] Updating files in /front/api
     [API] Updating files in /front/api
     [API] Updating files in /front/api
     [API] Updating files in /front/api
     [API] Updating files in /front/api

Paste your pialert.conf (remove personal info)


#-----------------AUTOGENERATED FILE-----------------#
#                                                    #
#         Generated:  2023-03-23_10-12-02            #
#                                                    #
#   Config file for the LAN intruder detection app:  #
#      https://github.com/jokob-sk/Pi.Alert          #
#                                                    #
#-----------------AUTOGENERATED FILE-----------------#

# General
#---------------------------
ENABLE_ARPSCAN=True
SCAN_SUBNETS=['192.168.1.0/24 --interface=ens18','192.168.0.0/24 --interface=ens18']
LOG_LEVEL='verbose'
TIMEZONE='xxxxx'
PIALERT_WEB_PROTECTION=False
PIALERT_WEB_PASSWORD='xxxxx'
INCLUDED_SECTIONS=['internet','new_devices','down_devices','events']
SCAN_CYCLE_MINUTES=5
DAYS_TO_KEEP_EVENTS=90
REPORT_DASHBOARD_URL='http://pi.alert/'
DIG_GET_IP_ARG='-4 myip.opendns.com @resolver1.opendns.com'
UI_LANG='English'

# Email
#---------------------------
REPORT_MAIL=False
SMTP_SERVER='smtp.gmail.com'
SMTP_PORT=587
REPORT_TO='user@gmail.com'
REPORT_FROM='Pi.Alert <user@gmail.com>'
SMTP_SKIP_LOGIN=False
SMTP_USER='user@gmail.com'
SMTP_PASS='password'
SMTP_SKIP_TLS=False
SMTP_FORCE_SSL=False

# Webhooks
#---------------------------
REPORT_WEBHOOK=False
WEBHOOK_URL='http://n8n.local:5555/webhook-test/aaaaaaaa-aaaa-aaaa-aaaaa-aaaaaaaaaaaa'
WEBHOOK_PAYLOAD='json'
WEBHOOK_REQUEST_METHOD='GET'

# Apprise
#---------------------------
REPORT_APPRISE=False
APPRISE_HOST='http://localhost:8000/notify'
APPRISE_URL='mailto://smtp-relay.sendinblue.com:587?from=user@gmail.com&name=apprise&user=user@gmail.com&pass=password&to=user@gmail.com'
APPRISE_PAYLOAD='html'

# NTFY
#---------------------------
REPORT_NTFY=False
NTFY_HOST='https://ntfy.sh'
NTFY_TOPIC='replace_my_secure_topicname_91h889f28'
NTFY_USER='user'
NTFY_PASSWORD='passw0rd'

# PUSHSAFER
#---------------------------
REPORT_PUSHSAFER=False
PUSHSAFER_TOKEN='ApiKey'

# MQTT
#---------------------------
REPORT_MQTT=False
MQTT_BROKER='192.168.1.2'
MQTT_PORT=1883
MQTT_USER='mqtt'
MQTT_PASSWORD='passw0rd'
MQTT_QOS=0
MQTT_DELAY_SEC=2

# DynDNS
#---------------------------
DDNS_ACTIVE=False
DDNS_DOMAIN='your_domain.freeddns.org'
DDNS_USER='dynu_user'
DDNS_PASSWORD='A0000000B0000000C0000000D0000000'
DDNS_UPDATE_URL='https://api.dynu.com/nic/update?'

# PiHole
#---------------------------
PIHOLE_ACTIVE=False
DHCP_ACTIVE=False

# Pholus
#---------------------------
PHOLUS_ACTIVE=True
PHOLUS_TIMEOUT=120
PHOLUS_FORCE=False
PHOLUS_RUN='schedule'
PHOLUS_RUN_TIMEOUT=600
PHOLUS_RUN_SCHD='0 4 * * *'
PHOLUS_DAYS_DATA=7

# Nmap
#---------------------------
NMAP_ACTIVE=True
NMAP_TIMEOUT=150
NMAP_RUN='none'
NMAP_RUN_SCHD='0 2 * * *'
NMAP_ARGS='-p -10000'

# API
#---------------------------
API_CUSTOM_SQL='SELECT * FROM Devices WHERE dev_PresentLastScan = 0'

# WEBMON
#---------------------------
WEBMON_RUN='disabled'
WEBMON_CMD='python3 /home/pi/pialert/front/plugins/website_monitor/script.py urls={urls}'
WEBMON_RUN_SCHD='0 2 * * *'
WEBMON_API_SQL='SELECT * FROM plugin_website_monitor'
WEBMON_RUN_TIMEOUT=5
WEBMON_WATCH=['Watched_Value1']
WEBMON_REPORT_ON=['new','watched-changed']
WEBMON_urls_to_check=['https://google.com','https://duck.com']
WEBMON_SQL_internet_ip='SELECT dev_LastIP FROM Devices WHERE dev_MAC = {s-quote}Internet{s-quote}'

# NMAPSRV
#---------------------------
NMAPSRV_RUN='disabled'
NMAPSRV_CMD='SELECT  dv.dev_Name as Object_PrimaryID, cast({s-quote}http://{s-quote} || dv.dev_LastIP as VARCHAR(100)) || {s-quote}:{s-quote} || cast( SUBSTR(ns.Port ,0, INSTR(ns.Port , {s-quote}/{s-quote})) as VARCHAR(100)) as Object_SecondaryID,  datetime() as DateTime,  ns.Service as Watched_Value1,        ns.State as Watched_Value2,        {s-quote}null{s-quote} as Watched_Value3,        {s-quote}null{s-quote} as Watched_Value4,        ns.Extra as Extra, dv.dev_MAC as ForeignKey        FROM (SELECT * FROM Nmap_Scan) ns LEFT JOIN (SELECT dev_Name, dev_MAC, dev_LastIP FROM Devices) dv   ON ns.MAC = dv.dev_MAC'
NMAPSRV_RUN_SCHD='0 2 * * *'
NMAPSRV_WATCH=['Watched_Value1']
NMAPSRV_REPORT_ON=['new','watched-changed']

#-------------------IMPORTANT INFO-------------------#
#   This file is ingested by a python script, so if  #
#        modified it needs to use python syntax      #
#-------------------IMPORTANT INFO-------------------#

Paste your docker-compose.yml and .env (remove personal info)

docker-compose.yml


version: "3.9"

networks:
  default:
    driver: bridge
  traefik-proxy:
    name: traefik-proxy
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.100.0/24

services:
  pialert:
    container_name: pialert
    image: "jokobsk/pi.alert:latest"
    restart: unless-stopped
    network_mode: "host"
    # networks:
    #   - host
    #   - traefik-proxy
    security_opt:
      - no-new-privileges:true
    volumes:
      - /home/vthang/docker/pialert/config:/home/pi/pialert/config
      - /home/vthang/docker/pialert/data/:/home/pi/pialert/db/
      # (optional) useful for debugging if you have issues setting up the container
      - /home/vthang/docker/pialert/log:/home/pi/pialert/front/log
     environment:
      - TZ=${TZ}      
    #   - HOST_USER_ID=${HOST_USER_ID}
    #   - HOST_USER_GID=${HOST_USER_GID}
    #   - PORT=${PORT}
    ports:
      - "20211:20211"

.env


#GLOBAL PATH VARIABLES

# APP_DATA_LOCATION=/path/to/docker_appdata
# APP_CONFIG_LOCATION=/path/to/docker_config
# LOGS_LOCATION=/path/to/docker_logs

#ENVIRONMENT VARIABLES

TZ=Asia/Ho_Chi_Minh
# HOST_USER_ID=1000
# HOST_USER_GID=1000
# PORT=20211

#DEVELOPMENT VARIABLES

# DEV_LOCATION=/path/to/local/source/code

Screenshots If applicable, add screenshots to help explain your problem.

jokob-sk commented 1 year ago

Hi @VThang ,

Thanks for the effort you put into describing your issue!

What I think is happening:

arp-scan is returning a response not expected by the app and thus it is parsing it incorrectly

What I think is the cause:

I've never tested setting up PiAlert through a proxy(?) such as traefik, so that might cause the issue.

To help debug the issue I'd suggest the following:

Try running arp-scan in the container directly and post the redacted result here. Probably these 2 commands (as you have 2 subnets) are:
- sudo arp-scan --ignoredups --retry=6 192.168.1.0/24 --interface=ens18
- sudo arp-scan --ignoredups --retry=6 192.168.0.0/24 --interface=ens18
Try removing the traefik configuration from the container if possible (workaround, not fixing the issue)
If you are using PiHole try disabling arp-scan (set ENABLE_ARPSCAN to False) and use PiHole as the discovery method for your devices by following the settings description/documentation on setting up PiHole. (workaround, not fixing the issue)

Not sure if you are using vlans, but if yes, please read this as well.

Hope this helps.

Thanks, j

EDIT: After submitting I've noticed you've disabled traefik, can you still try to remove any unnecessary config values from the docker-compose file? Also, does the container have access to the internet?

VThang commented 1 year ago

Thank you for help.

EDIT: After submitting I've noticed you've disabled traefik, can you still try to remove any unnecessary config values from the docker-compose file? Also, does the container have access to the internet?

First time I'm trying to setup Pi-Alert, I'm using the same template of my docker and add it to Traefik reverse proxy, then add Traefik proxy label. Then i realize it not a good idea because Pi-Alert can't watch the normal network but docker network. I disable everything Traefik related to Pi-Alert, wipe all config, db, log and change to network_mode: host and expose port 20211, then use Traefik loadBalancer to http://ip:20211. So i think traefik didnt do anything with Pi-Alert. And because Pi-Alert use host network so it have internet.

arp-scan --ignoredups --retry=6 192.168.1.0/24 --interface=ens18

arp-scan --ignoredups --retry=6 192.168.0.0/24 --interface=ens18 Something wrong about my config or my firewall so Pi-Alert only see Proxmox host (everything is in proxmox), maybe my firewall or something because Pi Alert can ping anything in subnet 192.168.0.0/24 but cant scan. But i will trying fix it another time.

Try removing the traefik configuration from the container if possible (workaround, not fixing the issue)

Done

If you are using PiHole try disabling arp-scan (set ENABLE_ARPSCAN to False) and use PiHole as the discovery method for your devices by following the settings description/documentation on setting up PiHole. (workaround, not fixing the issue)

I have 2 pihole but they not in this docker machine so i can't map the pihole-FTL.db for Pi-Alert.

Not sure if you are using vlans

I'm not using VLAN

What I think is happening: arp-scan is returning a response not expected by the app and thus it is parsing it incorrectly

I think so too. When i'm trying to fix Pi-Alert cant scan subnet 192.168.0.0/24 with routing table on firewall and Debian host. Some think went wrong, and Debian host trying to get ipv6 (I disable ipv6 in my network) -> Debian host lost all connection, including my ssh session -> access Debian console, disable ipv6 -> network is fixed but the issue appear in Pi-Alert.

jokob-sk commented 1 year ago

Thanks for the update!

I want to double-check:

1) is your issue resolved now or are you still experiencing issues after the re-deployment of the container?

If you are still facing issues, let's try to debug it further:

Can you paste your current compose file if you've changed it between your first post and now?
Can you try to disable NMAP and PHOLUS? (NMAP_ACTIVE=False and PHOLUS_ACTIVE=False)?
Can you set LOG_LEVEL='debug' to check if something weird doesn't show up in the logs?
Can you try to execute this command dig +short -x 192.168.1.50 (use a real device IP on your network) in your container?
Do you have any DNS blocklist setup on your network? Try disabling it for testing purposes.
Could you please let me know what are the titles/headers of these 2 columns?

Thanks in advance! j

VThang commented 1 year ago

I think i found something interesting in log

pialert_nmap.log

...

Starting Nmap 7.80 ( https://nmap.org ) at 2023-03-23 09:27 GMT
Failed to resolve "RTNETLINK answers: Network is unreachable".
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.04 seconds

Starting Nmap 7.80 ( https://nmap.org ) at 2023-03-23 11:59 GMT
Failed to resolve "RTNETLINK answers: Network is unreachable".
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.04 seconds

...

pialert.log

...
[2023-03-23 09:27:25] Scan: Nmap for max 150s (2.5min) per device
        Estimated max delay: 150s (2.5min)
[2023-03-23 09:27:25] Scan: Nmap SUCCESS for RTNETLINK answers: Network is unreachable (1/1)
[2023-03-23 09:27:25] Scan: Ports found by NMAP: 0
  Check if something to report
    Couldn't check for new release.
     [API] Updating files in /front/api
    Changes detected, sending reports
      Skip email
      Skip Apprise
      Skip webhook
      Skip NTFY
      Skip PUSHSAFER
      Skip MQTT
[2023-03-23 09:27:25] Notifications: 0
[2023-03-23 09:27:25] Last action: network_scan
[2023-03-23 09:27:25] Process: Wait
     [API] Updating files in /front/api

...
[2023-03-23 11:59:22] Scan: Nmap for max 150s (2.5min) per device
        Estimated max delay: 150s (2.5min)
[2023-03-23 11:59:22] Scan: Nmap SUCCESS for RTNETLINK answers: Network is unreachable (1/1)
[2023-03-23 11:59:22] Scan: Ports found by NMAP: 0
  Check if something to report
    Couldn't check for new release.
     [API] Updating files in /front/api
    Changes detected, sending reports
      Skip email
      Skip Apprise
      Skip webhook
      Skip NTFY
      Skip PUSHSAFER
      Skip MQTT
[2023-03-23 11:59:22] Notifications: 0
[2023-03-23 11:59:22] Last action: network_scan
[2023-03-23 11:59:22] Process: Wait
     [API] Updating files in /front/api
...

Maybe NMAP scan Failed to resolve "RTNETLINK answers: Network is unreachable"., but somehow Pi-Alert still accept that answer as success Scan: Nmap SUCCESS for RTNETLINK answers: Network is unreachable (1/1) and write that answer to database (below is full screenshot where RTNETLINK error have Row ID, i presume Row ID is database row ID). If that so then only way to fix this issue is delete the row on database?

jokob-sk commented 1 year ago

Thanks for that,

Can you try to execute these two commands in the container?

ip -o route get 1 | sed 's/^.*src \\([^ ]*\\).*$/\\1/;q'

/sbin/ifconfig `ip -o route get 1 | sed 's/^.*dev \\([^ ]*\\).*$/\\1/;q'` | grep ether | awk '{print $2}'

jokob-sk commented 1 year ago

i presume Row ID is database row ID). If that so then only way to fix this issue is delete the row on database?

I think it's easier to redeploy the container with an empty DB to make sure nothing else is corrupted

VThang commented 1 year ago

ip -o route get 1 | sed 's/^.*src \$[^ ]*\$.*$/\\1/;q'

1.0.0.0 via 192.168.1.1 dev ens18 src 192.168.1.60 uid 0 \ cache

/sbin/ifconfig `ip -o route get 1 | sed 's/^.*dev \$[^ ]*\$.*$/\\1/;q'` | grep ether | awk '{print $2}'

06:07:48:5e:03:e1

I think it's easier to redeploy the container with an empty DB to make sure nothing else is corrupted

Ok. I will do that when i have time. Thank you for your support.

jokob-sk commented 1 year ago

Thanks for the update -> closing for now

roger- commented 1 year ago

FYI I'm using 23.6.16 and still experiencing this issue.

jokob-sk commented 1 year ago

@roger- Thanks for the info!

I've implemented some safeguards for this that I hope will prevent this from happening - it's possible that the entries in your DB were stored before those safeguards were in place.

Can you report back if that happens again after you fixed your DB?

MartinKuhl commented 1 year ago

I have the same issue, after a power outage I have these kind of undeleteable entries in my device overview. Is there a way to directly delete them with in the db?

jokob-sk commented 1 year ago

Hey @MartinKuhl ,

Try this workaround:

https://github.com/jokob-sk/Pi.Alert/issues/228#issuecomment-1546803064

Can you post the values that were incorrectly inserted? I'll try to fix the insert statement if I know what to look for.

Thanks! j

MartinKuhl commented 1 year ago

In the CSV file the wrong entries are easy to identify. The is simply RTNETLINK answers: Network is unreachable and than a linebreak followed by several MAC addresses.

jokob-sk commented 1 year ago

Humm, thanks, I thought I fixed this already by implementing a Mac check - will have to reopen 😓

https://github.com/jokob-sk/Pi.Alert/commit/298b5ac03e998282bad180278638076adde98d36

jokob-sk commented 1 year ago

I hope the fix is in the release > Closing for now, will reopen if needed

roger- commented 1 year ago

Thanks! Does this fix existing bad entries or do those need to be manually removed?

Just updated and I still see some corrupt entries from before.

jokob-sk commented 1 year ago

Hey, this will not fix existing entries. You need to clean up the DB as per https://github.com/jokob-sk/Pi.Alert/issues/228#issuecomment-1546803064

jokob-sk / NetAlertX

Pi alert show a device with a lot of mac address #202

What I think is happening:

What I think is the cause: