Илдар

Надо бы отследить, куда стучится смартфон. Хотя бы, какие адреса он пытается резолвить. Зачем это нужно: весь трафик идёт через впн. Но некоторые сервера (например, мобильного приложения кинопоиска) недоступны через впн, поэтому надо бы получить список серверов, к которым тел пытается достучаться, чтобы для них пустить трафик напрямую. На компе просто, в хроме в панели разработчика всё видно, а под андроид даж не знаю как.

Похоже что инструкция в точности для моего случая. Сделал в точности как в инструкции. Однако не заработало. Что произошло: кинетик коннектится к чердаку , получает от чердака адрес 192.168.1.33, админка его доступна по этому адресу, комп через старый кинетик получает адрес 192.168.1.54, однако с компа кроме как админка старого кинетика больше ничего не доступно. Похоже что старый кинетик также не получает инета как и раньше.

Прокомментирую. Да, это очень старый белый кинетик, скорее всего 2.04 последняя для него. Разумеется на старом кинетике настроена локалка не 192.168.1, а 192.168.2 DNS я прописал от безысходности, ибо не получается никак.

Привет. Непонятно почему не получается такая простая вещь. Новый кинетик на чердаке раздаёт вайфай, всё нормально с ним. Старый кинетик (NDMS v2.04) должен получать инет по вайфай и раздавать по проводу. На старом кинетике вроде как успешно подключено к вайфай нового, вот что в мониторе: Почему старый кинетик пишет, что нормально получает доступ в инет по вайфай, но при этом ни раздаёт интернет по сети, ни даже сам не может подключиться к хранилищу обновлений для проверки? Что надо сделать чтобы работало? Вот настройки подкючения к вайфай: Вот что по нслукап показывает:

Я не разберусь, т.к. профессионально далёк от этой области. Мне проще использовать другие устройства без OPKG, на которых нет такой проблемы.

Т.к. автообновление роутера до версии 3.1.10 привело к его неработоспособности, то был сброс настроек и всё было установлено заново с нуля. Список установленных пакетов:

Можно считать так, а можно проверить. В том посте приложен простейший тестовый скрипт на PHP. Простейший коннект к сайту не должен генерировать ошибку. У меня генерирует. Если у вас отработает корректно (в конфигурации по-умолчанию без подкручивания опций SSL под эти сайты, что есть очень корявый workaround, не приводящий к итоговому решению ), тогда действительно что-то у меня не так. У меня на двух разных устройствах на OPKG ошибка возникает, на двух других устройствах с нативным PHP проблемы нет.

Прошу прощения, вы уже видели основную тему по проблеме, вот она:

Спасибо. Так и поступил. Поставил OPKG на QNAP NAS. Там точно такая же проблема. Попробовал использовать встроенный в поставку этого же NAS PHP 7.3.7 (/mnt/ext/opt/apache/bin/php) - всё отлично работает, проблемы нет. Придётся использовать NAS. Вывод - я разобрался с проблемой, в OPKG кривая версия PHP либо криво собрана

а то я жду, когда вы перекомпилируете-обновите версию PHP 7.2.22 правильно либо до последней версии. либо нужно где-то на гитхабе самому мониторить или подписаться?

На самом деле проблема не решилась, так как для других сайтов и способов доступа опять возникают эта и подобные ошибки: OpenSSL Error messages: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure Жду пересборку последней версии PHP с корректными хидерами и версией OpenSSL. С этой версией PHP невозможна нормальная работа с интернетом.

невероятно, круто. всё работает, телеграмы и рутрекеры, быстро, и бесплатно.

v6 было добавлено по статье https://help.keenetic.com/hc/ru/articles/213968529-Настройка-туннельного-подключения-IPv6-6to4 , чтобы обойти все эти приевшиеся уже роскомнадзоры. После удаления IPv6 DNS и туннеля, похоже что проблема пропала, теперь резолвится моментально, с первого раза и без ошибок. Тогда вопрос, как же добавить эти v6 интерфейс и DNS так, чтобы это не ломало резолв? т.е. похоже что нужно чтобы первым DNS брался 8.8.8.8 по-умолчанию, а не IPv6? как настроить ПОРЯДОК выборки DNS?

Не, из предыдущего поста и из информации ниже следует, что проблема вовсе не в пинге, он стабилен. Проблема в первичном резолве имени - он неудачен. Повторный резолв этого же имени удачен. Смотрите: