Excessive "IP Changed" Events on Dual-Stack (IPv4/IPv6) Devices?

[lennelei]

Hi there,

I recently deployed NetAlertX using Docker and I'm experiencing an issue that generates a massive amount of "IP Changed" events, essentially flooding the logs.

This occurs with every device on my network that is configured with both IPv4 and IPv6 addresses. It seems that during each scan cycle, NetAlertX detects the device on its primary IPv4, and then detects the same device on its multiple IPv6 addresses (Global and Link-Local), interpreting the subsequent IPv6 detections as an "IP changes".

Exemple: for a single device, the logs show multiple IP changes during every scan:

27/10/2025 13:16:09 | IP Changed | fe80::*:721f | Previous IP: 192.168.0.199 27/10/2025 13:16:09 | IP Changed | 2a01:*:721f | Previous IP: 192.168.0.199 27/10/2025 13:11:02 | IP Changed | fe80::*:721f | Previous IP: 192.168.0.199 27/10/2025 13:11:02 | IP Changed | 2a01:*:721f | Previous IP: 192.168.0.199 27/10/2025 13:05:56 | IP Changed | fe80::*:721f | Previous IP: 192.168.0.199 27/10/2025 13:05:56 | IP Changed | 2a01:*:721f | Previous IP: 192.168.0.199 27/10/2025 13:00:42 | IP Changed | fe80::*:721f | Previous IP: 192.168.0.199 27/10/2025 13:00:42 | IP Changed | 2a01:*:721f | Previous IP: 192.168.0.199 27/10/2025 12:55:29 | IP Changed | fe80::*:721f | Previous IP: 192.168.0.199

Is there a recommended way to handle this scenario within NetAlertX to prevent this excessive logging?

I've checked the configuration documentation but haven't found a clear solution for filtering these events or adjusting the IP change detection logic in a dual-stack environment.

Any guidance would be greatly appreciated. Thank you!

[jokob-sk]

Hi @lennelei ,

Maybe it's possible to filter out notifications based on a wildcard. Have a look at the NTFPRCS_event_condition setting.

However, I'd like to handle this natively in future. Do you think would an additional IPv6 field that would be checked and available on every device solve this? And only an IP changed event triggered if there is a mismatch in both?

[lennelei]

I'll have a look at the NTFPRCS_event_condition setting. Thank you!

However, while filtering is a possible workaround, relying on this doesn't seem a viable solution essentially because it only hides the issue from the user, while the core problem of excessive data logging persists (storage, processing overhead).

I believe your proposal to handle this natively is the way to go.

The idea of having an additional IPv6 field (or fields) that gets checked is a great starting point. To make it robust for future environments, it might be necessary to consider that a single device can have multiple concurrent addresses on a single interface:

• IPv6: At least one Link-Local (fe80::) and potentially multiple Global Unicast Addresses.
• IPv4: While less common, devices can also have multiple IPv4 addresses (primary, secondary, virtual, etc.).

A true solution would likely need an improved logic that identifies a device based on its MAC address (which should be unique and stable) and then treats the associated set of detected IPs (IPv4 and all IPv6) as belonging to that single known device. An "IP Changed" event would only be triggered if this entire set of addresses changes significantly, or if the primary tracking IP is lost.

Given most existing LANs still rely heavily on IPv4, prioritizing the IPv4 address as the primary tracker for a given device might be the quickest and most efficient way to reduce false positives in the short term.

The refined logic could be:

1. Identify the Device: The device is fundamentally tracked by its MAC address (which is usually stable).
2. Determine Primary IP: When NetAlertX detects multiple IPs for a single MAC:
   • If an IPv4 address is found, use it as the Primary Tracking IP.
   • If only IPv6 addresses are found, use the Global Unicast Address (2xxx:) as the primary (or the lowest one alphabetically/numerically).
3. Logging Logic: Only trigger an "IP Changed" event if the Primary Tracking IP changes.

This simple prioritization would immediately stop the excessive logging caused by the multiple IPv6 addresses being detected after the stable IPv4 address.

Thank you for considering this!

[jokob-sk]

Thanks for the detailed response. I don't use ipv6 so there is a bit of understanding missing on my end, so if I miss anything, please fill in the gaps.

To clarify a few things - the devices are detected and identified by MAC address, the IP changed notification is just that, an IP change notification.

Currently, one of the core design principles of the app is to keep all device data in one table (reason: simple backup, export, sync of core data, with lots of underlying dependencies), so implementing unlimited additional IPs is tricky.

Other things we could do:

• have a new category ip_changes available in the global setting NTFPRCS_INCLUDED_SECTIONS
• have a checkbox "Report IP Changes" on a device

As a middle ground have a set of fields for IP addresses on a device e.g. :

• Last ipv4
• Previous ipv4
• Last ipv6
• Previous ipv6

On the device itself. Change the logic to check both Last ipv4 and Last ipv6 and only fire an IP Changed notification if the detected IP is missing in both primary (Last prefixed ) fields.

[lennelei]

I'm not very familiar with IPv6 either, however, I can see in my NetAlertX installation that a lot of devices with dual stack have 2 IPv6 adresses along with one IPv4 address.

Your suggestion for checking both Last ipv4 and Last ipv6 as a middle ground is definitely the best way forward, respecting the single-table design.

However, to truly eliminate the noise caused by stable concurrent addresses (especially when having both IPv4 and IPv6), an even simpler solution might be a single Primary Tracking IP approach.

1. New Field: Add a single field: Primary_Tracking_IP.
   • (A Last_Tracking_IP field might be needed for your internal change logic).
2. Initial Fill Logic (Prioritization): This field is auto-populated upon detection using a clear hierarchy:
   • Priority 1: IPv4. Any detected IPv4 address (lowest IP or IP on a main network defined in the settings).
   • Priority 2: Stable IPv6 ULA (lowest Unique Local Address, fcxx::/fdxx::).
   • Priority 3: IPv6 GUA (lowest Global Unicast Address, 2xxx::/3xxx::).
   • Note: The Link-Local address (fe80::) should not be considered as Primary Tracking IP.
3. User Control: Allow the user to manually edit the Primary_Tracking_IP field for each device, locking the tracking onto a specific, known stable address.
4. Logging Condition: The IP Changed notification should only fire if the currently detected Primary Tracking IP differs from the stored/last value.

To keep the single table simple, an addition field, like Other_IPs (e.g., in JSON format), could log the list of other concurrent addresses (including the fe80::) for informational/troubleshooting purposes.

Good luck :)

[jokob-sk]

Thanks for the suggestions.

I'm trying to avoid complex data structures like JSON is the data is supposed to be checked in SQL conditions.

How would you handle the scenario where the IP changes - which field would be updated? Let's say the following events occur:

First detected: 74:ac:74:ac:74:ac | 192.168.1.15 -> devMAC: 74:ac:74:ac:74:ac devLastIP: 192.168.1.15
Later scan 1: 74:ac:74:ac:74:ac | 192.168.1.15 -> devMAC: 74:ac:74:ac:74:ac devLastIP: 192.168.1.15
Later scan 2: 74:ac:74:ac:74:ac | 192.168.1.16 -> devMAC: 74:ac:74:ac:74:ac devLastIP: 192.168.1.16 or 192.168.1.15 (?)
Later scan 3: 74:ac:74:ac:74:ac | 192.168.1.18 -> devMAC: 74:ac:74:ac:74:ac devLastIP: 192.168.1.16 or 192.168.1.15 or 192.168.1.18 (?)
Later scan 4: 74:ac:74:ac:74:ac | fcxx:: -> devMAC: 74:ac:74:ac:74:ac devLastIP: 192.168.1.16 or 192.168.1.15 or 192.168.1.18 or fcxx:: (?)

How would the fields you propose look like at each step?

Why is the primary IP important - some scanners, such as the ICMP scanner, use the IP for their scans.

[lennelei]

Two information are missing for me to understand the whole process and to answer your question:

1. how last IP field is used
2. more important: how all the IPs and changes are detected

If I use two scenarios from real examples in my own installation:

1. common case: a device simply has multiple IPv4/IPv6 adresses (1 IPv4 and 3 IPv6 in the example below)
   I have 3 rows for each scan (first column is added by me) - the timestamp on each event is the same:

Scan	Time	Event	IP	Message
3	06/11/2025 11:21:08	IP Changed	fe80:...:c682	Previous IP: 192.168.0.100
3	06/11/2025 11:21:08	IP Changed	2a01:...:3dbf	Previous IP: 192.168.0.100
3	06/11/2025 11:21:08	IP Changed	2a01:...:c682	Previous IP: 192.168.0.100
2	06/11/2025 11:15:58	IP Changed	fe80:...:c682	Previous IP: 192.168.0.100
2	06/11/2025 11:15:58	IP Changed	2a01:...:3dbf	Previous IP: 192.168.0.100
2	06/11/2025 11:15:58	IP Changed	2a01:...:c682	Previous IP: 192.168.0.100
1	06/11/2025 11:10:50	IP Changed	fe80:...:c682	Previous IP: 192.168.0.100
1	06/11/2025 11:10:50	IP Changed	2a01:...:3dbf	Previous IP: 192.168.0.100
1	06/11/2025 11:10:50	IP Changed	2a01:...:c682	Previous IP: 192.168.0.100

This is where I don't understang the logic: to have a Previous IP 192.168.0.100, there should be an IP Changed to that value?
I would expect an "IP Changed" event from IPv4 to IPv6 such as:

Scan	Time	Event	IP	Message
2	06/11/2025 11:15:58	IP Changed	192.168.0.100	Previous IP: 2a01:...:c682

2. another scenario: a device loses it's IPv4
   Here, for an unkonw reason, my device stopped answering the the IPv4 and I could see that in the NetAlertX logs:

Scan	Time	Event	IP	Message
5	26/10/2025 00:46:16	IP Changed	2a01:...:721f	Previous IP: fe80:...:721f
4	26/10/2025 00:41:09	IP Changed	2a01:...:721f	Previous IP: fe80:...:721f
3	26/10/2025 00:35:59	IP Changed	2a01:...:721f	Previous IP: fe80:...:721f
2	26/10/2025 00:30:50	IP Changed	fe80:...:721f	Previous IP: 192.168.0.54
2	26/10/2025 00:30:50	IP Changed	2a01:...:721f	Previous IP: 192.168.0.54
1	26/10/2025 00:25:38	IP Changed	fe80:...:721f	Previous IP: 192.168.0.54
1	26/10/2025 00:25:38	IP Changed	2a01:...:721f	Previous IP: 192.168.0.54

That would be something like this (depending on your usage of the Last field):

First detected: 74:ac:74:ac:74:ac | 192.168.0.100 and 2a01:...:c682 and 2a01:...:3dbf and fe80:...:c682 -> devMAC: 74:ac:74:ac:74:ac devLastIP: 192.168.0.100 devPrimaryIP: 192.168.0.100 devOtherIPs: 2a01:...:c682 / 2a01:...:3dbf / fe80:...:c682
Later scan 1: 74:ac:74:ac:74:ac | same -> no change
Later scan 2: 74:ac:74:ac:74:ac | 192.168.0.100 and whatever others IPv6 -> no change on devLastIP and devPrimaryIP but devOtherIPs: whatever
Later scan 3: 74:ac:74:ac:74:ac | 192.168.0.102 and whatever others IPv6 -> devLastIP: 192.168.1.102 ? devPrimaryIP: 192.168.0.102 devOtherIPs: whatever + "IP Changed" event
Later scan 4: 74:ac:74:ac:74:ac | 2a01:...:c682 and whatever others IPv6 -> devLastIP: 2a01:...:c682 ? devPrimaryIP: 2a01:...:c682 devOtherIPs: whatever + "IP Changed" event (lost of IPv4)
Later scan 5: 74:ac:74:ac:74:ac | 192.168.0.100 and whatever others IPv6 -> devLastIP: 192.168.1.100 ? devPrimaryIP: 192.168.0.100 devOtherIPs: whatever + "IP Changed" event (IPv4 is back)

[jokob-sk]

DevLastIP is used as only comparison data point between the previous and currently detected IP. If the ip changes it is overwritten. The changes are determined pretty basically. Is DevLastIP different from the last detected IP? Yes - > Ip Changed notification is fired and DevLastIP is replaced with the new value.

In your example you are using devOtherIPs which I know ant to avoid.

I'll have a closer look at your example tomorrow, but as mentioned, I want to avoid storing complex data types in one field as DB level operations would be problematic.

Sorry for a messy message, just typing on my phone before bed.

[jokob-sk]

Ideally if possible, I'd like to see my above example with the state of your proposed fields after each scan so that I can understand the logic you are proposing - without the need to store all previous IPs.

[lennelei]

Thank you again for your patience.

I mistakenly assumed the multiple IP reports within the same minute came from a single, unified scan.
I now understand that the events are likely triggered by independent plugins (e.g., ARPSCAN and FREEBOX).

1. Plugin A (e.g., ARPSCAN): Scans the network and maps MAC X with IPv4 address.
2. Plugin B (e.g., FREEBOX): Detects the same MAC X, but finds IPv6 addresses (fe80:: and 2a01::) alongside the IPv4.
3. The FREEBOX plugin reports these IPv6 addresses, causing the core logic to overwrite the stored IP:
   • 192.168.0.x is replaced by fe80:: $\rightarrow$ Logs 'IP Changed'.
   • fe80:: is replaced by 2a01:: $\rightarrow$ Logs 'IP Changed'.

I now understand why detecting IP changes is tricky because the plugins may not be aware of what the others have reported.

I still don't fully understand everything (for example, why there's no 'IP Changed' to the IPv4), but I now see why my initial ideas didn't work.

I'll take a deeper look into the plugin logic to see if I can come up with another approach.

On my setup, disabling the FREEBOX plugin stops the flooding of events, though I'm not sure yet what information might be lost as a result.

Another possible simple solution could be to prioritize one scanner (e.g. ARPSCAN over FREEBOX) for the 'IP Changed' event?

[jokob-sk]

now understand why detecting IP changes is tricky because the plugins may not be aware of what the others have reported.

To give you a high-level idea:

1. Every plugin runs in a pre-defined schedule - the best practice is to have the schedules aligned.
2. since teh schedules are aligned all plugins plugins run during the same execution loop
3. all plugins in the same execution loop collect available data into the CurrentScan table
4. at the end of the loop the CurrentScan table is evaluated and new devices, changes, etc. are determined

So yes, plugins work independently, but at teh end of the scan all data is available in the CurrentScan table. BTW you can see the state of teh CurrentScan table during a run by enabling LOG_LEVEL=trace and searching the logs for ================ CurrentScan table content ================ which then follows with a printout of the whole table.

You can see the logic here: https://github.com/jokob-sk/NetAlertX/blob/71e0d13befcb3edba6aa2336d77f78a10f7bc229/server/scan/device_handling.py#L56

Also maybe I'm too restrictive (unnecessarily restrictive?) with the complex data types in teh Devices table, but so far this has proven as a good choice when implementing other functionality.

Another possible simple solution could be to prioritize one scanner (e.g. ARPSCAN over FREEBOX) for the 'IP Changed' event?

Plugin priorities are specified in the plugin config, and the FREEBOX plugin has a higher priority because it's data is more reliable and detailed than a simple ARPSCAN. E.g. you can see it here: https://github.com/jokob-sk/NetAlertX/blob/71e0d13befcb3edba6aa2336d77f78a10f7bc229/front/plugins/freebox/config.json#L5

Happy to rethink anything mentioned above if it is valuable to others, just sharing additional context. I still think adding at least one more additional IP tracking field will give us more data and flexibility to play with, I just need to understand the behavior and covered use cases in advance.

EDIT - you can check teh docs for even more context: https://jokob-sk.github.io/NetAlertX/PLUGINS_DEV_CONFIG/

Looking forward to your thoughts

[jokob-sk]

Hi @lennelei - did you give this further thought? Would love to hear if you have thought of something on how I can improve the reporting on IP addresses.

[eddieathens]

Hello- I'm not the OP, but recently ran into the same issue while doing a demo of NetAlertX.

Because only a single IP address is saved per MAC address the system not really usable in a dual ip4/ipv6 stack environment. This is unfortunate because for ipv4 the project is very useful.

In order to handle ip6 addresses it helps to understand some basics. In really basic usage ignoring many edge cases, each interface will probably have one ip4 address as well as at least one but up to 3 (or more) ipv6 addresses.

The ipv6 addresses consist of:

1. link local address used for local network communication. Each interface with ipv6 enabled will have one.
2. stable address, used for internetworks. Usually SLAAC or DHCPv6 assigned and stable for the configured life of the interface.
3. temporary address, also for internetworks but limited in lifetime to about 2 days for security use.

So basically a device may have 1, two or three ipv6 addresses on an interface, one of which may change every day or two.

In my opinion in order for NetAlertX to be usable in dual stack environments it needs to at a minimum track the link local address for the interface. These could be filtered from other addresses by the ipv6 address range assigned for them (fe80::/10).

The stable and temporary addresses are nice to have, but you would need to find a way to deal with the churn of temporary entries.

This is a very basic simplified overview but I hope it is useful. NetAlertx seems very useful for ipv4 environments and it would be great to see that extended to dual stack.

[jokob-sk]

Hi @eddieathens , sorry I missed this message - would you be able to provide a detailed data flow / state example with additional fields? Similar to #1273 (comment)

I'm playing with the idea to add 1-2 new fields to improve IP change detection but since I don't have an environment to test this on I'd need more context on how the best to handle this.

I'm thinking these fields:

Current field:

devLastIP

NEW:

devPreviousIPv4
devPreviousIPv6

On each scan the devLastIP contains the latest reported IP, and if it changes, the old value gets stored in devPreviousIPv4 or devPreviousIPv6. I would add a global setting NON_STRICT_CHANGE and if enabled, devLastIP, devPreviousIPv4 and devPreviousIPv6 would be compared and an "IP Changed" event would only be logged if the newly detected IP differs from all 3.

Let me know your thoughts.

[ozdeadmeat]

Was there a resolution to this, my system notifications are filling with IP Changes, 4 every 5 minutes. Is there either a way to turn off that notification or resolve it to stop it from happening?

[eddieathens]

Was there a resolution to this, my system notifications are filling with IP Changes, 4 every 5 minutes. Is there either a way to turn off that notification or resolve it to stop it from happening?

Disabling alerts quiets the noise, but still leaves the issue of the IP Address changing from IPv4 to IPv6 and back again. I decided to turn off all plugins (IP Neigh in my case) that pick up IPv6 addresses and just have IPv4 in the data. That way you have predictable and useful (although without IPv6) data.

[jokob-sk]

@ozdeadmeat You can disable alert events. See this doc for more information
https://jokob-sk.github.io/NetAlertX/NOTIFICATIONS/?h=not

[KoRRo]

Hi @jokob-sk,
As you asked in my other thread, I am continuing the discussion here.
For everybody else that did not read my other thread, I had a similar issue, but the cause for me was linked to multiple VLANs (and therefore multiple IPv4 addresses) on a single interface.

Unfortunately, I do not have the time at the moment to read through the source code and create a proper solution, but with a little AI help, I have put together a suggestion on how this could work.

Currently, it seems the system treats the MAC address as the unique primary key, leading to IP Changed alerts when a single hardware interface serves multiple subnets.

Current Logic:
I guess the current logic looks something like this:

if mac_exists(discovered_mac): 
    if discovered_ip != stored_ip: 
        update_device_ip(discovered_mac, discovered_ip) 
        trigger_alert(IP Changed) 
    else: 
        mark_as_online(discovered_mac) 
else: 
    insert_new_device(discovered_mac, discovered_ip)

Proposed Solution:
Composite Key and Static Mapping Logic:
To support multi-IP scenarios without overcomplicating the automated discovery, we could introduce a Context or VLAN field and include it (along with the IP version) in the device identification logic.

Key changes:

• Composite Identity: Identify a record by MAC + IP_Version + VLAN/Tag.
• Static Flag Priority: Use the existing Static IP flag as a manual override to lock a MAC to a specific IP/VLAN combination.

Proposed Logic:

def process_scan_result(mac, ip):
    ip_version = get_ip_version(ip)

static_record = db.query(SELECT * FROM devices WHERE mac=? AND ip=? AND is_static=1, mac, ip)

if static_record:
    update_status(static_record.id, Online)
else:
    dynamic_record = db.query(SELECT * FROM devices WHERE mac=? AND is_static=0 AND ip_version=?, mac, ip_version)
    
    if dynamic_record:
        update_device_ip(dynamic_record.id, ip)
    else:
        insert_new_device(mac, ip, ip_version)

Why this works:

• For VLANs: Users can manually set the different gateway IPs as Static. The system will then treat 192.168.1.1 and 192.168.20.1 as distinct monitored entities despite having the same MAC.
• For IPv4/IPv6: Since IP_Version is part of the logic, the v6 address will not overwrite the v4 address.
• Manual Control: By making the VLAN field manual, we avoid the complexity of trying to guess the network topology automatically.

What do you think?

[KoRRo]

Sorry, but i did read the full thread, my remark about not having time was to excuse myself for not tailoring my suggestion to your code, not as an excuse for not reading. Having said that, i still might have grossly misunderstood the thread o i might have explained myself poorly.
It is not my intention to derail the conversation, but I will try to explain my reasoning better, if you still think this is not relevant i will not insist, no hard feelings.

First of all, let's establish a bit of context:

1. i had a similar problem and i opened my own thread ( Single mac, multiple IPs due to vlans #1372)
2. your response ended with "Also, if you have feedback how to handle this scenario better, please feedback here"
3. after reading this thread my conclusion was that we have 2 use cases for managing multiple IPs for a single physical device (dual-stack and vlans) that can maybe be solved with a single solution.

now, this was my reasoning for the solution:

1. the software already handles child devices like NICs, this could be a starting point to avoid changing the whole logic of the software
2. the software seems to use the mac address as primary/unique key for devices (if i try to insert a new device with the same mac i get an error, so i'm pretty sure of that)
3. considering point number 2 we cannot use use child devices as suggested in point number 1 unless we loosen the primary key
4. solving the use case about IPv4 and IPv6 can be quite simple since we can easilly find the ip version just by looking at the IP itself, and this information can be easilly added as part of the primary key whithout breaking the rest of the code and all existing installations.
5. no, this doesn't solve the problem about the 2 IPv6 + 1 IPv4 you were also discussing, but honestly i don't know enough about IPv6 to incoporate also this in my solution, but my solution for the vlans can maybe be a starting point even for this.
6. to solve the vlan problem (remember this is why i came here, so honestly this is my priority) we need another piece of information to add to the primary key to create multiple child devices with the same ip version.
7. Asking the software to recognize the vlan automatically (as i suggested for the IP version) would be unrealistic, so i opted for a semi manual solution
8. the first step for my solution as mentioned above is adding a manual field to track the vlan and use it as part of the primary key (again this should not break the software or existing installations)
9. now we can save the devices for both the use cases, but we still need to change a bit the logic when saving the devices. this message is already quite long so for the save logic i will ask you to read again my pseudo code snippets in my previous message
10. one last remark, i added a check on the static ip flag in my solution. with the rest of the logic in place i don't think it is strictly necessary, it is just a failsafe to avoid creating many records in case a device was using dynamic ip and the user was using the vlan field in a way it was not intended. i don't think there are many devices out there using multiple vlans and dynamic ip at the same time, so i think this is a safe assumption.

This might not be the perfect solution and surely i might be missing something since i haven't studied your code, but from my understanding of how the program works this is how i would implement it if it was my project. I hope this clarifies what i was suggesting.

[jokob-sk]

sorry for my rash response, just getting stressed a bit by the amount of issues and limited time to address those+ your ask which is a substantial one.

the first step for my solution as mentioned above is adding a manual field to track the vlan and use it as part of the primary key (again this should not break the software or existing installations)

changing the primary id would be a substantial rewrite - the original author based all internal keys/PKs on MACs so replacing these relationships, without breaking existing functionality, is challenging. There is already a devGUID generated for each device. Unsure if sufficient or a composite key should be created from other fields (macs and IPs might change so that might be challenging).

Things to solve include:

1. Add the devGUID as a binding field to all related records (Events, Sessions, Notifications, CurrentScan )
2. Loosen the primary key requirement for the Devices table
3. Change duplicate detection on the Devices table (currently handled by refusing duplicate MACs)
4. Can't the VLAN be auto assigned by the subnets configuration (my network knowledge is limited)?
5. How should a scanner attribute the result to the correct device? Some scanners rely on macs only, some on IPs only. if any is shared,which device is to be updated? What about related records such as events or sessions?

Number 2 & 5 worries me the most as it could result in inconsistencies, changed behavior from previous versions, or duplicate device entries, messing up existing installations.

Also, if I'm about to touch all these DB tables, I would also rename the fields to make them GraphQL compatible (no _).

Just to add context to how substantial this change would be.

[jokob-sk]

Feel free to have a look at the current code if you have suggestions:

• https://github.com/jokob-sk/NetAlertX/blob/main/server/scan/device_handling.py
• https://github.com/jokob-sk/NetAlertX/blob/ffdde451d66030e2f5981384f255099194b852d1/server/scan/session_events.py#L178

Also, some users have ~3000-9000 devices so any solution should also be performing well for device matching and events update/inserts. That means a scan cycle needs to be able to quickly update almost 10k entries. AFAIK SQL operations are the fasted way how to handle this, moving the logic into the app would create a new performance bottle neck - I might be wrong.

[KoRRo]

Don't worry, I know the feeling. End of the year is always crazy also for me.
Yes, from your description the change is more substantial than what I anticipated. I will try to find the time to check the code and maybe come up with a better strategy

[jokob-sk]

I still want to solve this in the long term. As a first step I might add 3 new fields (probably the release after next as I want the current release to stabilize first). These would be:

• devPrimaryIPv4 (auto populated)
• devPrimaryIPv6 (auto populated)
• devVlan (manual ?)

This should then provide a good starting point to implement some of your proposed changes going forward.

[jokob-sk]

This is partially resolved in the netalertx-dev image if someone wants to test. Now logging ipv4 and ipv6 and checking against latest reported. Ideally, spin up a separate container with a separate db and config as DB modifications can happen).

Make sure you refresh your browser cache - and click the 🔄 refresh button in the top right corner.

Disclaimer:
Running on the dev container long term might lead to data loss as upgrade path is not guaranteed.

Thanks in advance,
j