Rewrite detection of ipv6-addresses & ipv6-networks to LibreNMS/Modules

[Npeca75]

1. drop all .inc.php files
2. drop all hard coded OIDs
3. drop old DB code
4. detect SpecialOS es (previous .inc.php)
5. drop old discover_process_ipv6() from functions
6. include ipv6-addresses in json test data
7. include ipv6-networks in json test data
8. translated address origin
9. proper handling of multiple IPv6 Addresses
10. proper handling of IPv4 compatible IPv6 Addresses (tested on Jetstream and linux derivates)

DO NOT DELETE THE UNDERLYING TEXT

Please note

Please read this information carefully. You can run ./lnms dev:check to check your code before submitting.

• Have you followed our code guidelines?
• If my Pull Request makes discovery/polling/yaml changes, I have added/updated test data.

Testers

If you would like to test this pull request then please run: ./scripts/github-apply <pr_id>, i.e ./scripts/github-apply 5926
After you are done testing, you can remove the changes with ./scripts/github-remove. If there are schema changes, you can ask on discord how to revert.

[Jellyfrog]

@Npeca75 does this has the same problem as the other one?

[Npeca75]

@Npeca75 does this has the same problem as the other one?

Hi @Jellyfrog

i understand your concern 🙂
using this patch on 5 distributed poller, cca 220 pcs of unique IPv6 address and 61pcs of IPv6 network
using 3 special OS and bunch of device in "standard OS" category

for now, everything is looks good
mostly /64 and /120 prefixlen

but, to be sure let me test it again with some "strange" prefixes
will drop you a note

[Npeca75]

@Npeca75 does this has the same problem as the other one?

Hi @Jellyfrog
tested again, everything works fine

[murrant]

@Npeca75 Thanks for starting work on this! We need to make some changes to make it align with the overall design of the new modules.

You are missing a design pattern that puts all OS specific code in the OS classes within LibreNMS/OS.

We do this by creating an interface for discovery/polling and implementing that on the OS. These functions return a collection of models. For this module, you would not need to create a polling interface of course.

We can then use the Keyable interface on the model to sync them to the database with $this->syncModels()

Check out the Isis.php module and others for an example.

[Npeca75]

You are missing a design pattern that puts all OS specific code in the OS classes within LibreNMS/OS.

done
but ... not as you expected :(
yes, i wrote a separate discovery modules for each special OS, this is OK, but

We can then use the Keyable interface

it is over my head

1. ipv6address discovery use two table, ipv6addresses & ipv6networks
2. if (big if) someone finish this and make "keyable" thing to work, there will be duplicate, triplicate etc code because then, in every specific OS file you need to have complete code for both networks&addresses

so, i did:
specific os have snmp discovery & put in array
main module then do the rest of job

ok, half way you wanted ... but as i said, i will be glad if you rethink your demand or help me with co-authoring