А зачем в базе 2 а то бывает доходит до 7 одинаковых точек ? если можно сохранять последнюю актуальную точку с паролем) а определяется эта точка по дате в листе который загружается в базу)

насколько я понимаю здесь идет обсуждение и предложение) и каждый может написать просьбы и предложения)я же не требую) авторам самим решать чем им заниматся) я просто делюсь мыслями вдруг будет полезна. а нет просто проигнорируют) или попросят больше не предлогать0

Ну а как определить что это та же самая точка?

Если предположить (а по спецификации так и должно быть), что у каждого устройства свой MAC адрес, то всё выглядит просто - берем BSSID и говорим, что это поле должно быть уникальным. Тут же идем в статистику, смотрим таблицу "BSSID / MAC-адрес" и грустим по поводу 00:12:34:56:78:92 - 862 точки, с разными паролями, пин кодами, прошивками... Терять не хочеться, а ведь это только вершина айсберга, уникальных BSSIDов в базе 745'983, а всего точек 865'316, т.е. таким способом потеряем 119'333 точки (включая дубли).

Окей, разные ESSID'ы +BSSID. А если название изменится? - один фиг дубль получится, т.е. цели не достигнем, а точки потеряем.

Название устройства\прошивку в учет брать нельзя - прошивку можно и обновить, а разные версии RS могут по разному считать инфу.

Предположим, что мы изобрели хитрый механизм, позволяющий точно определить дубль это или совсем другая точка. Встает другая проблема - а какая информация является актуальной? Нужно вводить в прогу RS дополнительный столбец дата, а значит отказ от поддержки старых версий RS. В итоге - чего ради? Ну лежит у нас в базе устаревшая инфа, ну занимает она не более 119'333/865'316*100%=13.8% ну и что теперь с того? Было бы это 200%, я бы еще подумал, а так это не минус - это плюс - я могу посмотреть историю изменения паролей по данной точке, и возможно мне это поможет угадать новый пароль.

Доступ к Router Scan есть у всех, следовательно делать какие-то проверки подлинности - бессмысленно.

Насчёт дат загрузки, для ответственных пользователей есть галка "Не обновлять точки в базе, если ваши данные устарели".

И я считаю, что хранить всю историю изменений - идеально, ибо хозяин может поменять пароль на один из ранее придуманных. Плюс товарищи из темы словарей огорчатся, если пассворды начнут пропадать.

Уважаемый @binarymaster, может сделать интеграцию с nmap? Т.е. nmap сканирует заданный диапазон, возвращает открытые ip:port, а RS уже по этому списку проходит всем свои арсеналом. Пока что пробую просто по списку IP проходить - уже в разы быстрее, а с портом в придачу было бы еще круче.

Помню, кто-то из пользователей RS когда-то использовал VNC сканер в режиме connect вместо встроенного, а потом отдавал IP-адреса на обработку программе.

В результате, при большом кол-ве макс. потоков программа почти полностью съедала ресурсы и сетевой канал. Поэтому в таких юзкейсах потоков нужно ставить меньше - от 10 до 20, поскольку сканирования диапазонов как такового не осуществляется.

Я вот о чем (лог nmap)

Нужно загрузить такой отчет и вычленить из него в следующем формате:

Ну или так:

Далее загрузить получившийся список в диапазоны для сканирования RS. Ну и добавить поддержку такого формата в RS: если есть двоеточие и список портов за ним, то сканировать только эти порты, а если просто IP без портов - то использовать список портов по умолчанию.

Не проще в таком случае использовать zmap? Тем более если быстрый интернет можно хоть весь мир просканить.

Ну хорошо, просканировавали, добавили, а у провайдера опять произошел РАЗРЫВ СВЯЗИ))))это тот чувак, что звонил в тп и орал.... для каламбура) ну в состветствии сменились ip адреса, вопрос на сколько это целесообразно, чем муторно и долго сканировать заданный диапазон по провайдеру? конечно если маленькими порциями сканировать.... тут уже спора нет.