Илдар
-
Posts
96 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by Илдар
-
-
верное направление dns-over-tls.
у меня почему-то (из-за провайдера?) клаудфлейрные IP не пинговались похоже или как-то недоступны были. В техподдержке посоветовали добавить в список ещё гугловые, антивирусные и ещё какие-то согласно их статье. Сразу заработало.
-
1. обновиться невозможно, т.к. роутер не может достучаться до сервера обновлений
2. по ssh такая же проблема:
~ # opkg update
Downloading http://bin.entware.net/mipselsf-k3.4/Packages.gz
wget: bad address 'bin.entware.net'
*** Failed to download the package list from http://bin.entware.net/mipselsf-k3.4/Packages.gzхотя если проверить адрес http://bin.entware.net с компа (который берёт инет через вайфай с этого же роутера), то сервер доступен.
вот ещё для примера:
~ # ping ya.ru
ping: bad address 'ya.ru'
~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=112 time=15.672 ms
64 bytes from 8.8.8.8: seq=1 ttl=112 time=15.417 ms
64 bytes from 8.8.8.8: seq=2 ttl=112 time=15.436 ms
64 bytes from 8.8.8.8: seq=3 ttl=112 time=15.535 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 15.417/15.515/15.672 ms
~ # nslookup ya.ru
Server: 127.0.0.1
Address 1: 127.0.0.1 localhostnslookup: can't resolve 'ya.ru': Temporary failure in name resolution
~ # nslookup yandex.ru
Server: 127.0.0.1
Address 1: 127.0.0.1 localhostnslookup: can't resolve 'yandex.ru': Temporary failure in name resolution
~ #
-
ошибка в моём случае возникает через две-три недели.
Пока она возникла, появилась новая альфа. Поддержка потребовала поставить последнюю альфу.
Видимо так и будет продолжаться
Пока буду ждать ошибку, ещё появится альфа.
-
создал Запрос #506151
-
1
-
-
ночью отвалилось, теперь не пускает, пароли не подходят.
Что нужно предоставить?
-
а я поставил последнюю альфу и что-то тоже похоже перестало отваливаться,
больше двух недель уже.
-
1
-
-
Подтверждаю проблему на версии 3.5 Giga 1010
Что-то около 1-2 недель работает доступ.
Далее NAS на linux начинает ругаться, что ночью дамп скинуть на диск в роутере он не смог.
С винды зайти на \\192.168.1.1 также не получается - пароль не принимается.
После отключения smb слайдером в админке и повторного включения, пароль принимается, заходит.
Раньше такой проблемы не было.
Поставил последнюю альфу, буду ждать повторения.
Кто-нибудь из ответственных, напишите алгоритм, что сделать, что предоставить и кому, когда проблема повторится?
-
5 часов назад, AndreBA сказал:
Похоже что инструкция в точности для моего случая.
Сделал в точности как в инструкции.
Однако не заработало.
Что произошло: кинетик коннектится к чердаку
, получает от чердака адрес 192.168.1.33, админка его доступна по этому адресу, комп через старый кинетик получает адрес 192.168.1.54, однако с компа кроме как админка старого кинетика больше ничего не доступно. Похоже что старый кинетик также не получает инета как и раньше.
-
Прокомментирую.
Да, это очень старый белый кинетик, скорее всего 2.04 последняя для него.
Разумеется на старом кинетике настроена локалка не 192.168.1, а 192.168.2
DNS я прописал от безысходности, ибо не получается никак.
-
Привет.
Непонятно почему не получается такая простая вещь.
Новый кинетик на чердаке раздаёт вайфай, всё нормально с ним.
Старый кинетик (NDMS v2.04) должен получать инет по вайфай и раздавать по проводу.
На старом кинетике вроде как успешно подключено к вайфай нового, вот что в мониторе:
Почему старый кинетик пишет, что нормально получает доступ в инет по вайфай, но при этом ни раздаёт интернет по сети, ни даже сам не может подключиться к хранилищу обновлений для проверки?
Что надо сделать чтобы работало?
Вот настройки подкючения к вайфай:
Вот что по нслукап показывает:
-
Я не разберусь, т.к. профессионально далёк от этой области.
Мне проще использовать другие устройства без OPKG, на которых нет такой проблемы.
-
Цитата
Zyxmon:
Если хотите продолжать, то продолжайте в той теме, где начали. Приведите список установленных пакетов, укажите обновлялись ли пакеты (при обновлениях бывают ошибки, способы решения которых известны).
Приводите информацию, конфиги, а не домыслы.
Т.к. автообновление роутера до версии 3.1.10 привело к его неработоспособности, то был сброс настроек и всё было установлено заново с нуля.
Список установленных пакетов:
Скрытый текст~ # opkg list-installed
busybox - 1.31.0-1
ca-bundle - 20190110-1
coreutils - 8.30-2
coreutils-groups - 8.30-2
cron - 4.1-3
curl - 7.66.0-1
dropbear - 2019.78-2
entware-release - 1.0-2
etherwake - 1.09-5
findutils - 4.6.0-4
git - 2.22.0-1
git-http - 2.22.0-1
grep - 3.3-1
ldconfig - 2.27-8
libatomic - 7.4.0-8
libbz2 - 1.0.8-1
libc - 2.27-8
libcurl - 7.66.0-1
libdb47 - 4.7.25.4.NC-5
libexpat - 2.2.7-1
libffi - 3.2.1-3
libgcc - 7.4.0-8
libgdbm - 1.18.1-1
libgmp - 6.1.2-2
libgnutls - 3.6.9-2
libintl-full - 0.19.8.1-2
liblzma - 5.2.4-5
libncurses - 6.1-5
libncursesw - 6.1-5
libndm - 1.1.10-1a
libnettle - 3.5.1-1
libopenssl - 1.1.1d-1
libopenssl-conf - 1.1.1d-1
libpcre - 8.43-1
libpthread - 2.27-8
librt - 2.27-8
libsqlite3 - 3290000-1
libssp - 7.4.0-8
libstdcpp - 7.4.0-8
libtirpc - 1.1.4-2
libuuid - 2.34-1
libxml2 - 2.9.9-2
lighttpd - 1.4.54-1
lighttpd-mod-access - 1.4.54-1
lighttpd-mod-accesslog - 1.4.54-1
lighttpd-mod-alias - 1.4.54-1
lighttpd-mod-auth - 1.4.54-1
lighttpd-mod-authn_file - 1.4.54-1
lighttpd-mod-fastcgi - 1.4.54-1
locales - 2.27-8
msmtp - 1.8.5-2
ndmq - 1.0.2-5a
openssl-util - 1.1.1d-1
opkg - 2019-06-14-dcbc142e-1
opt-ndmsv2 - 1.0-12
perl - 5.28.1-2
perl-image-exiftool - 11.65+perl5.28-1
perlbase-base - 5.28.1-2
perlbase-bytes - 5.28.1-2
perlbase-class - 5.28.1-2
perlbase-config - 5.28.1-2
perlbase-cwd - 5.28.1-2
perlbase-dynaloader - 5.28.1-2
perlbase-encode - 5.28.1-2
perlbase-errno - 5.28.1-2
perlbase-essential - 5.28.1-2
perlbase-fcntl - 5.28.1-2
perlbase-file - 5.28.1-2
perlbase-filehandle - 5.28.1-2
perlbase-i18n - 5.28.1-2
perlbase-integer - 5.28.1-2
perlbase-io - 5.28.1-2
perlbase-list - 5.28.1-2
perlbase-locale - 5.28.1-2
perlbase-mime - 5.28.1-2
perlbase-params - 5.28.1-2
perlbase-posix - 5.28.1-2
perlbase-re - 5.28.1-2
perlbase-scalar - 5.28.1-2
perlbase-selectsaver - 5.28.1-2
perlbase-socket - 5.28.1-2
perlbase-symbol - 5.28.1-2
perlbase-tie - 5.28.1-2
perlbase-time - 5.28.1-2
perlbase-unicore - 5.28.1-2
perlbase-utf8 - 5.28.1-2
perlbase-xsloader - 5.28.1-2
php7 - 7.2.22-1
php7-cgi - 7.2.22-1
php7-cli - 7.2.22-1
php7-fpm - 7.2.22-1
php7-mod-ctype - 7.2.22-1
php7-mod-curl - 7.2.22-1
php7-mod-dom - 7.2.22-1
php7-mod-exif - 7.2.22-1
php7-mod-fileinfo - 7.2.22-1
php7-mod-gmp - 7.2.22-1
php7-mod-hash - 7.2.22-1
php7-mod-json - 7.2.22-1
php7-mod-mbstring - 7.2.22-1
php7-mod-openssl - 7.2.22-1
php7-mod-pdo - 7.2.22-1
php7-mod-pdo-sqlite - 7.2.22-1
php7-mod-phar - 7.2.22-1
php7-mod-sqlite3 - 7.2.22-1
php7-mod-tokenizer - 7.2.22-1
php7-mod-xml - 7.2.22-1
php7-mod-xmlwriter - 7.2.22-1
php7-mod-zip - 7.2.22-1
poorbox - 1.31.0-1
python3 - 3.7.4-2
python3-asyncio - 3.7.4-2
python3-base - 3.7.4-2
python3-cgi - 3.7.4-2
python3-cgitb - 3.7.4-2
python3-codecs - 3.7.4-2
python3-ctypes - 3.7.4-2
python3-dbm - 3.7.4-2
python3-decimal - 3.7.4-2
python3-distutils - 3.7.4-2
python3-email - 3.7.4-2
python3-gdbm - 3.7.4-2
python3-light - 3.7.4-2
python3-logging - 3.7.4-2
python3-lzma - 3.7.4-2
python3-multiprocessing - 3.7.4-2
python3-ncurses - 3.7.4-2
python3-openssl - 3.7.4-2
python3-pydoc - 3.7.4-2
python3-sqlite3 - 3.7.4-2
python3-unittest - 3.7.4-2
python3-urllib - 3.7.4-2
python3-xml - 3.7.4-2
terminfo - 6.1-5
zlib - 1.2.11-3
zoneinfo-asia - 2019c-1
zoneinfo-europe - 2019c-1
~ #
-
8 минут назад, zyxmon сказал:
Пока же будем считать, что Вы репозиторий используете неправильно....
Можно считать так, а можно проверить.
В том посте приложен простейший тестовый скрипт на PHP.
Простейший коннект к сайту не должен генерировать ошибку.
У меня генерирует. Если у вас отработает корректно (в конфигурации по-умолчанию без подкручивания опций SSL под эти сайты, что есть очень корявый workaround, не приводящий к итоговому решению ), тогда действительно что-то у меня не так.
У меня на двух разных устройствах на OPKG ошибка возникает, на двух других устройствах с нативным PHP проблемы нет.
-
50 минут назад, zyxmon сказал:
Вы очень информативны. Очень четко описали проблему ))))
Прошу прощения, вы уже видели основную тему по проблеме, вот она:
-
В 06.11.2019 в 10:39, Александр Рыжов сказал:
Вместо ожидания лучше начать постепенно разбираться в происходящем.
Спасибо. Так и поступил.
Поставил 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 невозможна нормальная работа с интернетом.
-
невероятно, круто.
всё работает, телеграмы и рутрекеры, быстро, и бесплатно.
-
1
-
-
16 часов назад, rustrict сказал:
А v6-адреса из этого списка к вам прилетают от провайдера?
v6 было добавлено по статье https://help.keenetic.com/hc/ru/articles/213968529-Настройка-туннельного-подключения-IPv6-6to4
, чтобы обойти все эти приевшиеся уже роскомнадзоры.
После удаления IPv6 DNS и туннеля, похоже что проблема пропала, теперь резолвится моментально, с первого раза и без ошибок.
Тогда вопрос, как же добавить эти v6 интерфейс и DNS так, чтобы это не ломало резолв?
т.е. похоже что нужно чтобы первым DNS брался 8.8.8.8 по-умолчанию, а не IPv6?
как настроить ПОРЯДОК выборки DNS?
-
-
2 минуты назад, keenet07 сказал:
Это очень маленький промежуток времени. Попробуйте запустить пинг и одновременно резолвить какие-нибудь адреса. До первой ошибки. А потом проверьте не было ли в этот момент провала пинга.
Не, из предыдущего поста и из информации ниже следует, что проблема вовсе не в пинге, он стабилен.
Проблема в первичном резолве имени - он неудачен. Повторный резолв этого же имени удачен.
Смотрите:
Цитата~ # ping stroyka.ru
ping: bad address 'stroyka.ru'
~ # ping stroyka.ru
PING stroyka.ru (141.101.193.226): 56 data bytes
64 bytes from 141.101.193.226: seq=0 ttl=60 time=2.739 ms
64 bytes from 141.101.193.226: seq=1 ttl=60 time=2.325 ms
64 bytes from 141.101.193.226: seq=2 ttl=60 time=2.619 ms
и так далее.
провалов пинга нет, в процессе пинга резолвил в другом окне другие адреса, и там первый резолв любого адреса возвращал ошибку.
-
есть особенность: если принудительно указываю ДНС для резолва, то моментально определяет, если не указываю, то в первый раз вообще не определяет, во второй раз в большинстве случаев определяет:
Цитата/opt/share/www/tg # nslookup maman.ru 8.8.8.8
Server: 8.8.8.8
Address 1: 8.8.8.8 dns.googleName: maman.ru
Address 1: 82.98.86.167
/opt/share/www/tg # nslookup maman.ru
Server: 127.0.0.1
Address 1: 127.0.0.1 localhostnslookup: can't resolve 'maman.ru': Temporary failure in name resolution
/opt/share/www/tg # nslookup maman.ru
Server: 127.0.0.1
Address 1: 127.0.0.1 localhostName: maman.ru
Address 1: 82.98.86.167
-
похоже что нормальный пинг:
Цитата/opt/share/www/tg # ping 46.188.37.2
PING 46.188.37.2 (46.188.37.2): 56 data bytes
64 bytes from 46.188.37.2: seq=0 ttl=255 time=1.327 ms
64 bytes from 46.188.37.2: seq=1 ttl=255 time=1.124 ms
64 bytes from 46.188.37.2: seq=2 ttl=255 time=1.071 ms
64 bytes from 46.188.37.2: seq=3 ttl=255 time=1.331 ms
64 bytes from 46.188.37.2: seq=4 ttl=255 time=1.173 ms
64 bytes from 46.188.37.2: seq=5 ttl=255 time=1.341 ms
64 bytes from 46.188.37.2: seq=6 ttl=255 time=1.338 ms
64 bytes from 46.188.37.2: seq=7 ttl=255 time=1.379 ms
64 bytes from 46.188.37.2: seq=8 ttl=255 time=1.377 ms
64 bytes from 46.188.37.2: seq=9 ttl=255 time=1.311 ms
64 bytes from 46.188.37.2: seq=10 ttl=255 time=1.219 ms
^C
--- 46.188.37.2 ping statistics ---
11 packets transmitted, 11 packets received, 0% packet loss
round-trip min/avg/max = 1.071/1.271/1.379 ms
-
Кинетик толком не резолвит имена в консоли, подскажите путь, что делать, а то сложно уже работать - приложения не ставятся, т.к. не может источники разрешить, и т.п.
куда стучится и ходит смартфон?
in Обмен опытом
Posted
Надо бы отследить, куда стучится смартфон.
Хотя бы, какие адреса он пытается резолвить.
Зачем это нужно: весь трафик идёт через впн. Но некоторые сервера (например, мобильного приложения кинопоиска) недоступны через впн, поэтому надо бы получить список серверов, к которым тел пытается достучаться, чтобы для них пустить трафик напрямую. На компе просто, в хроме в панели разработчика всё видно, а под андроид даж не знаю как.