slomblobov

Данный компонент больше не поддерживается. Как у в вашем окружении показывает себя TSMB?

Посмотрел ваш селфтест. Сам модем на протяжении 6 минут возвращает RSSI -89dBm. RSRP тоже не меняется. Лишь RSRQ и SINR немного изменяются. ndm: Network::Interface::WebCaller::Huawei: "CdcEthernet0": node: 'rsrq', value: '-11dB'. ndm: Network::Interface::WebCaller::Huawei: "CdcEthernet0": node: 'rsrp', value: '-105dBm'. ndm: Network::Interface::WebCaller::Huawei: "CdcEthernet0": node: 'rssi', value: '-89dBm'. ndm: Network::Interface::WebCaller::Huawei: "CdcEthernet0": node: 'sinr', value: '14dB'.

Необходимые изменения будут перенесены.

@alfonder прошу переснять дамп на актуальной версии + поставить при захвате трафика наибольшее возможное maximum packet size, чтобы пакеты не обрезались.

Вероятно в соответствующем драйвере нет поддержки вашего модема. Кстати что за модем?

Хорошо, считаем, что обосновали необходимость. Сделаем команду "mdns reflector", которая будет призвана форсировать задание параметра, независимо от isolate-private

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

Проверил работу команды isolate-private, странностей не нашел. Если установлена(в дефолтном конфиге установлена), то enable-reflector=no, иначе enable-reflector=yes. В 2.16 данный функционал отсутствует, но его несложно добавить.

1. содержимое главной страницы вызывает жаркие споры. Кому-то достаточно силы сигнала в палках, кому-то подавай весь спектр параметров. Скорее всего одного вашего пожелания не будет достаточно, чтобы изменить ситацию прямо сейчас, но ваш голос будет учтён; 2. для диагностики rssi нужно собрать данные. Для этого включите отладку на интерфейсе interface CdcEthernet0 debug и спустя некоторое время снимите селфтест.

Посмотрел селфтест, можно отключить dhcp клиент на dsl соединении. Может лог почище станет и будет виднее проблему. interface Adsl0/Pvc0 no ip address dhcp @Rbuha 2.16 пробовали?

В новой версии появится возможность прописывать в опциях 121 и 249 дефолтный маршрут. Для этого разрешено указывать "0.0.0.0/0". Например: ip dhcp pool _WEBADMIN option 121 0.0.0.0/0,192.168.2.1,192.168.3.1/24,192.168.2.10

@kodirovshchik ошибке tgt_transport_fill_network_ifinfo посвящена эта тема. Ошибка проявляется только в 2.16, что несколько ухудшает прогнозы по скорости починки. Если есть рецепт быстрого воспроизведения, то это сильно приблизит исправление.

Во встроенном DHCP сервере зависимости можно прописать только по опции 60. По опции 93 зависимостей нет. Реализовать вышеприведенный конфиг не получится.

На данный момент внесены все изменения в прошивку согласно доступным спецификациям QMI. Но не все прошивки поддерживают расширение стандарта QMI, которое позволяет отображать более двух несущих. Подразумеваю, что для модемов будут выходить обновления и необходимые данные смогут быть считаны.

А мне бы как хотелось...

Без более подробного описания, селфтеста и дампа трафика никаких исправлений не последует.

Ваша идея понятна, но реализовать её весьма сложно по ряду причин. И самая вероятная из них состоит в том, что мы пока не готовы к смене концепции. Анонимный доступ уже сам по себе весьма коряво работает в протоколе SMB. К тому же разные клиенты имеют разную реализацию, где-то "GUEST", где-то пользователь без имени. Но большинство клиентов ломится с именами учетной записи ОС. И все указанные пользователи должны получать полный доступ если сервер настроен в режиме анонимного доступа. Сделано это для пользователей, которые в своей домашней сети не хотят заморачиваться с паролями. Далее мы сталкиваемся с проблемой, как пускать существующих пользователей, если разрешен анонимный доступ. Допустим у нас есть пользователь "admin". Какой-нибудь "admin1" будет ходить на сервер без проблем, но для пользователя "admin" будет обязательным ввод правильного пароля. Выглядит просто, но на практике это постоянные грабли.

Нужны дампы, селфтесты. По тексту непонятно что конкретно не получилось. 1) сервер не получает запросы? 2) сервер получает неверные запросы? 3) клиент не получает ответ от сервера?

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

В селфтесте 3 рестарта DHCP, вызванные отправкой сигнала SIGTERM, первые два связаны с посылкой команды dhcp client debug. Третий рестарт произошел по неизвестной причине: Срабатывает какой-то триггер и ndm перезапускает DHCP. Это может быть связано с изменением линка, настроек устройства. Пока сделаю следующее: не перезапускать DHCP если состояние debug не изменилось.

Проверил, действительно необходима такая доработка. Создал тикет, сделаем...

Плохо, что очистили сообщения. При наполнении хранилища проблема вернётся:(

Посмотрите здесь.

Сброс не поможет. Проблема на уровне обмена данными. Вероятно уперлись во внутренние лимиты. Потребуется коррекция со стороны прошивки. @Kisel39 вам тестовую прошивку пришлю позже.

Это внутренний признак, он используется для отладки, но смысл он имеет. Признак global означает, что префикс маршрутизируем в глобальной сети. В частности он принадлежит интерфейсу(ISP), который имеет действующий шлюз.