Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

(решено, проблема в физике) Пропадает интернет и возвращается после перезагрузки (продолжение)

Снова пропадает интернет после примерно 20 мин работы по "воздуху" или по кабелю с FT-AIR-DUO-G на ноуте, также на смартфоне и возвращался после перезагрузки с "вебморды" или выключением питания FT-AIR-DUO-G.

Имеем:

FT-AIR-DUO-G

Версия ПО  2.7.15.RU.11082020

- сброс настроек до заводских кнопкой Reset;

-далее минимальная настройка (PPPoE-логин-пароль на провайдера РТ- по технологии FTTx, "воздух" 2.4 ГГц без шифрования, 5ГГц отключен ), также ничего не трогал в доп. настройках, кроме установки логирования на Debug.

и так много раз ....

Приложен экспорт конфига (заменены * логин и пароль и MAC адреса), также лог в режиме Debug после пропадания интернета по кабелю от FT-AIR-DUO-G на ноуте и перехода на "воздух". Лог короткий, потому что не сохраняет он больше, а передать на IP удаленной системы не получается.

Очень хотелось бы разобраться с этой проблемой, уже больше недели после покупки прошло, а с инетом вот так чудит.

Приходится подключать свой старый ZTE ZXHN H118N и на нем интернет не пропадает и не пропадал.

Далее для sfstudio:

По моей предыдущей теме по пропаданию интернета Вы неправильно поняли с текста по поводу прошивок.

Официально заявляю - прошивки левые для FT-AIR-DUO-G не использовал и не пытался, кроме как с кнопкой "Проверить" и "Обновить".

Зачем, и так глюков в нем хватает и еще на гарантии, пусть этот вопрос решают производитель железа и ПО.

Мои записи были по поводу перепрошивок роутеров других производителей, с которыми были иные проблемы и их перепрошивка не приводила отсутствию интернета через каждые примерно 20 мин. как сейчас...

Считаю, что Ваши подозрения неуместными, иначе получится, как вот здесь.

Для оперативного решения проблемы могу допустить удаленно до пациента или дайте пожалуйста последовательность действий с моей стороны, которая поможет ускорить процесс исправления проблемы.

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

1. верните отладку на родину в дефолт, иначе кроме дебага ngix там нет ничего, по умолчанию разве что в настройках vpn debug включить
2. мне не интересен ваш опыт с перепрошивками других устройств, это лишний шум который ничем кроме как недоразумениями не грозит. Мне хватает и так подземных стуков и бесполезной инфы.
3. считаю неуместным замусоривать топик левой инфой о каких-то левых устройствах, а то получится как с "не единого разрыва"
4. плавающий характер проблемы всегда намекает на проблемы с линком, свитч в MT7621 достаточно чувствителен к длине и качеству (скрутки, сопли, окисел в коннекторах) оного (как впрочем и другие интегрированные в SOC современные свитчи в отличии от старых).

В общем жду нормального лога после проявления проблемы. И уверен на 99% там будет событие Link Down на WAN. Решений обычно при такой проблеме возможных 4:
1. тыкнуть свитч дешовый в разрыв кабеля провайдера, желательно вместо скрутки или каких-нить там бочёнков (если есть), дешовые свитчи на древних риалтэках гораздо менее к этому чувствительны
2. использовать старый роутер как собсно роутер или перевести его в AP режим вырубить радио и использовать как тот самый свитч
3. чинить линию
4.  судорожно искать новый девайс который не будет на этом линке ловить link down регулярно при изменении чего-то во вне. А потом ждать когда и на нём начнётся тоже самое ибо "хвосты" деградируют со временем + сопли в виде скруток образовываться имеют свойство у провайдеров массово. Ибо режут и ессно никто линию не перекладывает.

Все кроме 3го варианта это костыли.

Жду лог. И ещё раз просьба. Без левой инфы. Она не нужна тут. Не интересно и вредит делу.

Как и фантазировать не стоит о постоянных обновлениях. Ну вот не было обновлений, а ситуация повторилась? Знач ищем что-то в аппаратной части раз программно ничего не менялось. Перезагрузка просто реинитит свитч и линк заживает на какое-то время.

Эт всё по опыту и на правах гадакли ибо лог просто в кашу из-за врубленного дебага нгикса. Зачем включенного не ясно. Никто не просил вроде.

По конфигу криминала кроме обозначенного выше не вижу.

включил в настройках:

- vpn debug;

-перевел лог в info

изменения более не вносил

приведу в приложенном файле лог (внутри поставил звездочки на мои IP и MAC) сразу после пропадания интернета,  где есть момент подключения с смартфона, коротковат он, как бы удлинить, т.е. передать в файл, чтобы можно было по времени реконнекта искать , подскажите направление.

после пропадания интернета пропадает пинг наружу, "вебморда" доступна и FT-AIR-DUO-G подмигивает огоньками светодиодов, т.е. он не заморожен

опять надо подойти к нему и по reset-у, полезно конечно каждые почти двадцать минут по 40 метров прогулки туда-сюда, ну не сижу постоянно на "вебморде", чтобы программно перегрузить

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

Я не вижу тут ни падение линка ни падения сессии. Только одно убийство pppd по сигналу 15 что следствие

vpnhelper-pppoe: ==================START-PPPOE-CLIENT=======================

После чего сессия поднялась и собсно лог на этом кончился.

Тут исключительно в морде кто-то тыкнул apply в VPN больше ни сесся не рвалась (возможно ещё не истёк таймаут LCP-ECHO по которому PPPD детектит что сессия умерла).

Ничего другого в этом логе я не вижу.

Что на главной страице видно по статусу портов? Особенно WAN. Не съезжает в какие-нить 10Мбит? Ибо может и не быть именно Link Down, а пересогласование в какой-нить 10Half duplex при этом с потерями в полку.

На крайняк для пробы старый роутер в AP режим, отключаем DHCP и радио на нём и тыкаем для проверки в разрыв WAN просто как свитч. Нужно проверить вот эту догадку, потом не знаю что-то думать.

Или свитча нет самого обычного на пробу ткнуть в разрыв WAN?

Если в логах только это и втыкание свитча в разрыв не поможет, то только возвращать железку по гарантии. Ибо с РТ добиться что бы они в момент появления проблемы посмотрели хотя бы на домовом свитче что там с линком это без шансов.

 

после пропадания интернета пропадает пинг наружу, "вебморда" доступна и FT-AIR-DUO-G подмигивает огоньками светодиодов, т.е. он не заморожен

Не завис наверное хотелось сказать?

опять надо подойти к нему и по reset-у, полезно конечно каждые почти двадцать минут по 40 метров прогулки туда-сюда, ну не сижу постоянно на "вебморде", чтобы программно перегрузить

Какому ещё резету и зачем?

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

В текущий момент никаких проблем в логе нет.

Пароли везде изменены от дефолтовых? Ну раз wifi у вас открыт (что дурь редкая). Точно не утекли пароли? А то мож кто развлекается.

Что бы писать длинные логи достаточно просто на ПК подключенном к сети постоянно развернуть remote syslog например. Можно вообще ткнуть флэшку затем

зайти по ssh и сказать что-то типа killall -9 syslogd && syslogd -b0 -l7 -S -D -L пусть_куда писать_лог.

Вариантов масса, другое дело что нет в логе ничего у вас. Вообще. Если лог выше в момент возникновения проблемы то pppd даже ещё об этом не узнал, и это не удалённая сторона ему что-то сказала.

Это конкретно очень похоже на фиговый линк. Тут см выше.

Можно в настройках свитча для WAN задать жёстко 100Мбит и вырубить автонеготинэйт и контроль потока. Тогда вероятнее всего те самые event`ы о link down увидим.

То что тут до софта как до шанхая в части проблемы как раз и говорит, что ppp сессия на роутере даже не рвётся, а инет внезапно пропал. Т.е. нужно смотреть ниже. А ниже только свитч, софта в нём нет никакого по сути. Лечить софтово не чего.

 

 

изменил скорости портов, показательно на приложенном скрине

очистил лог, чтобы фиксировать только момент потери линка

может сесть на мобильного провайдера, где-то старый USB модем имеется,  сможем ли сэмулировать ситуацию или не стоит

свича простого нет и скорее не справлюсь переводом в свич старого ZTE

пароли все по умолчанию, эфир открыт (это же "бешеные" скорости без шифрования, нет необходимо тратить процессорное время на запросы пакетов "свой-чужой",  а точек доступа в округе как "кильки в бочке")

так, хожу пешком - оговорился- не к reset-у, а кнопке питания, нет же интернета ни по кабелю к нему ни по "воздуху"

 

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..
  1. зачем везде вырубили? Чётко же сказано тольуо WAN
  2. не понял причём тут модем
  3. на ZTE достаточно вырубить встроенный DHCP сервер и радио и использовать любые 2 LAN (не WAN) порта как порты свитча
  4. процессорное время на шифрование трафика НЕ ТРАТИТЬСЯ. Там в радиочипе (MT7615) свой криптоблок заточенный на конкретно шифрование, ни один цикл CPU точно не пострадает, в отличии от открытой АП, именно что в говноэфире да без шифрования... Не надо выдумывать, используйте шифрование ВСЕГДА. Никто на CPU ничего нынче не шифрует в 802.11 (лет 12 как), есть специальные криптоблоки в радиочипах для этого. Кто вам о экономии ресурсов CPU таким образом сказал я даже боюсь предположить...

Я даже больше скажу, что все пароли посланные по http через открытое радио перехватываются обычным wireshark, прям прямым текстом. Оно вам надо? Включите шифрование на родину.

ПАРОЛИ ВСЕ СМЕНИТЬ. Вообще система не зря аж алярмы рисует что ВАЖНО изменить пароли и включить шифрование.

Просто я даже не знаю что сказать, сеть открытая, пароли в дефолте... Заходи кто хочешь-делай что хочешь... НЕЛЬЗЯ ТАК. Следуйте рекомендациям по безопасности. ОБЯЗАТЕЛЬНО.

 

сделал - встроенный DHCP отключил в разделе Lan и отключил wi-fi и использовал 2 LAN (не WAN) порта как порты свитча

но в логах вот что и это оттуда все записи и нет интернета, хотя перезагрузил:

Aug 17 20:59:39 udhcpc[2318]: sending discover
Aug 17 20:59:44 udhcpc[2318]: sending discover
Aug 17 20:59:49 udhcpc[2318]: sending discover
Aug 17 20:59:54 udhcpc[2318]: sending discover
Aug 17 20:59:59 udhcpc[2318]: sending discover
Aug 17 21:00:04 udhcpc: Lease fail eth3.
Aug 17 21:00:24 udhcpc[2318]: sending discover
Aug 17 21:00:25 pppd[4431]: Timeout waiting for PADO packets
Aug 17 21:00:29 udhcpc[2318]: sending discover
Aug 17 21:00:34 udhcpc[2318]: sending discover
Aug 17 21:00:39 udhcpc[2318]: sending discover
Aug 17 21:00:44 udhcpc[2318]: sending discover
Aug 17 21:00:49 udhcpc: Lease fail eth3.
Aug 17 21:01:09 udhcpc[2318]: sending discover
Aug 17 21:01:14 udhcpc[2318]: sending discover
Aug 17 21:01:19 udhcpc[2318]: sending discover
Aug 17 21:01:24 udhcpc[2318]: sending discover
Aug 17 21:01:29 kernel: device br0 entered promiscuous mode
Aug 17 21:01:29 udhcpc[2318]: sending discover
Aug 17 21:01:33 kernel: device br0 left promiscuous mode
Aug 17 21:01:35 udhcpc: Lease fail eth3.

что еще предпринять?

исключил из цепи FT-AIR-DUO-G оставив ZTE как свич и связал ноут по кабелю

интернет есть

вернул FT-AIR-DUO-G за свич

пинга наружу нет, интернета нет

лог после возврата в приложенном файле (забил * мои IP)

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..
  1. на РТ в настройках VPN должна стоять галка PurePPPOE нет у РТ dhcp
  2.  Ок попробую по шагам. WAN FT-AIR в LAN1 ZTE, в LAN2 ZTE провайдерский кабель. На ZTE ничего (никаких PPPOE/DHCP и прочего настроено быть не должно, т.е. сбросили ZTE, зашли в настройках отрубили DHCP сервер и радио и всё, в терии LAN порты у него просто будут работать как свитч).

По логу нет ответов никаких из сети, вообще. Ни на pppoe discovery ни на dhcp discovery. Линк прыгает. Точно хорошо всё воткнули?

У меня нет ZTE особенно кастомизировано под РТ, запросто там может быть какой-нить ТР при включении на нём сразу конфигурит PPPOE там или ещё чего. Об этом мне увы не ведомо. Жаль если так, тады только свитчик у кого-нить погонять взять на время до выяснения.

сейчас еще раз через свич-ZTE попробую, но когда подключал через этот свич сразу кабель к ноуту, то инет был и не стал трогать его- резетовать

к тому же я его TR-069 внутрях отключил и сам PPPOE на РТ настраивал

PurePPPOE поставил сейчас

 

На ноуте то PPPOE настраивали и сразу был? =) Просто если сразу был то PPPOE там сверху поднялся на ZTE.

Там же у них и autoprovision и тры которые по факту не отрубаются бывают. Был бы под рукой - глянул бы, но увы.

100% вариант переключить ZTE в режим точки доступа. Но его там может и не быть вовсе.

Цитата: sfstudio от 17/08/2020, 22:58

На ноуте то PPPOE настраивали и сразу был? =) Просто если сразу был то PPPOE там сверху поднялся на ZTE.

Там же у них и autoprovision и тры которые по факту не отрубаются бывают. Был бы под рукой - глянул бы, но увы.

100% вариант переключить ZTE в режим точки доступа. Но его там может и не быть вовсе.

на ноуте инет появляется после запуска ярлыка с PPPOE

без ярлыка с PPPOE на ZTE- свич нет инета

про точку доступа сейчас посмотрю

а пока посмотрите лог при ZTE-свич - наш "больной"- и профиль DNS установил в GoogleDNS

что за IP -адрес непонятный такой, которого вроде не должно быть в строке 129 лога:

Aug 17 23:04:01 zcip: config eth3 169.254.151.174
Aug 17 23:04:01 global: Add ip adress 169.254.151.174/32 to interface eth3 and interface up.

И вопрос: Зачем нам мучения эти, нельзя ли в ядре прописать, чтобы он не отвлекался, как вы говорите на реконнекты линка WAN?

так работал же мой ZTE и не отключал инет (и в последний раз - никогда) и несколько Zyxel-ей было и  Dlink был на этом же РТ

 

 

 

 

 

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..
  1. это затычка, нужна для корректного прохождения мультикаста в схеме PurePPPOE
  2. какие мучения опять, я уже просил перестать фантазировать? Вот давайте ещё раз попрошу.
  3. что там смотреть? Он снят ещё до того как что-то там можно увидеть. Только pppd запустился на том лог закончился.

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

 

Цитата: sfstudio от 18/08/2020, 11:41

какие мучения опять, я уже просил перестать фантазировать? Вот давайте ещё раз попрошу.

Фантазии появляются когда нет достаточно информации по сути.

в моем случае действительно мои мучения походов больше недели с момента приобретения к кнопке питания для перезагрузки FT-AIR-DUO-G, чтобы снова появился интернет. Ну не было до FT-AIR-DUO-G пропаданий интернета через ZTE.

Цитата: sfstudio от 18/08/2020, 11:41

Либо сдайте железку по гарантии

Какая последовательность возврата? Так у них получится, что он работать будет. Как вернуть работающий девайс?

Цитата: sfstudio от 18/08/2020, 11:41

Либо возьмите на время у кого-нить свитч на погонять самый дешовый и проверьте.

Да, взял в аренду работающий Zyxel Keenetic Giga II (черный).

-вернул к заводским настройкам;

-перевел в режим свича, как подсказано выше;

-подключил кабель от него к ноуту, нет интернета;

-запустил ярлык VPN подключения на ноуте - есть интернет (это я проверил, что как свич он работает);

-далее от свича подал кабель на WAN порт FT-AIR-DUO-G- есть интернет

а вот далее как будем проверять, каковы будут Ваши инструкции

Может Reset применить к FT-AIR-DUO-G, для начала и чистоты эксперимента, а то какие-то настройки уже совершали в нем?

Так стоп. Что значит может Reset? Дык не может, а обязательно после покупки и первого обновления. И вообще перед настройкой обрезетить обязательно! Сколько раз писал об этом. Именно что бы точно и новые дефолты подгрузились и исключить что на presale кто-то там чего крутанул.

Зачем было брать гиги в аренду если можно взять любой самый дешовый коммутатор я тоже не понял И не могу даже представить что сказать на "есть/нету". Линк-то есть вообще между устройствами? В статусе портов что отбражается?

По процедуре возврата это к дистрибьютору. Мы к продажам отношения не имеем, и как следствие к гарантийным процедурам тоже. Наша задача разработать АПК, запустить серию и решать проблемы по софту (причём даже не по вопросам конфигурации, а багрепортам и даже не напрямую, напрямую работа это наша добрая воля для ускорения процесса).

Можно написать коллегам на support@wi-fi.ru со ссылкой на эту тему, ни подскажут. Я не в курсе по процедурам.

 

Ну не было до FT-AIR-DUO-G пропаданий интернета через ZTE.

К сожалению мне тут сказать, кроме сказанного выше, не чего.

Да, применил Reset

пока забил только VPN на РТ, пока не настроил "воздух", подключил кабель к FT-AIR-DUO-G

интернет-есть, т.е. пинги на сайты интернета идут с "вебморды" и с коммандной строки, по кабелю от FT-AIR-DUO-G сайты открываются

новая версия ПО появилась (2.8.3.RU.18082020), будем обновлять или тест продолжим на версии 2.7.15.RU.11082020?

Какие действия будут?

 

Цитата: sfstudio от 17/08/2020, 22:25

тады только свитчик у кого-нить погонять взять на время до выяснения.

вот он красавчик -Zyxel Keenetic Giga II(подключен в режима свича, на приложенном фото), а не FT-AIR-DUO-G, которому помогает выжить красавчик Giga в моих суровых условиях.

Два дня с Giga, полет нормальный- оставлю пока в таком режиме, да и народ просит беспрепятственного внешнего мира (могу вернуться к тесту только к концу следующей недели (буду в дальней командировке))

Цитата: sfstudio от 17/08/2020, 17:54

... свитч в MT7621 достаточно чувствителен к длине и качеству (скрутки, сопли, окисел в коннекторах) оного (как впрочем и другие интегрированные в SOC современные свитчи в отличии от старых).

... тыкнуть свитч дешовый в разрыв кабеля провайдера, желательно вместо скрутки или каких-нить там бочёнков (если есть), дешовые свитчи на древних риалтэках гораздо менее к этому чувствительны

Может Вам стоит подумать о программном загрублении чувствительности FT-AIR-DUO-G на WAN, старые устройства сами говорите -менее к этому чувствительны

 

Цитата: sfstudio от 17/08/2020, 19:31

... Ибо с РТ добиться что бы они в момент появления проблемы посмотрели хотя бы на домовом свитче что там с линком это без шансов.

И как к ним подъехать, сказать что у меня крутой FT-AIR-DUO-G и чует ваши сопли в виде скруток?

 

Цитата: sfstudio от 17/08/2020, 20:36

... процессорное время на шифрование трафика НЕ ТРАТИТЬСЯ.  Никто на CPU ничего нынче не шифрует в 802.11 (лет 12 как)

Снова Вы разрушили миф в которого многие верили :)

Поиск в пучине интернета ничего не прояснил по этому поводу...

Может "пошлете" нас на ту(или те) ссылки по поводу?

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..
  1. ну значит я был прав по поводу физики в который раз, раз помогло
  2. не чего там загрублять, я вообще (на правах ванги) думаю что так с новыми встроенными в SOC такие вещи всплыли благодаря зелёным, ибо там каждый миллампер потребления нынче экономят. Т.е. всё настолько подгоняется по уровням и т.д. что бы вот только только в стандарт вписаться и лишний миллиампер не потребить. В итоге относительно старого железа и/или даже трансиверов на сетевухах на длинных и фиговых линиях имеем что имеем. Ничего софтово или даже аппаратно тут не придумать.
  3. какие ещё ссылки? Ну сравните сами загрузку cpu с и без шифрования и всё. AES на таких скоростях никакой CPU современный в роутер встроенный не осилит. Более того в 7615 свой не кислый ARM  процик и отдельно ещё специализированный BBP и криптоблок. Он вообще почти всё что можно считает сам (full mac offload чип однако). CPU общего назначения, в роутерах, для операций шифрования не задействуется, ибо просто не вывезет ни в каком виде.

Купите дешовый свитч на каком-нить RTL8305 стареньком за 300р. Ткните его в разрыв кабеля на вводе в квартиру. Будет буфером и "репиттером" между вами и ISP.

Как пинать РТ что бы кабель переложили? Ну это индивидуально. =) Не буду давать советы заниматься вредительством. =)

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: