vst

@alex2342 Проблема известная, мы работаем над её испарвлением. @krass обычно проще перезапустить упавшее приложение, чем писать повсюду обработчики. Однако для tsmb и это не поможет, так как приложение состоит из userspace и kernelspace. Если ядерный модуль содержит баг, то перезапуск приложения не восстанавливает работоспособность.

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

KN-2210, KN-2310, EM7455, EP06, EM06, T77W676, T77W968. На внешние модемы требуется переходник, от качества которого зависит качество связи. Дешевый переходник не будет давать достаточно тока для высокой категории LTE

Нашел опечатку. Дебажные сообщения исчезнут. На работу модемов это не повлияет.

Тогда наши полномочия всё. Интересно, можно ли этот модем перевести в qmi... А лучше продать его и купить qmi модем, у которого будут всякие крутилки и свистелки.

Проблема известна. SYS-394. Помогает включение неразборчивого режима(promisc) на интерфейсе. Как раз захват пакетов его включает. Исправление последует.

Код ошибки означает, что запрашиваемые данные временно недоступны. Это не является проблемой. Странно, что у вас возникают подобные сообщения, обычно они скрыты в не debug режиме.

Для ZTE мы не добавляли считывание подобных параметров. Посмотрите в Web модема. Там есть эти сведения?

Перенес патч из новых веток в 2.16. Должно заработать. Остаётся ждать выпуска новой версии. NDM-1083

Новая прошивка может влиять на это. Перешив обратно не поможет. Пользуйтесь соотвествующими тарифами.

Да, вы правы. Разбираюсь...

(config)> sh ver release: 3.07.B.3.0-0 sandbox: draft title: 3.7 Beta 3 arch: mips hw_id: ku_rd (config)> tools ping6 fast.com count 5 sending ICMPv6 ECHO request to fast.com... PING fast.com (2a02:26f0:e2:785::24fe) 56 (104) bytes of data. 64 bytes from fast.com (2a02:26f0:e2:785::24fe): icmp_req=1, ttl=56, time=44.63 ms. 64 bytes from fast.com (2a02:26f0:e2:785::24fe): icmp_req=2, ttl=56, time=44.90 ms. 64 bytes from fast.com (2a02:26f0:e2:785::24fe): icmp_req=3, ttl=56, time=43.27 ms. 64 bytes from fast.com (2a02:26f0:e2:785::24fe): icmp_req=4, ttl=56, time=42.97 ms. 64 bytes from fast.com (2a02:26f0:e2:785::24fe): icmp_req=5, ttl=56, time=43.00 ms. --- fast.com ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss, 0 duplicate(s), time 4044.87 ms. Round-trip min/avg/max = 42.97/43.75/44.90 ms. (config)> tools ping6 sprint.net count 5 sending ICMPv6 ECHO request to sprint.net... PING sprint.net (2600::) 56 (104) bytes of data. 64 bytes from sprint.net (2600::): icmp_req=1, ttl=51, time=138.08 ms. 64 bytes from sprint.net (2600::): icmp_req=2, ttl=51, time=144.48 ms. 64 bytes from sprint.net (2600::): icmp_req=3, ttl=51, time=138.08 ms. 64 bytes from sprint.net (2600::): icmp_req=4, ttl=51, time=143.47 ms. 64 bytes from sprint.net (2600::): icmp_req=5, ttl=51, time=147.13 ms. --- sprint.net ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss, 0 duplicate(s), time 4149.71 ms. Round-trip min/avg/max = 138.08/142.24/147.13 ms. Не получилось воспроизвести. Подключение 6in4 ipv4market.

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

Есть тикет NDM-1840 по данной проблеме. Обязательно исправим.

@diqipibскиньте селф, соберу вам кастомную прошивку для проверки

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

Давайте включим "interface CdcEthernet0 debug" и посмотрим логи.

Были исправления в более поздних версиях. У вас в списке устойств множество роутеров. Есть возможность проверить вашу модель модема с устройством на актуальной версии 3.7+?

В ядре отключено CONFIG_IPV6_MULTIPLE_TABLES. Рассмотрим возможность включения.

Да, го пробовать.

@Makson53 предоставленный селф не содержит проблем. Лучше обращайтесь в техподдержку, если не уверены в своих силах. Там специально обученные люди вам помогут.

ТС прислал скриншоты лога скрытыми сообщениями. @Makson53 так дело не пойдёт. Либо выкладываете нормальный лог, либо обращайтесь в техподдержку.

Не надо ничего обновлять. Может вы поделитесь лучше какими-то данными, которые подволят диагностировать проблему? Например логи покажете в момент воспроизведения проблемы? Было бы неплохо предварительно включить отладку на интерфейсе "interface CdcEthernet0 debug". Так же скрытым сообщением нужно приложить селфтест.

Нужно убрать отображение ipv6 маршрутов из dashboard. Вместо маршрута по умолчанию впоследствие сделаем отображение шлюза.

Идея классная, однако многие пользователи не снимают наклейку.