LTE module и Debian

Да, при выходе из саспенда ModemManager попустило, и он задетектил модем. При перезапуске ModemManager тоже детектит модем.

Почему он его не сдетектил на загрузке операционки, я не знаю. Наверное какие-то гонки. sysfs и devfs ещё не полностью заселились, а ModemManager уже вынюхивает, находит, и начинает команды посылать.

Закрыл крышку. Теперь открыл, модем отображается, подключается.

Это подтверждает мои предположения о том,что переключение конфигураций модема ту не причём. Виновато именно неправильное управление питанием. Этим занимается подсистема ACPI,а данные она берет из таблицы DSDT находящейся в ROM ноутбука. И увы - очень часто у ноутов эти таблицы кривые. У меня был опыт их правки,но описание процесса явно не для короткого форумного сообщения. Хотя бывает что удается обойтись без правки таблиц,просто найти в скриптах, срабатывающих при закрывании-открывании крышки и прочих действиях вызывающих «события acpi» что и как там делается с модемом(или подсистемой usb вообще). Возможно включен слишком агрессивный режим энергосбережения

Погружение в тему можно начать например отсюда: https://wiki.archlinux.org/title/Power_management_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9) И обратить внимание вот сюда: https://help.ubuntu.ru/wiki/laptop_mode#%D0%B0%D0%B2%D1%82%D0%BE%D0%BE%D1%82%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5_usb Ну и к сожалению придется очень много читать всякой документации чтобы понять как это всё работает и какими настройками можно изменить поведение.

iliyap, почему тогда банальный перезапуск ModemManager не помогает? Но если уходит в сон, а потом просыпается, то модем работает.

watchcat382, да вы правы оказались. Я немного провел експерименты:

В конфиге /etc/laptop-mode/conf.d/runtime-pm.conf (Arch Wiki говорит про замену им usb-autosuspend). Добавил в меню AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST="12d1:15c1" поставил значение AUTOSUSPEND_USE_WHITELIST=1. Далее, Arch Wiki рекомендует заменить usb-autosuspend на runtime-pm.conf по пути /lib/udev/rules.d/99-laptop-mode.rules. Но там ничего похожего не нашел:

ACTION=="change", SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_NAME}=="|AC|ACAD|ADP*", RUN+="lmt-udev auto"
ACTION=="add|remove", SUBSYSTEM=="machinecheck", RUN+="lmt-udev auto"
ACTION=="add", SUBSYSTEM=="usb", RUN+="lmt-udev force"

# Run a particular module only
#ACTION=="add", SUBSYSTEM=="usb", RUN+="lmt-udev force modules=runtime-pm devices=%k"

Проверил:

grep -r '^\(CONTROL\|ENABLE\)_' /etc/laptop-mode/conf.d
/etc/laptop-mode/conf.d/kbd-backlight.conf:CONTROL_KBDLIGHT=0
/etc/laptop-mode/conf.d/hal-polling.conf:CONTROL_HAL_POLLING="auto"
/etc/laptop-mode/conf.d/cpuhotplug.conf:CONTROL_CPU_HOTPLUG=0
/etc/laptop-mode/conf.d/wireless-ipw-power.conf:CONTROL_IPW_POWER="auto"
/etc/laptop-mode/conf.d/ac97-powersave.conf:CONTROL_AC97_POWER="auto"
/etc/laptop-mode/conf.d/terminal-blanking.conf:CONTROL_TERMINAL="auto"
/etc/laptop-mode/conf.d/wireless-iwl-power.conf:CONTROL_IWL_POWER="auto"
/etc/laptop-mode/conf.d/sched-mc-power-savings.conf:CONTROL_SCHED_MC_POWER_SAVINGS="auto"
/etc/laptop-mode/conf.d/dpms-standby.conf:CONTROL_DPMS_STANDBY="auto"
/etc/laptop-mode/conf.d/radeon-dpm.conf:CONTROL_RADEON_DPM="auto"
/etc/laptop-mode/conf.d/sched-smt-power-savings.conf:CONTROL_SCHED_SMT_POWER_SAVINGS="auto"
/etc/laptop-mode/conf.d/lcd-brightness.conf:CONTROL_BRIGHTNESS=0
/etc/laptop-mode/conf.d/nouveau.conf:CONTROL_NOUVEAU="auto"
/etc/laptop-mode/conf.d/eee-superhe.conf:CONTROL_SUPERHE="auto"
/etc/laptop-mode/conf.d/ethernet.conf:CONTROL_ETHERNET=0
/etc/laptop-mode/conf.d/intel-hda-powersave.conf:CONTROL_INTEL_HDA_POWER="auto"
/etc/laptop-mode/conf.d/runtime-pm.conf:CONTROL_RUNTIME_AUTOSUSPEND=1
/etc/laptop-mode/conf.d/start-stop-programs.conf:CONTROL_START_STOP=1
/etc/laptop-mode/conf.d/vgaswitcheroo.conf:CONTROL_VGASWITCHEROO=0
/etc/laptop-mode/conf.d/nmi-watchdog.conf:CONTROL_NMI_WATCHDOG="auto"
/etc/laptop-mode/conf.d/configuration-file-control.conf:CONTROL_CONFIG_FILES=0
/etc/laptop-mode/conf.d/cpufreq.conf:CONTROL_CPU_FREQUENCY="auto"
/etc/laptop-mode/conf.d/cpufreq.conf:CONTROL_CPU_THROTTLING=0
/etc/laptop-mode/conf.d/bluetooth.conf:CONTROL_BLUETOOTH=0
/etc/laptop-mode/conf.d/video-out.conf:CONTROL_VIDEO_OUTPUTS=0
/etc/laptop-mode/conf.d/intel_pstate.conf:CONTROL_INTEL_PSTATE="auto"
/etc/laptop-mode/conf.d/wireless-power.conf:CONTROL_WIRELESS_POWER_SAVING="auto"
/etc/laptop-mode/conf.d/pcie-aspm.conf:CONTROL_PCIE_ASPM="auto"
/etc/laptop-mode/conf.d/battery-level-polling.conf:CONTROL_BATTERY_LEVEL_POLLING=0
/etc/laptop-mode/conf.d/intel-sata-powermgmt.conf:CONTROL_INTEL_SATA_POWER="auto"
/etc/laptop-mode/conf.d/intel-sata-powermgmt.conf:CONTROL_AHCI_RUNTIME_PM=1
/etc/laptop-mode/conf.d/exec-commands.conf:CONTROL_EXEC_COMMANDS="auto"
/etc/laptop-mode/conf.d/auto-hibernate.conf:ENABLE_AUTO_HIBERNATION=0

Изменил в файле wireless-iwl-power.conf значения: CONTROL_IWL_POWER="auto" на 1 IWL_BATT_POWER=3 на 0.

Изменил в файле wireless-ipw-power.conf CONTROL_IPW_POWER="auto" на 1 IPW2100_BATT_POWER=5 на 0

Изменил wireless-power.conf CONTROL_WIRELESS_POWER_SAVING="auto" на 1 WIRELESS_BATT_POWER_SAVING=1 на 0

Тест 1: оставить ноутбук, крышка открыта, екран потух. Ноутбук не спит. Результат: модем не работает, с перезагрузками модема,тоже. Выхлоп:

systemd[1]: Starting ModemManager.service - Modem Manager...
ModemManager[5311]: <info>  ModemManager (version 1.20.4) starting in system bus...
systemd[1]: Started ModemManager.service - Modem Manager.
ModemManager[5311]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': not supported by a>
ModemManager[5311]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1f.6': not supported by any plugin
ModemManager[5311]: <info>  [device /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3] creating modem with plugin 'huawei' and '3' ports
ModemManager[5311]: <warn>  [plugin/huawei] could not grab port cdc-wdm0: Cannot add port 'usbmisc/cdc-wdm0', unhandled port type
ModemManager[5311]: <warn>  [base-manager] couldn't create modem for device '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3': Failed to find primary AT port

Тест 2: оставить ноутбук, крышка открыта, екран потух и ноутбук перешел в режим сна(?). Закрыть и открыть крышку, ноутбук запустился, проснулся. Результат: Модем виден. Выхлоп:

ModemManager[5311]: <warn>  [modem1] couldn't load UE mode of operation for EPS: No AT port available to run command
ModemManager[5311]: <warn>  [modem1] couldn't load initial EPS bearer settings: LTE attach status info is unsupported
ModemManager[5311]: <warn>  [modem1] couldn't load 5GNR registration settings: 5GNR registration settings are unsupported
ModemManager[5311]: <info>  [modem1] state changed (unknown -> disabled)
ModemManager[5311]: <info>  [modem1] state changed (disabled -> enabling)
ModemManager[5311]: <info>  [modem1] power state updated: on
ModemManager[5311]: <info>  [modem1] state changed (enabling -> enabled)
ModemManager[5311]: <info>  [modem1] 3GPP registration state changed (unknown -> registering)
ModemManager[5311]: <info>  [modem1] 3GPP registration state changed (registering -> home)
ModemManager[5311]: <info>  [modem1] state changed (enabled -> registered)

да вы правы оказались.

Стандартный ноутбучный глюк - криво написанная производителем железа таблица DSDТ. Это данные для работы линуксовой подсистемы ACPI. Неоднократно сталкивался с необходимостью вытаскивать эту таблицу из ПЗУ,править и потом подсовывать ядру при загрузке уже из отдельного файлы. Применительно к Дебиану можно почитать например отсюда https://wiki.debian.org/OverridingDSDT Можно провести эксперимент: извлечь таблицу DSDT,декомпилировать ее и попытаться скомпилировать обратно,просто скомпилировать никуда пока не используя. Фактически выполняить syntax check таким образом. И посмотреть сколько компилятор ошибок найдет. Обычно - много:( Хотя большая часть и не критичные но бывает и вот такое как с вашим модемом. А у меня также звук не просыпался. Там эта таблица вся из себя «объектная» и к устройствам применяются «методы». Так вот если метод пробуждения сломан то такой бардак и будет. Потому что если драйвер в ядре написан правильно - то будит он через вызов «метода» ACPI. И оно не будится. А виндовый драйвер соблюдением стандарта может и не заморачиваться и напрямую лезть в регистры железа. И будит. Честно говоря я оставил эту причину на самый крайний случай. Последний раз возиться пришлось лет десять назад,думал ну может производители уже перестали так косячить. Как видите - нет:( И чинить это правкой DSDT - врагу не пожелаю:(

почему тогда банальный перезапуск ModemManager не помогает?

Потому что ему некуда («не через что») к модему обратиться - порта же нет. Вот usb_modeswitch пинал модем в usb endpoint который и у спящего модема не пропадает, и похоже что это его будило. Вам повезло что действие «открыть крышку» таки вызывает успешное пробуждение модема. Надо изучить скрипт который при открытии крышки вызывается и посмотреть как он там модем пинает. После чего сделать свой небольшой скрипт с этим действием и запускать его если модема не видно. Видимо в DSDT сломан не сам метод пробуждения,иначе бы хлопание крышкой не помогало, а то место откуда он должен бы вызываться.

Пока вы не начинали особо глубоко копаться в настройках,могу предложить еще один простой тест. Удалить пакет Laptop Mode Tools и посмотреть как система будет работать без него. Поставить-то его потом обратно легко одной командой. Иногда LMT имеет слишком агрессивные настройки энергосбережения,не подходящие к конкретному железу даже если всё исправно и DSDT более-менее нормальная. Просто умолчания в ней такие. Если окажется что без LMT модем не пытается усыпать сразу после загрузки - то можно будет в DSDT не лезть,а крутить только настройки LMT.

LMT и не был установлен, когда делались ранние попытки. Пока, в качестве временного решения, запускаю sudo systemctl suspend, затем можно не закрывать/открывать крышку. А нажать клавишу Fn, подождать, включится экран, авторизоваться, и около 1-2 минут подождать и модем заработает.

Но как известно, ничто не бывает более постоянным - чем временное.

Позже, вероятно придеться ковыряться в DSDT.

watchcat382, iliyap, благодарю за уделенное время и помощь.

Если управление пробуждением модема всё-таки работает,хотя и не совсем так как надо,то может быть получится обойтись и без ковыряния в DSDT ибо дело это весьма сложное. Хорошо если ошибка окажется какой-нибудь очевидной опечаткой. Но шансов на это не много потому что в таком случае пробуждение модема не работало бы вообще. А что-то сложное переписать в DSDT - не слишком-то реально. Вот еще старая ссылка на эту тему из моей коллекции: https://init-6.bitbucket.io/content/2009/12/acpi-dsdt/ Жаль недавно,буквально пару месяцев назад, много ссылок поудалял,не думал что пригодятся если за десяток лет ни разу уже не потребовались.

Поэтому имеет смысл порыться в скриптах LMT и разобраться как именно они будят модем. В конце концов есть вот такой модуль для ядра,позволяющий принудительно вызвать какой-нибудь «метод» ACPI https://github.com/mkottman/acpi_call Главное понять какой именно. А может и без вызова этих «методов» получится обойтись, например записью в какой-нибудь хитрый файлик в /sys - их там много разных :) Ну и соответственно вставить нужное действие куда-нибудь в загрузочные скрипты или написать «юнит» для systemd. Каноническое место для таких вещей /etc/rc.local,но в Дебиане его по умолчанию нет. Но можно сделать,запуская тоже через «юнит» systemd.

Кстати, еще один простой тест придумался. С целью определить это модем при загрузке усыпает взаимодействуя только с самим ядром или же что-нибудь потом в процессе загрузки «постаралось». В самом последнем Дебиане я это не пробовал,а раньше можно было прервать загрузку в момент появления меню grub, отредактировать командную строку ядра написав в нее init=/bin/bash и загрузку запустить. Загрузится замый минимум и вылезет приглашение шелла. Как минимум команда ls /dev/ttyUSB* там доступна будет. Команды lsmod и modprobe тоже - на случай если ядро само не загрузит в этом случае «модемные» модули. А вот весь сложный механизм обычной загрузки отрабатывать не будет. Ну и станет понятно - есть модем или нет модема. Отредактированная таким образом командная строка ядра нигде не сохраняется и при следующей перезагрузке всё будет загружаться как обычно.

А имеет смысл менять права на файлы runtime_enabled для редактирования? Параметры с forbidden на enabled у всех файлов в ветках каталогов /sys/bus/usb/devices/1-3/.

А вообще, watchcat382, iliyap а так же немного anonymous, благодарю, за файлы, ссылки и практическую базу по LTE модемам и сетям. Я все законспектировал и добавил в базу знаний.

Файловая система которая в /sys - не настоящая. Поэтому при следующей загрузке снова придется менять права. А в случае usb-устройств скорее всего и при следующем переподключении.

Проведи Тест 1, только сначала запусти в одном терминале dmesg -w |tee dmesg.txt, во втором терминале udevadm monitor -k |tee uevent.txt. Когда «екран» потухнет, покажи эти dmesg.txt и uevent.txt, а также sudo journalctl -b -t ModemManager. Возможно в этих логах найдутся события об отключении или снижении питания, и станет понятно, кто инициатор. Потому что пока никаких фактов, одни предположения.

Провел тест с условием: В каталоге /etc/udev/rules.d/40-me906.rules присутствуют параметры:

SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", ATTR{idProduct}=="15c1", ATTR{bConfigurationValue}!="3", ATTR{bConfigurationValue}="3"

Выхлоп dmesg

Выхлоп udevadm

Выхлоп ModemManager:

мар 11 20:27:09 debian ModemManager[1046]: <info>  ModemManager (version 1.20.4) starting in system bus...
мар 11 20:27:12 debian ModemManager[1046]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': not supported by any plugin
мар 11 20:27:12 debian ModemManager[1046]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1f.6': not supported by any plugin
мар 11 20:27:57 debian ModemManager[1046]: <info>  [device /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3] creating modem with plugin 'huawei' and '3' ports
мар 11 20:27:57 debian ModemManager[1046]: <warn>  [plugin/huawei] could not grab port cdc-wdm0: Cannot add port 'usbmisc/cdc-wdm0', unhandled port type
мар 11 20:27:57 debian ModemManager[1046]: <warn>  [base-manager] couldn't create modem for device '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3': Failed to find primary AT port
мар 11 20:44:14 debian ModemManager[1046]: <info>  [sleep-monitor-systemd] system is about to suspend
мар 11 20:54:13 debian ModemManager[1046]: <info>  [sleep-monitor-systemd] system is resuming
мар 11 20:54:16 debian ModemManager[1046]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': not supported by any plugin
мар 11 20:54:16 debian ModemManager[1046]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1f.6': not supported by any plugin
мар 11 20:54:20 debian ModemManager[1046]: <info>  [cdc-wdm0/mbim] MBIM device is not QMI capable
мар 11 20:54:20 debian ModemManager[1046]: <info>  [device /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3] creating modem with plugin 'huawei' and '3' ports
мар 11 20:54:20 debian ModemManager[1046]: <info>  [base-manager] modem for device '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3' successfully created
мар 11 20:54:20 debian ModemManager[1046]: <info>  [modem1/cdc-wdm0/mbim] MBIM device is not QMI capable
мар 11 20:54:21 debian ModemManager[1046]: <warn>  [modem1] couldn't load carrier config: QMI PDC not supported
мар 11 20:54:21 debian ModemManager[1046]: <warn>  [modem1] couldn't load supported bands: Unsupported
мар 11 20:54:21 debian ModemManager[1046]: <warn>  [modem1] couldn't load current bands: Unsupported
мар 11 20:54:32 debian ModemManager[1046]: <warn>  [modem1] couldn't query SIM slots: Transaction timed out
мар 11 20:54:44 debian ModemManager[1046]: <info>  [modem1] state changed (unknown -> locked)
мар 11 20:54:44 debian ModemManager[1046]: <warn>  [modem1] modem couldn't be initialized: Couldn't check unlock status: SIM not inserted
мар 11 20:54:44 debian ModemManager[1046]: <info>  [modem1] state changed (locked -> failed)
мар 11 20:54:44 debian ModemManager[1046]: <warn>  [modem1] error initializing: Modem in failed state: sim-missing

pppd. Я лет десять назад настраивал. Есть инструкция в арч вики, рабочая (на тот момент времени и для того мегафоновского модема)

Про гуи можешь забыть. Придётся писать конфиг.

Edit: нашёл инструкцию: https://wiki.archlinux.org/title/Ppp/Mobile_broadband_modem

iliyap, повторил те же самые действия, но сим карта в лотке:

Выхлоп 2 dmesg

Выхлоп 2 udeadm

Выхлоп ModemManager:

мар 11 21:55:17 debian ModemManager[1040]: <info>  ModemManager (version 1.20.4) starting in system bus...
мар 11 21:55:20 debian ModemManager[1040]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': not supported by any plugin
мар 11 21:55:20 debian ModemManager[1040]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1f.6': not supported by any plugin
мар 11 21:56:04 debian ModemManager[1040]: <info>  [device /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3] creating modem with plugin 'huawei' and '3' ports
мар 11 21:56:04 debian ModemManager[1040]: <warn>  [plugin/huawei] could not grab port cdc-wdm0: Cannot add port 'usbmisc/cdc-wdm0', unhandled port type
мар 11 21:56:04 debian ModemManager[1040]: <warn>  [base-manager] couldn't create modem for device '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3': Failed to find primary AT port
мар 11 22:12:27 debian ModemManager[1040]: <info>  [sleep-monitor-systemd] system is about to suspend
мар 11 22:24:31 debian ModemManager[1040]: <info>  [sleep-monitor-systemd] system is resuming
мар 11 22:24:34 debian ModemManager[1040]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': not supported by any plugin
мар 11 22:24:34 debian ModemManager[1040]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1f.6': not supported by any plugin
мар 11 22:24:38 debian ModemManager[1040]: <info>  [cdc-wdm0/mbim] MBIM device is not QMI capable
мар 11 22:24:38 debian ModemManager[1040]: <info>  [device /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3] creating modem with plugin 'huawei' and '3' ports
мар 11 22:24:38 debian ModemManager[1040]: <info>  [base-manager] modem for device '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3' successfully created
мар 11 22:24:39 debian ModemManager[1040]: <info>  [modem1/cdc-wdm0/mbim] MBIM device is not QMI capable
мар 11 22:24:39 debian ModemManager[1040]: <warn>  [modem1] couldn't load carrier config: QMI PDC not supported
мар 11 22:24:39 debian ModemManager[1040]: <warn>  [modem1] couldn't load supported bands: Unsupported
мар 11 22:24:39 debian ModemManager[1040]: <warn>  [modem1] couldn't load current bands: Unsupported
мар 11 22:24:49 debian ModemManager[1040]: <warn>  [modem1] couldn't query SIM slots: Transaction timed out
мар 11 22:25:01 debian ModemManager[1040]: <warn>  [modem1/sim0] couldn't load list of emergency numbers: No AT port available to run command
мар 11 22:25:01 debian ModemManager[1040]: <warn>  [modem1/sim0] couldn't load list of preferred networks: No AT port available to run command
мар 11 22:25:01 debian ModemManager[1040]: <warn>  [modem1/sim0] couldn't load GID1: Failed reading GID1 from SIM card
мар 11 22:25:01 debian ModemManager[1040]: <warn>  [modem1/sim0] couldn't load GID2: Failed reading GID2 from SIM card
мар 11 22:25:11 debian ModemManager[1040]: <warn>  [modem1/sim0] couldn't load EID: Transaction timed out
мар 11 22:25:11 debian ModemManager[1040]: <warn>  [modem1] couldn't load UE mode of operation for EPS: No AT port available to run command
мар 11 22:25:11 debian ModemManager[1040]: <warn>  [modem1] couldn't load initial EPS bearer settings: LTE attach status info is unsupported
мар 11 22:25:11 debian ModemManager[1040]: <warn>  [modem1] couldn't load 5GNR registration settings: 5GNR registration settings are unsupported
мар 11 22:25:11 debian ModemManager[1040]: <info>  [modem1] state changed (unknown -> disabled)
мар 11 22:25:11 debian ModemManager[1040]: <info>  [modem1] state changed (disabled -> enabling)
мар 11 22:25:11 debian ModemManager[1040]: <info>  [modem1] power state updated: on
мар 11 22:25:12 debian ModemManager[1040]: <info>  [modem1] state changed (enabling -> enabled)
мар 11 22:25:12 debian ModemManager[1040]: <info>  [modem1] 3GPP registration state changed (unknown -> registering)
мар 11 22:25:12 debian ModemManager[1040]: <info>  [modem1] 3GPP registration state changed (registering -> home)
мар 11 22:25:12 debian ModemManager[1040]: <info>  [modem1] state changed (enabled -> registered)

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

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

А за pppd благодарю, добавлю в базу.

В логах компьютер уходит в гибернацию (suspend-to-disk, sleep state S4):

[ 1218.496866] PM: hibernation: hibernation entry
...
[ 1219.349148] ACPI: PM: Preparing to enter system sleep state S4
[ 1219.354649] ACPI: PM: Saving platform NVS memory

При возвращении из гибернации он ресетит USB устройства:

[ 1219.363829] ACPI: PM: Restoring platform NVS memory
...
[ 1219.540137] usb usb1: root hub lost power or was reset
[ 1219.846454] usb 1-3: reset high-speed USB device number 2 using xhci_hcd
[ 1219.998900] option 1-3:3.2: device disconnected
[ 1221.077685] option 1-3:3.2: GSM modem (1-port) converter detected
[ 1221.078025] usb 1-3: GSM modem (1-port) converter now attached to ttyUSB0

От этого на несколько миллисекунд отрывает порт ttyUSB0 модема:

KERNEL[1221.014185] change   /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
KERNEL[1221.014253] change   /devices/pci0000:00/0000:00:14.0/usb1/1-3 (usb)
KERNEL[1221.014300] remove   /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:3.2/ttyUSB0/tty/ttyUSB0 (tty)
KERNEL[1221.014337] unbind   /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:3.2/ttyUSB0 (usb-serial)
KERNEL[1221.014368] remove   /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:3.2/ttyUSB0 (usb-serial)
KERNEL[1221.014417] unbind   /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:3.2 (usb)
...
KERNEL[1221.059958] add      /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:3.2/ttyUSB0 (usb-serial)
KERNEL[1221.060181] add      /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:3.2/ttyUSB0/tty/ttyUSB0 (tty)
KERNEL[1221.060211] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:3.2/ttyUSB0 (usb-serial)
KERNEL[1221.060244] bind     /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:3.2 (usb)

Но ModemManager похоже обрабатывает возвраты из гибернации и сна, и восстанавливает соединение с модемом (видимо закрывает и переоткрывает ttyUSB0):

мар 11 22:24:31 debian ModemManager[1040]: <info>  [sleep-monitor-systemd] system is resuming
...
мар 11 22:24:38 debian ModemManager[1040]: <info>  [base-manager] modem for device '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3' successfully created
...
мар 11 22:25:12 debian ModemManager[1040]: <info>  [modem1] state changed (enabled -> registered)

При загрузке компьютера udev-правило меняет конифгурацию модема с #2 на #3. Но ModemManager всё равно не «видит» модем. Давай попробуем сделать ресет USB устройства, раз ресет при возврате из сна помогает.

Сначала после загрузки ноута, когда ModemManager не может сдетектить модем, попробуй выполнить команды:

echo 0 |sudo tee /sys/bus/usb/devices/1-3/authorized
echo 1 |sudo tee /sys/bus/usb/devices/1-3/authorized

Если после этого ModemManager продетектит модем, значит метод рабочий. Тогда можно попробовать автоматизировать это udev-правилами:

# disable usb device having non #3 configuration
SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", ATTR{idProduct}=="15c1", ATTR{bConfigurationValue}!="3", ATTR{authorized}=="1", ATTR{authorized}="0"

# change disables usb device configuration to #3
SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", ATTR{idProduct}=="15c1", ATTR{bConfigurationValue}!="3", ATTR{authorized}=="0",  ATTR{bConfigurationValue}="3"

# enable usb device having #3 configuration
SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", ATTR{idProduct}=="15c1", ATTR{bConfigurationValue}=="3", ATTR{authorized}=="0", ATTR{authorized}="1"

из другого треда про wayland в ответ на:

вообще, на мой взгляд, в wayland пытаются изобретать недоделанный Photon из QNX, но концептуально и до его микроархитектуры не доросли, и выходит какое-то нагромождение костылей вместо протокола и концептуальной продуманности архитектуры «графического сервера»/композитора/всего остального, то есть, того как именно это все должно взаимодействовать.

по поводу Photon и QNX 6.5 (выпилили уже из 6.6) – есть скриншоты, в том числе и на ЛОРЕ, в том числе и относительно недавние : 6.6_deprecated_photon , 6.3 2007

по устройству микроархитектуры «графического сервера» в QNX 6.5 Photon: ссылки например здесь1 и здесь2

еще похожий подход «совмещенного API» был реализован например в MicroWindows: Win32/X11/свой собственный.

вообще, мне Wayland напоминает концептуально недоделанную половину Photon, только в виде фарса или анекдота:

• вместо микроархитектуры графического сервера – непонятный протокол клиент-сервер-композитор=другие клиенты, и не работающий drag’n’drop (в Photon, например, отлично работает)

• вместо «единого пространства 3D-событий» и регионов с прозрачностью и чувствительностью, и например, потоком «фотонов» в смысле событий изменяющих области отсечения и списки отрисовки === ???? непонятно что (в итоге драг-н-дроп не работает, а скриншоты делают несколькими различными способами, лолъ)

• вместо QNX IPC для связи меж процессами для управления регионами для предоставления сервисами между приложениями — непонятно что

• вместо микроядра – не просто .so инжектируемое в процесс клиента, а монолитное непонятно что.

подозреваю, что именно с этой концептуальной «непонятно что» и связаны ряд недоделок самого wayland как протокола и объединяющей концепции.

в QNX там впрочем было микроядро, и IPC эффективно использовалось.

а в wayland опять же, непонятно что пытаются эмулировать разными реализациями плохо специфицированного протокола с несовместимыми плохо специфицированными расширениями.

в общем, у меня такое впечатление что wayland это недоделанный photon, попытка перетащить в монолитный линукс с микроядерного qnx какие-то отдельные куски без понимания мощной унифицирующей концепции, и каких-то тонкостей.

и именно поэтому – попытка неудачная.

соответственно, что делать с wayland чтобы приблизить его к X11? да для начала хотя бы просто воспроизвести примерно все то же самое что уже было и хорошо работало в Photon,MicroWindows, и т.п. примерно в тех же 1993-1995 годах или ранее.

то есть, wayland нужно не усложнять, а упрощать – приближая его концептуально к тому же Photon, PhAB и похожей его инфраструктуре что была под QNX.

жаль впрочем, что и в самом QNX 6.6 уже его списали, и не поддерживают, как и в 7.0, 8.0. и вообще состояние развития современного QNX – какое-то непонятное.

остается надеяться, что если взять например какой-нибудь L4/Geode/SculptOS, Plan9 Rio и воспроизвести эти же идеи поверх этих технологий (пускай и даже через Wayland для начала), как например в Arcan/Durden/Wayland – им можно дать второе дыхание.

Сервер так и будет один,только объединенный в один «контейнер» в формате библиотеки. Мало кто знает,что в линуксе файлы формата .so могут иметь точку входа и запускаться как обычные исполняемые файлы. При этом они продолжают быть библиотеками,способными динамически линковаться к программам. Вот этим и воспользуемся - при старте запускаем такую «библиотеку», которая создает процесс-«сервер». А программы к этому серверу обращаются посредством динамической линковки и вызова функций API. Как именно там внутри «библиотеки» будет устроено межпроцессное взаимодействие - это вопрос подлежащий обсуждению. Но уж точно не через последовательный канал-сокет. Наверно через разделяемую память и семафоры.

в Plan 9 в графических системах Rio и 8 1/2, например, графический сервер реализован через сокеты (как впрочем и файловый сервер P9FS/Styx) – не столько потому что концептуально архитектурно, сколько потому что там нет ELF-ов, а свой формат бинарников типа COFF (из-за того что например, нет C++ а свой kencc Plan9 C [68]c/[68]l/[68]a), и нет динамической линковки.

по воспоминаниям Дж.Гослинга (который знаменит не только Явой и microemacs, но и еще например, оконной системой NeWS – в которой экранный DisplayPostScript с программируемыми на Си объектами исполняемыми на сервере) —- они тоже применили сетевой сервер не столько потому что хотели сетевую прозрачность, сколько из-за того, что динамические библиотеки в то время толком не поддерживались.

так что это пережитки классического unix с COFF a.out и статической линковкой, а не какой-то глубинный элемент дизайна «графического сервера».

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

например, можно использовать какие-то служебные неблокирующиеся сокеты в основном для асинхронности и мультиплексирования, синхронизации а сообщения передавать другим способом (например в Plan9 через P9FS/Styx /dev/window/ctl - файлы с запросами в виде какого-то протокола).

содержимое окна в графическом и текстовом виде в Plan9 Rio кстати, доступно через /dev/window/NNN/text или аналогично для графической картинки.

так что это альтернативная IPC типа разделяемой памяти, семафоров, мьютексов реализация.

впрочем, P9FS/Styx тоже передаются через TCP/IP сокеты – написать «файловый сервер» (а по сути, объектный сервер каких-то ресурсов типа объекто) в Plan9 не сложнее чем написать обычный HTTP или даже проще типа SMTP сервер.

в общем, концептуально подобный Wayland протокол наверное можно и поверх P9FS/Styx Rio изобразить.

главный вопрос насчет стандартизации и полной спецификации такого протокола (примерно как в самом XWindows его X-протокол).

впрочем, в wayland все равно передают картинку – а вот насчет «глобального пространства событий» и составимости, композабельности их регионов типа прозрачности и чувствствительности — полная непонятка.

почему я и говорю, что Wayland это концептуально недоделанный Photon из QNX.

вообще, еще было бы интересно сравнить с какими-то библиотеками для графического композитинга – типа Skia или например, Nile/Gezire из проекта FONC/STEP, или чего-то типа аналогичного на расте из zed.dev.

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

ещё вот подумалось что композитинг 3D – это далеко не все что хотелось бы концептуально.

например, событие с координатами или атрибутами вида (x,y,z,t,e,r,o) где x,y-2d, z– плоскость вперед от экрана, t-время, e- код события, r-регион, o-объект.

распознается в какие-то другие охватывающие их контейнеры – другие регионы и объекты, вплоть до деревьев типа BSPtree.

сортируется по времени в похожую цепочку событий, монотонно возрастающую по времени.

сортируется по Z по «алгоритму художника» или более сложному (например, в другом порядке) со списками отсечений и списками отрисовки.

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

то есть, тут по идее хотелось бы многомерного распознавания образов через пространство признаков в таком графическом пространстве событий – не просто 2D/3D, но и 4D,5D и т.п. – через регионы и объекты и их охватывающие контейнеры.

то есть вообще-то, это например, на реализацию ООП системы диспетчеризующей в нужные объекты может быть завязано.

хотя в Photon без таких особых сложностей, QNX IPC между процессами там используется не для этого.

потратили бы на X11, у нас бы такая конфетка была …

Согласен. Можно было сохранив API полностью совсем переделать внутренности.

в этом смысле любопытно устроен API MicroWindows – который Nano-X / NanoGUI site github:

• совместимость с Win32

• совместимость с X11

• свой API

собственно, вместо изобретения непонятно зачем плохо специфицированного протокола – добавить очередной API для совместимости.

под Nano-X кажется был порт FLTK, под который был порт браузер WebKit. в итоге какой-то любитель собрал сначала дистрибутив Linux а затем и FreeDOS с таким GUI и DE.

есть и другие похожие примеры оконных систем, не только эти.

так что опять же – в Wayland нужно было изобретать подходы Photon или Nano-X (MicroWindows) – а не придумывать свои костыли и велосипеды.

вообще, написать оконную систему не так уж и сложно – у меня в гараже где-то валяются дискеты с GUI аналогом графического Turbo Vision под ДОС, который написал за пару месяцев в одиночку году этак в 1992/1993. потом я его переписал с паскаля на модулу и защищенный режим, и на что-то похожее immediate mode частично, потом поигрался и забросил. до ады жаль, что в этот раз не добрался, а вообще надо было на ней сразу писать :))

сложнее сделать это

а) быстро и эффективно

б) с поддержкой современных графических стеков и конвейеров типа OpenGL, Vulkan, шейдеров, etc;

в) совместимо по API с уже наработанными приложениями — а вот тут и находится основная засада.

хотя и не так уж просто.

самая наглядная математика на эту тему, на мой взгляд в проекте Nile/Gezira из проекта FONC/STEP/OMeta где для этого аж свой математический DSL придумали.

Чушь про вейланд. Попытка удачная с возможностью включения отрисовки через вулкан. Иксы дико лагают рядом с вейландом и единственный их плюс это легкий разгон монитора. Пропиши WLR_RENDERER=vulkan в /etc/environment и завязывай высасывать всем мозг.

Выполнял следующие команды. Без перезагрузки ModemManager и с ней:

echo 0 |sudo tee /sys/bus/usb/devices/1-3/authorized
echo 1 |sudo tee /sys/bus/usb/devices/1-3/authorized

echo 0 |sudo tee /sys/bus/usb/devices/1-3/1-3:3.2/authorized
echo 1 |sudo tee /sys/bus/usb/devices/1-3/1-3:3.2/authorized

echo 0 |sudo tee /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/authorized
echo 1 |sudo tee /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/authorized

echo 0 |sudo tee /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:3.2/authorized
echo 1 |sudo tee /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:3.2/authorized

Ничего из этого не сработало, к сожалению.

watchcat382, iliyap, пока временное решение: Ставим пакет usbutils и командой: sudo usbreset 12b1:15c1 ресетим устройство и оно начинает корректно отображаться.

sudo usbreset 12b1:15c1

Тоже вполне себе вариант. Прописать этот ресет в per-up в /etc/network/interfaces для ppp0,только надо подсмотреть в гугле способ сделать ожидание появления устройства в /dev, что-то типа такого

pre-up usbreset 12b1:15c1
pre-up for _ in $(seq 1 10); do /usr/bin/test -c /dev/ttyUSB0 && break; /bin/sleep 1; done

Ну это на тот случай если будете ppp-интерфейс через этот дебиановский ifup поднимать. А если своим скриптом то соответственно это писать в свой скрипт.

Вылезла дополнительная неприятность. Как известно, Дебиан любит обзывать сетевые интерфейсы странными именами, типа вместо eth0 называет enp2s0. Якобы для того чтобы имена не зависели от порядка активации этих интерфейсов. Но вот в случае использования usbip с именами бардак получается - то остается просто wwan0 то переименовыввается в что-то типа wwx028ddd964a36, а при следующей перезагрузке wwx226236d808e7, потом может снова wwan0 остаться или переименоваться в что-нибудь еще,причем разное :( Что естественно ставит крест на попытках написать скрипт для автоподнятия такого интерфейса. Вот не знаю как заставить udev всегда давать одно и то же имя. Ну не приучен он видимо работать с интерфейсами, сделанными через usbip.

Это уже не работает? // лично мне линки нравятся

Это уже не работает?

Есть радиомодемы (у меня такой) которые работают в режиме raw-ip,а не 802-3, и mac-адреса у них вообще НЕТ. А насколько я понимаю,почему-то в дебиане по умолчанию для usb сетевых устройств используется примязка с маку,а не к положению на шине как для pci устройств. Вот потому и получаеются эти странные имена у радиомодема,причем разные. А иногда переименование вообще не срабатывает и остается wwan0. Вопрос в том,как сделать для usb привязку к положению на шине также как это сделано для pci. Ну или к vid:pid например. Вобщем - к чему-нибудь тому что у радиомодема есть,а не к отсутствующему у него mac-адресу.

Вариант с net.ifnames=0 мне не нравится также как и хозяевам Дебиана,от именования eth0,eth1 отказавшимся - оно таки действительно может именоваться в случайном порядке при загрузке. И правильно что к положению карточки на шине привязали. Непонятно почему не поступили также для шины usb.

Нашел где привязка к маку для usb-устройств задается

/usr/lib/systemd/network/73-usb-net-by-mac.link

Там внутри исправил NamePolicy=mac сначала на path - помогло лишь отчасти - перестало переименовывать вообще,оставляет wwan0. Тогда исправил на kernel - пусть так и будет,лишь бы имя было постоянное. Но есть подозрение что после очередного апгрейда пакетов с systemd и/или udev это изменение может быть тихо затёрто - дебиановский пакетный менеджер любит так делать. Поэтому ищу как в предложенном вами варианте с .link файлом сделать привязку к чему-нибудь другому кроме mac. Например к vid:pid устройства.

Раскопал как сделать правильный link-файл для радиомодемов,не имеющих mac-адреса. Писать надо так:

# cat /etc/systemd/network/10-modem.link 

[Match]
Property=ID_MODEL_ID=0125 "ID_VENDOR_ID=2c7c"

[Link]
Name=gsm0

Вот тогда вместо mac-адреса для usb-сетевых устройств используются их VID и PID. Проверить правильно ли написали можно командой:

udevadm test-builtin net_setup_link /sys/class/net/wwan0

Тут надо указывать имя устройства «до переименования». Если напишет что собирается переименовать в gsm0 - значит vid и pid указаны правильно. И устройство теперь всегда будет иметь имя gsm0. К сожалению это не будет работать если воткнуты два совершенно одинаковых радиомодема. Но это ситуация маловероятная. Такое разве что для sms-шлюзов делают но там сетевые устройства не нужны.

Заодно разобрался почему в состоянии по умолчанию то переименовывалось то нет. А это потому что ядерный драйвер для сетевых usb-устройств исходно настроен работать с устройством в режиме «802-3», и у него какой-то свой MAC имеется даже если само устройство его не имеет. В процессе согласования формата данных с устройством скрипт /usr/bin/qmi-network переключает его в режим raw-ip и MAC-адрес исчезает. После этого уже переименование по адресу работать не будет и остается данное ядром имя wwan0. Даже если устройство передернуть в разъеме. Потому что драйвер в ядре уже один раз был перенастроен на raw-ip и больше mac-адрес не выдает. В случае с использованием usbip ситуация усугубляется тем что «передергиванием устройства» является сетевое переподключение.

По уму надо бы это согласование форматов куда-то в udev сразу запихать чтобы вообще не возникала ситуация рассогласования между устройством и ядерным драйвером. Но это надо откуда-то из конфигов udev запускать команду qmicli и разбирать там ее вывод. Фактически продублировать то что делает функция setup_data_format() в скрипте qmi-network. Но как это сделать красиво и не поломать дебиановскую автоконфигурацию я пока не знаю.

Ну ты «молоток» )

…

это не будет работать если воткнуты два совершенно одинаковых радиомодема. Но это ситуация маловероятная.

для китайских устройств почти наверняка так и будет

По уму надо бы это согласование форматов куда-то в udev сразу запихать чтобы вообще не возникала ситуация рассогласования между устройством и ядерным драйвером. Но это надо откуда-то из конфигов udev запускать команду qmicli и разбирать там ее вывод. Фактически продублировать то что делает функция setup_data_format() в скрипте qmi-network. Но как это сделать красиво и не поломать дебиановскую автоконфигурацию я пока не знаю

а если добавить свой скрипт к правилу udev?

Ну ты «молоток» )

Так у меня линукс это любимая компьютерная игрушка - уже 30 лет в нее играю и не надоело.

это не будет работать если воткнуты два совершенно одинаковых радиомодема. Но это ситуация маловероятная.

для китайских устройств почти наверняка так и будет

Так воткнуть-то два модема можно. А что с ними делать? Я знаю только одно применение - шлюзы,sms и голосовые. Но там не нужны сетевые интерфейсы этих модемов, используются терминалы /dev/ttyUSB* Потому и написал что способ с указанием VID и PID вполне пригоден для собственно модемно-сетевого применения. А кому сильно надо - могут через udevadm info -e найти свои модемы и посмотреть чем они еще отличаются,и вписать это в Property. Как без многочисленных перезагрузок тестировать на совпадение и срабатывание переименования - тоже выше написал.

а если добавить свой скрипт к правилу udev?

Впорос не в том чтобы добавить,а в том чтобы сделать это правильно. Сейчас udev плотно связан с systemd и я недостаточно хорошо представляю себе идеологию этого взаимодействия. Проще говоря - в какое место добавлять? Надо будет погуглить на предмет того как поступают с usb-устройствами,требующими некоторой инициализации сразу после втыкания. Например у меня была такая wifi карточка,кажется tp-link если правильно помню - ей надо было firmware грузить. Хотя если быть совсем точным то воздействовать надо не только на сам модем но и на модуль c которым он работает - то есть включить одинаковый формат данных в обоих местах. И если модем надо включать в нужный режим каждый раз при втыкании то модуль достаточно переключить один раз для каждого образуемого им интерфейса. Если модемов больше одного или если после вытаскивания модема первый образованный модулем сетевой интерфейс не освободился и при последующем втыкании модем встал вторым. Бывает,увы.

Ну и продолжение экспериментов с модемом. На этом модеме мне удалось получить от Мегафона IPv6 адрес и через такое соединение сходить на гугл:) Неприятностей несколько: не удается получить одновременно IPv6 и IPv4 адреса. Только что-нибудь одно,что первое поднял то и работает,вторая попытка вываливается с ошибкой ‘PolicyMismatch’. Возможно что нужно объявить в модеме два «контекста»,а у меня один был.

at+cgdcont?                                          
+CGDCONT: 1,"IPV4V6","internet","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0

Я вообще не уверен что используется этот контекст потому что он с нулями,а не вот этот,заполненный осмысленными цифрами при наличии соединения:

at+cgcontrdp
+CGCONTRDP: 1,5,internet,10.226.219.214,42.3.208.0.1.130.250.147.0.1.0.0.41.14.1
01.40, 254.128.0.0.0.0.0.0.0.0.0.0.0.0.0.5,10.153.3.212 42.3.208.0.3.1.0.1.0.0.0
.0.0.0.0.36,10.153.3.204 42.3.208.0.3.1.0.1.0.0.0.0.0.0.0.12 

AT+CGSCONTRDP                                                                   
OK          

Второе - это «second context»,возможно как-то надо его задавать чтобы работали одновременно IPv4 и IPv6. Но так как «операторским» IPv6 я весьма разочарован то буду продолжать использовать IPv6 через туннель teredo.

Вручную поднять IPv6 можно например вот этим скриптом: https://4pda.to/forum/index.php?showtopic=850236&view=findpost&p=74771001 Подправив в нем имя интерфейса и APN оператора. Но чтобы поднялось - надо сначала отключить IPv4. А лучше прямо сразу после включения модема пробовать,пока другие подключения не производились потому что «контекст» может оказаться занят.

Вторая неприятность - программа inadyn-mt не может прописать этот v6 адрес в freedns.afraid.org - хотя сам freedns.afraid.org поддерживает вписывание в него v6 адресов но похоже что собственно вписывание возможно только при обращении к нему по v4. Третья неприятность - как я уже упоминал dhclient с интерфейсом этого модема не работает потому что нет «802-3» заголовков,а udhcpc не умеет получать ipv6 адреса. Вобщем - пользы от получения IPv6 напрямую у мегафона вместо туннеля teredo оказалось меньше чем ожидалось. Также не вижу особой пользы от переключения модема в режим qmi вместо обычного pppd. Результаты speedtest.net показывают отсутствие сколько- нибудь заметного различия в скорости,вопреки утверждениям рекламы. Что так показывает запредельные для домашнего использования 16 рекламных мегабитов что эдак столько же. Только pppd отлично обрабаывает ошибки связи и сам переподключается,а вокруг qmi ничего такого пока что не написали или я это пока не нашел.

Откопал скрипт на замену qmi-network,называется tqmi-connect. Существенно более продвинутый и тщательно написанный. На моем модеме позволяет включить одновременно IPv4 и IPv6. Лежит тут: https://github.com/telit/tqmi-connect Он использует интерфейс qmimux0, образуемый поверх wwan0(ну или как будет называться собственно интерфейс модема). При этом адреса назначаются именно на этот интерфейс,и ipv4 и ipv6. Но скрипт не прописывает роутинг,его надо вручную задать

route add default dev qmimux0
route -6 add default dev qmimux0

Так что желающие могут пользоваться. Для ipv6 я проверял только на одном компе где модем, с раздачей адресов на другие компы не разбирался так как надобности нет.

Увы - все это работает «вручную»,в обход дебиановской системы конфигурирования интерфейсов. И возможные обрывы связи или подвисания модема никак не обрабатывает,в отличие от использования pppd.