darcosion
commented
2 years ago A priori, réglé juste avec de l'UI 79e0195b0a81d19e540418b9bc102dce7eea2368.
Le scan local a été séparé comme il se doit :
Cette issue peut être fermé pour qu'on se concentre sur la second phase de refactoring des scan locaux/distants car j'ai l'impression qu'il y a plusieurs soucis avec :
- Les scan DHCP semble ne pas fonctionner (bug)
- Les scan ARP & fast_ping ne prennent pas en compte les interfaces, c'est du à leur fonctionnement interne qui "ignore" les paramètre qu'on leur passe en terme de scan d'IP. Une solution consisterais à forcer l'interface qu'ils utilisent en priorité, ce qui signifie leur passer leurs interfaces en option (refacto)
- Les scan locaux doivent être améliorés (SNMP/SSTP/LLDP/ARP aggressif et bien d'autres) (enhancement)
Actuellement, les refacto #64 et #65 ont montrés que les fonctions scan_arp et fast_ping sont sévèrement imbriqués avec la logique de découverte de réseau locaux.
Une solution pour s'en sortir serait de séparer la logique de découverte de réseau local en deux logiques : une découverte de niveau 2 (couche liaison - ethernet, interfaces) et une découverte de niveau 3 (couche réseau, et au dessus, IP). De cette façon, comme "on ne choisit pas le réseau sur lequel on atterrit", il sera toujours plus intéressant de donner à l'utilisateur deux choix dans l'approche scan CIDR :
Cela nécessite en premier lieu la résolution de l'issue #66 , puis un refactoring du panel de gestion de scan CIDR, et enfin la séparation des deux types de scan au niveau de la documentation.