sfstudio Опубликовано 12 сентября, 2017 · Жалоба Т.е. iwpriv не сегфолтиться? Ну значит траблу надо искать где-то в функциях libwive которые собсно дёргают те же ioctl что и iwpriv. Sadler. Твоя работа ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 12 сентября, 2017 · Жалоба Повторил, пофиксил. Правка будет в 6.5.7 либо сегодня вечером залью либо завтра утром. Проблема была в регулярном выражении проверяющем не входит ли WAN интерфейс в какой-либо бридж. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 12 сентября, 2017 · Жалоба Пробуйте. https://sourceforge.net/projects/wive-ng/files/wive-ng-mt/test-only/ Да и ещё. Судя по логу у вас нет dhcp, т.е. используется чистый PPPOE для доступа в инет? Ну значит галка Pure PPPOE должна быть включена до кучи. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
igwt13 Опубликовано 13 сентября, 2017 · Жалоба 11 часов назад, sfstudio сказал: Пробуйте. https://sourceforge.net/projects/wive-ng/files/wive-ng-mt/test-only/ Да и ещё. Судя по логу у вас нет dhcp, т.е. используется чистый PPPOE для доступа в инет? Ну значит галка Pure PPPOE должна быть включена до кучи. Спасибо. Сейчас буду пробывать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
igwt13 Опубликовано 13 сентября, 2017 · Жалоба sfstudio Работает. Спасибо за оперативность. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sadler Опубликовано 20 сентября, 2017 · Жалоба Проблему обнаружил и устранил, в основную ветку закоммичу ориентировочно завтра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 21 сентября, 2017 · Жалоба Залил 6.5.9, проверяйте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CHIPSET7 Опубликовано 21 сентября, 2017 · Жалоба Всё работает, всем спасибо! И отображает в SSH теперь корректно. Пойду тестировать L2TP-сервер... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CHIPSET7 Опубликовано 13 октября, 2017 · Жалоба L2TP-сервер вроде как работает исправно. Но есть один момент. У сервера и клиента на доступе IPoE. Прошивка 6.5.9. При настройке сервера изменён диапазон адресов, MTU/MRU выставлены в 1460 и включена отладка. При настройке клиента интервал и количество допустимых ошибок LCP выставлены в 5, отладку забыл включить. При таких условиях и настройках всё прекрасно работает, если в роли L2TP-клиента выступает 3050. Переведя на 7620 сервер, решил попробовать перевести и клиентов. И тут засада: Спойлер Sep 21 15:58:48 pppd[3262]: LCP terminated by peer (Peer not responding) Sep 21 15:58:48 pppd[3262]: Connect time 0.5 minutes. Sep 21 15:58:48 pppd[3262]: Sent 1363060504 bytes, received 0 bytes. или Sep 21 16:00:31 pppd[6489]: No response to 5 echo-requests Sep 21 16:00:31 pppd[6489]: Serial link appears to be disconnected. Sep 21 16:00:31 pppd[6489]: Connect time 0.5 minutes. Sep 21 16:00:31 pppd[6489]: Sent 563308 bytes, received 0 bytes. В это время на сервере: Oct 11 16:50:09 pppd[16586]: No response to 8 echo-requests Oct 11 16:50:09 pppd[16586]: Serial link appears to be disconnected. Oct 11 16:50:09 pppd[16586]: Connect time 0.5 minutes. Oct 11 16:50:09 pppd[16586]: Sent 375 bytes, received 0 bytes. В последующих попытках в "отправлено" тоже становится ноль байт. Понятно почему отключает и почему через пол минуты, но не ясно почему данные не идут. Настройки клиента по умолчанию ничего не решили. На всякий случай прикрепляю полный лог клиента и лог сервера начиная с момента замены железа и до возврата 3050 на место. Адреса для удобства изменены на 10.0.0.2(сервер) и 10.0.0.3(клиент). client.txt server.txt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 13 октября, 2017 · Жалоба Роуты сравните там и там. Изменений было много может что-то и "поломалось". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CHIPSET7 Опубликовано 14 октября, 2017 (изменено) · Жалоба Действительно, прописав маршрут на WAN по типу 10.0.0.0 255.0.0.0 10.0.0.1 всё заработало. Разница в маршрутах заключается только в интерфейсе маршрута по умолчанию: в 3050 до подключения - WAN, после - VPN; в 7620 - всегда LAN. З.Ы. В ip-up кстати упущена буква U в слове requested. Изменено 14 октября, 2017 пользователем CHIPSET7 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 14 октября, 2017 · Жалоба Цитата 3050 до подключения - WAN, после - VPN; в 7620 - всегда LAN. Быть не может. Более того, я вот щас ругаться буду. Я на гадалку похож? Там стопка маршрутов рисуется. И причём тут LAN вообще? Конкретику + реквизиты доступа + конфиг - будем разбираться. Не надо пытаться волно пересказывать, то что можно показать в выводе команд. Не надо обгрызать вывод или что-то менять в выводе. DGW в LAN сроду никогда не задавался и не задаётся ни на 3050 ни на 7620, кроме случая с режимами где WAN вообще нет. В сторону LAN прописывается роут только до локальной подсети. Его вообще ядро само добавляет. Всё остальное в WAN и если надо dgw перекидывается в VPN при этом роут до VPN сервера ессно должен существовать через WAN. Эт всё даааавно было автоматизировано. И если нет пересечений адресации сетей то проблем быть не должно. Именно потому что DGW перекидывается в туннель, при этом нет статик маршрута до VPN сервера через WAN такое обычно и происходит. Значит автоматика рисующая этот маршрут не отработала. Вопрос почему. Если сети пересекаются - тут прописываем руками ибо прошивка не обладает доступом к астралу. Вроде не первый день блин знакомы. Чего за гадания опять с сочинительством? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CHIPSET7 Опубликовано 14 октября, 2017 · Жалоба Извините, видимо понесло что-то или не так понял. Как я выше писал в обоих местах IPoE(локальная сеть провайдера). Сеть 10.0.0.0 разделена на сети /22. В одной нахожусь я, в другой клиент. Ну прямая видимость в общем. DHCP нету, так что WAN точно у всех настроен. Диапазоны не пересекаются(снаружи - 10, внутри 192, в туннеле- 172). Про конфиг я вроде тоже писал - смена диапазона, MTU/MRU и LCP. К счастью сделал скрины с веб-страницы. Если нужен вывод с консоли, завтра съезжу и сниму. Реквизиты: сервер 10.188.5.122/22 шлюз 10.188.4.1 | клиент 10.188.17.207/22 шлюз 10.188.16.1. Диапазон VPN 172.16.11.2-172.16.11.5. Из сервисов включены UPNP, DNSproxy и Watchdog. Порты выставлены в 100FD. На WAN MTU 1500 поставлен. Пароли на wi-fi и устройство. Не знаю, что ещё написать... routes.bmp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CHIPSET7 Опубликовано 14 октября, 2017 · Жалоба Ещё включены Samba и NTP. Кстати я сейчас с сервера и пишу, здесь маршрут тоже на LAN, как в изображении выше. Пока смотрел настройки, заметил, что страница DHCP теперь выдаёт: Цитата В FF: Error evaluating /services/dhcp_clist.js: SyntaxError: JSON.parse: unexpected character at line 1 column 104 of the JSON data В Chrome: Error evaluating /services/dhcp_clist.js: SyntaxError: Unexpected token ] in JSON at position 103 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 14 октября, 2017 · Жалоба 1) ну реквихиты мне в личку 2) раз не включен DHCP то автоматом роуты не построятся скорее всего, но надо смотреть, к счастью у меня сейчас доступ тоже без DHCP, так что жду реквизиты 3) эт к веберу, т.е. в соответвующую тему. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CHIPSET7 Опубликовано 14 октября, 2017 · Жалоба Так я их уже написал, теперь не удалить. Разве что DNS не указал. Или что-то упустил? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 14 октября, 2017 · Жалоба Всмысле? Я грю логин, пароль, адрес сервера что бы мне проверить. В лоб не вижу. Что надо прибить? Делов-то. =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CHIPSET7 Опубликовано 14 октября, 2017 · Жалоба Да это я про адреса из локальной сети писал, про них подумал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 15 октября, 2017 · Жалоба 16 часов назад, CHIPSET7 сказал: Извините, видимо понесло что-то или не так понял. Как я выше писал в обоих местах IPoE(локальная сеть провайдера). Сеть 10.0.0.0 разделена на сети /22. В одной нахожусь я, в другой клиент. Ну прямая видимость в общем. DHCP нету, так что WAN точно у всех настроен. Диапазоны не пересекаются(снаружи - 10, внутри 192, в туннеле- 172). Про конфиг я вроде тоже писал - смена диапазона, MTU/MRU и LCP. К счастью сделал скрины с веб-страницы. Если нужен вывод с консоли, завтра съезжу и сниму. Реквизиты: сервер 10.188.5.122/22 шлюз 10.188.4.1 | клиент 10.188.17.207/22 шлюз 10.188.16.1. Диапазон VPN 172.16.11.2-172.16.11.5. Из сервисов включены UPNP, DNSproxy и Watchdog. Порты выставлены в 100FD. На WAN MTU 1500 поставлен. Пароли на wi-fi и устройство. Не знаю, что ещё написать... routes.bmp Судя по routes.bmp в роже до кучи кто-то заломал парсилку роутов. Сравните плз показания в роже и выводе route -n. Если будут отличия - плз в тему по web. Логику автороутов для VPN сейчас проверю. Хотя не лишним было бы так же показать route -n после соединения на 3050 и 7620. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 15 октября, 2017 · Жалоба Так, да роуты в роже парсятся криво. Щас пну вэбера. Задрали меня эти регрессии по роже. Но блин эт неизбежность тотального рефакторинга. По проблеме, вроде разобрался. Сейчас соберу 6.6.7. Правда у себя повторить не смог,но оно и понятно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 15 октября, 2017 · Жалоба Плюнул, переделал весь кусок. Пробуйте. SNR-CPE-W4N-MT-MT7620-2T2R-8M.6.6.7_RU.15102017.bin.zip Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CHIPSET7 Опубликовано 15 октября, 2017 · Жалоба Спасибо большое, маршрут появился! В журнале кстати выглядело так, как-будто повторить получилось(последние попытки). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 15 октября, 2017 · Жалоба Нет. Последние попытки эт я принудительно по голове давал ради проверки самовосстановления. Полечилось эт хорошо. Загогоняю регрессивные тесты и ждём вэбера... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
r1vver Опубликовано 17 октября, 2017 (изменено) · Жалоба Новомодная WPA2 уязвимость KRACK в версии 6.6.8 уже учтена? Что то там CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, CVE-2017-13087, CVE-2017-13088. Изменено 17 октября, 2017 пользователем r1vver Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sfstudio Опубликовано 17 октября, 2017 · Жалоба 1) ченджлог для кого придумали? Он прям в прошивке актуальный. В гите всё видно и т.д. 2) https://forum.nag.ru/index.php?/topic/134872-wpa2-vzlomali/ 3) почти все эти уязвимости вообще не касаются AP, часть касается режимов TKIP которые и без того дырявые, большей части из них у нас не было и не будет, т.к. они касаются конкретной реалиазции в wpa_supplicant Проще говоря. Уже неделю как всё это зафикшено. Но я уже задолбался повторять. Что это всё уязвимости клиентской части (кроме CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.). Она так же пофикшена. Не туда вопросы задаёте. Производителям ваших клиентских устройств задавайте, телефонов, карточек и прочих кофемолок. Уязвимости эти касаются их, а не АП (кроме выше обозначенной в п3). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...