Bug 32060 - Перестали работать USB-модемы
: Перестали работать USB-модемы
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/usb-modeswitch-data)
: unstable
: all Linux
: P3 critical
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2016-05-04 15:47 by
Modified: 2017-07-31 21:13 (History)


Attachments
Пример подключения в p7 (2.49 KB, text/x-log)
2016-05-04 15:54, Sergey Y. Afonin
no flags Details
Пример подключения модема в p8, udev_log="debug" (27.92 KB, text/x-log)
2016-05-05 11:38, Sergey Y. Afonin
no flags Details
Лог работы с G4 модемом (25.45 KB, application/x-bzip2)
2016-05-05 22:54, ruslandh
no flags Details
Лог udevadm test модма 4G (2.74 KB, application/x-bzip)
2016-05-07 09:38, ruslandh
no flags Details
Выдача udev info по 4-м модемам на одном компьютере (1.71 KB, application/x-bzip)
2016-05-07 15:25, ruslandh
no flags Details
Выдача udev info модема 4G на другом компьютере (2.97 KB, text/plain)
2016-05-07 15:28, ruslandh
no flags Details
Общая часть на всех HUAWEI (2.09 KB, text/plain)
2016-05-07 15:30, ruslandh
no flags Details
Общая часть по всем протестированным модемам (2.06 KB, text/plain)
2016-05-07 15:31, ruslandh
no flags Details
Маленькое исправление (403 bytes, text/plain)
2016-05-08 01:12, ruslandh
no flags Details
Лучшее, что мне удалось добиться (1.28 KB, text/plain)
2016-05-10 08:24, ruslandh
no flags Details
Стандартный лог (181 bytes, application/octet-stream)
2016-05-10 08:25, ruslandh
no flags Details
Мой набор "отмычек" (6.77 KB, application/x-bzip2)
2016-05-10 08:40, ruslandh
no flags Details
Логи (10.49 KB, application/x-bzip2)
2016-05-18 00:21, ruslandh
no flags Details
Неудачный лог с Хуавей (2.90 KB, application/octet-stream)
2016-05-20 09:03, ruslandh
no flags Details
Удачный лог. (2.72 KB, application/octet-stream)
2016-05-20 09:04, ruslandh
no flags Details
вставка модема, модем не заработал, ручной вызов usb-modeswitch, соединение (14.29 KB, text/x-log)
2016-06-06 11:39, Alexander
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2016-05-04 15:47:53
обсуждение: https://lists.altlinux.org/pipermail/devel/2016-May/201361.html

Есть модем, работающий в p7. Попытка установки в p8 не завершается созданием
tty:

May  4 16:38:03 kernel: [1565709.053025] usb 5-1: new high-speed USB device
number 21 using ehci-pci
May  4 16:38:03 kernel: [1565709.184926] usb-storage 5-1:1.0: USB Mass Storage
device detected
May  4 16:38:03 kernel: [1565709.192099] scsi host24: usb-storage 5-1:1.0
May  4 16:38:03 kernel: [1565709.192440] usb-storage 5-1:1.1: USB Mass Storage
device detected
May  4 16:38:03 kernel: [1565709.198155] scsi host25: usb-storage 5-1:1.1
May  4 16:38:03 mtp-probe: checking bus 5, device 21:
"/sys/devices/pci0000:00/0000:00:1d.7/usb5/5-1"
May  4 16:38:03 mtp-probe: bus: 5, device: 21 was not an MTP device
May  4 16:38:04 kernel: [1565710.215197] sr 24:0:0:0: [sr1] scsi-1 drive

И всё на этом. Судя по всему не происходит вызов usb_modeswitch. У этого пакета
тоже есть проблема (bug #31362), но вряд ли дело именно в этом: откат до пары
пакетов из p7 проблему не решает.
------- Comment #1 From 2016-05-04 15:54:12 -------
Created an attachment (id=6705) [details]
Пример подключения в p7

Пример подключения этого же модема в p7.
------- Comment #2 From 2016-05-04 21:45:06 -------
Вот ещё по теме:
https://forum.altlinux.org/index.php?topic=36758.msg285754#msg285754
------- Comment #3 From 2016-05-04 23:00:27 -------
возможно  как-то поможет в диагностике..

модем huawei e392 - при подключении определяется как  как cdrom
после вызова в консоли вручную  команды:
usb_modeswitch -v 12d1 -p 1505 -V 12d1 -P 151b -W -M
55534243123456780000000000000011062000000100000000000000000000
распознается системой и устанавливает соединение (через NetworkManager).
------- Comment #4 From 2016-05-05 02:51:38 -------
(In reply to comment #0)
> обсуждение: https://lists.altlinux.org/pipermail/devel/2016-May/201361.html
> 
> Есть модем, работающий в p7. Попытка установки в p8 не завершается созданием
> tty:
> 
> May  4 16:38:03 kernel: [1565709.053025] usb 5-1: new high-speed USB device
> number 21 using ehci-pci
> May  4 16:38:03 kernel: [1565709.184926] usb-storage 5-1:1.0: USB Mass Storage
> device detected
> May  4 16:38:03 kernel: [1565709.192099] scsi host24: usb-storage 5-1:1.0
> May  4 16:38:03 kernel: [1565709.192440] usb-storage 5-1:1.1: USB Mass Storage
> device detected
> May  4 16:38:03 kernel: [1565709.198155] scsi host25: usb-storage 5-1:1.1
> May  4 16:38:03 mtp-probe: checking bus 5, device 21:
> "/sys/devices/pci0000:00/0000:00:1d.7/usb5/5-1"
> May  4 16:38:03 mtp-probe: bus: 5, device: 21 was not an MTP device
> May  4 16:38:04 kernel: [1565710.215197] sr 24:0:0:0: [sr1] scsi-1 drive
> 
> И всё на этом. Судя по всему не происходит вызов usb_modeswitch. У этого пакета
> тоже есть проблема (bug #31362), но вряд ли дело именно в этом: откат до пары
> пакетов из p7 проблему не решает.

Откатил до
usb-modeswitch-2.0.1-alt1
usb-modeswitch-data-20131113-alt1
модем определяется нормально; говоря "нормально", имею в виду, что хотя
определяется и работает, но без передергивания модема не обходится
https://bugzilla.altlinux.org/show_bug.cgi?id=30489
------- Comment #5 From 2016-05-05 07:56:59 -------
(In reply to comment #3)

> Откатил до
> usb-modeswitch-2.0.1-alt1
> usb-modeswitch-data-20131113-alt1

Это что-то совсем далеко, в p7 новее сейчас:

usb-modeswitch-data-20140529-alt2
usb-modeswitch-2.2.0-alt0.M70P.1

> модем определяется нормально; говоря "нормально", имею в виду, что хотя
> определяется и работает, но без передергивания модема не обходится
> https://bugzilla.altlinux.org/show_bug.cgi?id=30489

Это про работу с systemd, а хотелось бы и без, как раньше.
------- Comment #6 From 2016-05-05 08:34:40 -------
Посмотрите вот эти таски: 
164301 - без systemd, последняя версия
164315 - полностью интегррированный с systemd

164319- новый usb-modeswitch-data

164317 - пересобранный 2.1.1
------- Comment #7 From 2016-05-05 08:36:07 -------
 У меня лучше всех показал 164301 , но всё равно соединение не создалось.
------- Comment #8 From 2016-05-05 08:39:22 -------
https://lists.altlinux.org/pipermail/devel/2016-May/201392.html
------- Comment #9 From 2016-05-05 08:50:06 -------
2shaba@ , boyarsh@ : чья эта бага? :)
------- Comment #10 From 2016-05-05 09:12:15 -------
Всё, я сообразил. Я yota тестировал, а она на 4G только включается. Модем с 4G
не работает из-за CD, а на остальных, надо смотреть, но это уже не сейчас - на
работу пора. Но на одном сразу завёлся с Мегафоном на  164301
------- Comment #11 From 2016-05-05 09:22:27 -------
(В ответ на комментарий №10)
> Всё, я сообразил. Я yota тестировал, а она на 4G только включается. Модем с 4G
> не работает из-за CD, а на остальных, надо смотреть, но это уже не сейчас - на
> работу пора. Но на одном сразу завёлся с Мегафоном на  164301

Руслан, Вы объясните _тут_, что попало сейчас в Сизиф и где у Вас что завелось
без отсылки к номерам заданий.
------- Comment #12 From 2016-05-05 09:31:24 -------
Извиняюсь перед мантейнером пакета, но в сизиф уехала база 
usb-modeswitch-data от 2016012, переименованная в версию 2.3.0 (по примеру
OpenSuse).

Задание http://git.altlinux.org/tasks/archive/done/_160/164316
------- Comment #13 From 2016-05-05 09:39:54 -------
Завелась 2.3.0 с патчем, убирающим systemd.  

 http://git.altlinux.org/tasks/164301/

Базу везде использовал одну и ту-же, 2.3.0 (20160112).

версия 164315 то-же работспособна, но ничем не лучше 164301, только имеет
лишнию зависимость на systemd.
------- Comment #14 From 2016-05-05 09:42:25 -------
PS у меня ещё и симка от Мегафона развалилась, теперь в другой модем не
переставишь, так-что на других модемах пока проверить не могу ;-(
------- Comment #15 From 2016-05-05 10:13:54 -------
(In reply to comment #12)

> переименованная в версию 2.3.0 (по примеру OpenSuse).

Вот это, кажется, зря: usb-modeswitch-data может обновляться независимо от
usb-modeswitch. Но, может быть, и хорошо видеть в названии пакета минимальную
версию.

А вот отправлять в Сизиф пакет data до обновления самого usb-modeswitch не
стоило, если в readme у data есть предупреждение о минимальной версии. Лучше
было их в одном задании держать.
------- Comment #16 From 2016-05-05 10:16:46 -------
(In reply to comment #10)

> Всё, я сообразил. Я yota тестировал, а она на 4G только включается. Модем с 4G
> не работает из-за CD, а на остальных, надо смотреть, но это уже не сейчас - на
> работу пора. Но на одном сразу завёлся с Мегафоном на  164301

В том и задача modeswitch, чтобы перевести устройство в состояние модема. У
меня так и не работает с usb-modeswitch-2.3.0-alt1.0 +
usb-modeswitch-data-2.3.0-alt1. Мне кажется, что проблема, всё же, в районе
udev. usb-modeswitch надо доделывать и заливать в Сизиф, и переключаться на
udev.
------- Comment #17 From 2016-05-05 11:01:02 -------
(In reply to comment #16)

> Мне кажется, что проблема, всё же, в районе udev. usb-modeswitch
> надо доделывать и заливать в Сизиф, и переключаться на udev.

Собственно да. Если сделать по аналогии с комментарием #3 (модем другой, набор
параметров чуть отличается)

usb_modeswitch -v 12d1 -p 1446 -V 12d1 -P 151b -W -M
55534243000000000000000000000011060000000000000000000000000000

то всё нужное появляется:

May  5 11:58:06 asy kernel: [1635312.014705] usb 5-1: USB disconnect, device
number 28
May  5 11:58:13 kernel: [1635318.756049] usb 5-1: new high-speed USB device
number 29 using ehci-pci
May  5 11:58:13 kernel: [1635318.887225] usb-storage 5-1:1.0: USB Mass Storage
device detected
May  5 11:58:13 kernel: [1635318.891797] option 5-1:1.0: GSM modem (1-port)
converter detected
May  5 11:58:13 kernel: [1635318.892046] usb 5-1: GSM modem (1-port) converter
now attached to ttyUSB0

И так далее, как в логе из p7.
------- Comment #18 From 2016-05-05 11:08:56 -------
У меня сейчас нет под рукой подходящего устройства.
Приложите, пожалуйста, логи неудачного подключения в Сизифе, не ограничиваясь
dmesg
Если у вас systemd, укажите это и приложить вывод journalctl с момента
подключения модема.
Если у вас sysvinit укажите это.
Чем больше логов вы приложите, тем больше вероятность быстрого исправления.
------- Comment #19 From 2016-05-05 11:32:26 -------
(In reply to comment #18)

> Приложите, пожалуйста, логи неудачного подключения в Сизифе, не ограничиваясь
> dmesg

В первом сообщении, вообще-то, syslog/messages. udev_log="debug" количество
информации там не увеличивает. Хотя, смотрю, что-то пошло в daemons/info. Но
всё про cdrom. Сейчас приложу.

> Если у вас sysvinit укажите это.

Это вот я не указал. Речь про sysvinit. 

> У меня сейчас нет под рукой подходящего устройства.

Вообще, наверное, я могу придумать вариант с доступом к стенду с модемом.
------- Comment #20 From 2016-05-05 11:38:21 -------
Created an attachment (id=6706) [details]
Пример подключения модема в p8, udev_log="debug"
------- Comment #21 From 2016-05-05 12:59:51 -------
Кто-нибудь может подтвердить или опровергнуть работоспособность usb-modeswitch
под управлением systemd?
------- Comment #22 From 2016-05-05 13:44:37 -------
(В ответ на комментарий №21)
> Кто-нибудь может подтвердить или опровергнуть работоспособность usb-modeswitch
> под управлением systemd?
------- Comment #23 From 2016-05-05 13:45:16 -------
> > Кто-нибудь может подтвердить или опровергнуть работоспособность usb-modeswitch
> > под управлением systemd?
Я могу. Не работает. Буду копать.
------- Comment #24 From 2016-05-05 13:49:03 -------
У меня работает только при  "ручном" вызове. На втыкание модема не реагирует.
У меня p8 systemd.
------- Comment #25 From 2016-05-05 13:52:53 -------
Сейчас в обед по-быстрому накатил пакеты 2.3.0. И симку сбегал поменял.

Из 4-х опробованных модемов.
- один завёлся сразу и вышел в интернет (E160G  - 2d1:1001 Huawei Technologies
Co., Ltd. E169/E620/E800 HSDPA Modem)

- Один обнаружил связь, но не смог подключиться (Связной bbb:f000 T & A Mobile
Phones)

- Один создал ttyUSB, но соединения не показал (Мегафон M21-4  12d1:1506 Huawei
Technologies Co., Ltd. )

- Один не создал ttyUSB - Мепфащт 4G (12d1:1506 Huawei Technologies Co., Ltd.
Modem/Networkcard)
------- Comment #26 From 2016-05-05 14:01:38 -------
Сейчас проверил - все 4 модема в рабочем состоянии и в p7 все вышли в интернет.
------- Comment #27 From 2016-05-05 14:18:13 -------
(In reply to comment #25)

> Из 4-х опробованных модемов.
> - один завёлся сразу и вышел в интернет (E160G  - 2d1:1001 Huawei Technologies
> Co., Ltd. E169/E620/E800 HSDPA Modem)

Этот, видимо, переключен в режим модема по-умолчанию. Это состояние у них можно
сохранять.


> - Один обнаружил связь, но не смог подключиться (Связной bbb:f000 T & A Mobile
> Phones)
> 
> - Один создал ttyUSB, но соединения не показал (Мегафон M21-4  12d1:1506 Huawei
> Technologies Co., Ltd. )

Эти, наверное, тоже в режиме модема по-умолчанию. Вероятно, есть какая-то ещё
проблема.

> - Один не создал ttyUSB - Мепфащт 4G (12d1:1506 Huawei Technologies Co., Ltd.
> Modem/Networkcard)

А вот этот не дождался запуска usb_modeswitch.
------- Comment #28 From 2016-05-05 14:20:03 -------
(В ответ на комментарий №18)
> У меня сейчас нет под рукой подходящего устройства.
Если что, есть билайновый и мегафоновый USB 3G-модемы (без симок).
И йота, но она другая...
------- Comment #29 From 2016-05-05 14:43:42 -------
> > - Один не создал ttyUSB - Мепфащт 4G (12d1:1506 Huawei Technologies Co., Ltd.
> > Modem/Networkcard)
> 
> А вот этот не дождался запуска usb_modeswitch.
 Generic запись для устройств Huawei почему-то не срабатывает, попробуйте
добавить в /lib/udev/rules.d/40-usb_modeswitch.rules

ATTR{idVendor}=="12d1", ATTR{idProduct}=="1506", RUN+="usb_modeswitch '%b/%k'"

После этого usb_modeswitch должен запуститься, но я не уверен, что это
единственная проблема.
------- Comment #30 From 2016-05-05 14:55:06 -------
(In reply to comment #29)

> ATTR{idVendor}=="12d1", ATTR{idProduct}=="1506", RUN+="usb_modeswitch '%b/%k'"
> 
> После этого usb_modeswitch должен запуститься, но я не уверен, что это
> единственная проблема.

У меня отработало правильно теперь (с поправкой на ATTR{idProduct}=="1446").
------- Comment #31 From 2016-05-05 15:01:36 -------
> У меня отработало правильно теперь (с поправкой на ATTR{idProduct}=="1446").
То есть связь установилась или просто usb_modswitch запустился, но ничего
полезного не сделал?
------- Comment #32 From 2016-05-05 15:09:55 -------
Похоже отработала, тк. id поменялся на 12d1:155b, но устройство /dev/ttyUSB не
появилось. Там в логах журнала идёт какая-то mpt-probe Может туда уходит не
возвращается? Я с телефона. Если нужны логи, то только вечером. Ну или через
фото.
------- Comment #33 From 2016-05-05 15:45:04 -------
(In reply to comment #31)

> > У меня отработало правильно теперь (с поправкой на ATTR{idProduct}=="1446").

> То есть связь установилась или просто usb_modswitch запустился, но ничего
> полезного не сделал?

Сделал всё, что нужно:

May  5 16:35:57 kernel: [1651983.177661] usb 5-1: GSM modem (1-port) converter
now attached to ttyUSB0
May  5 16:35:57 kernel: [1651983.182246] usb 5-1: GSM modem (1-port) converter
now attached to ttyUSB1
May  5 16:35:57 kernel: [1651983.186786] usb 5-1: GSM modem (1-port) converter
now attached to ttyUSB2

Все порты на месте, связь дальше - это дело уже pppd/networkmanager, это я не
проверял, не настроено нигде. Но оно должно работать после того, как
соответствующие устройства появились, я думаю. Хотя, я сейчас KDesktop 7 пробую
обновить, если всё пройдёт быстро и успешно, можно попробовать связь проверить.
------- Comment #34 From 2016-05-05 15:47:05 -------
В общем, я вижу проблему раз:
в правилах написано:
ATTRS{idVendor}=="12d1", ATTRS{manufacturer}!="Android",
ATTR{bInterfaceNumber}=="00", ATTR{bInterfaceClass}=="08", RUN+="usb_modeswitch
'%b/%k'"

Это правило не срабатывает.
Если убрать ATTR{bInterfaceNumber}=="00", ATTR{bInterfaceClass}=="08", оно
срабатывает, но на неправильном устройстве.

udevadm:
  looking at device '/devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2:1.0':
    KERNEL=="3-2:1.0"
    SUBSYSTEM=="usb"
    DRIVER=="usb-storage"
    ATTR{authorized}=="1"
    ATTR{bAlternateSetting}==" 0"
    ATTR{bInterfaceClass}=="08"
    ATTR{bInterfaceNumber}=="00"
    ATTR{bInterfaceProtocol}=="50"
    ATTR{bInterfaceSubClass}=="06"
    ATTR{bNumEndpoints}=="02"
    ATTR{supports_autosuspend}=="1"

  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb3/3-2':
    KERNELS=="3-2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{authorized}=="1"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bDeviceClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{bMaxPower}=="500mA"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bNumInterfaces}==" 2"
    ATTRS{bcdDevice}=="0000"
    ATTRS{bmAttributes}=="e0"
    ATTRS{busnum}=="3"
    ATTRS{configuration}=="Huawei   Configuration"
    ATTRS{devnum}=="23"
    ATTRS{devpath}=="2"
    ATTRS{idProduct}=="1446"
    ATTRS{idVendor}=="12d1"
    ATTRS{ltm_capable}=="no"
    ATTRS{manufacturer}=="HUAWEI Technology"
    ATTRS{maxchild}=="0"
    ATTRS{product}=="HUAWEI Mobile"
    ATTRS{quirks}=="0x0"
    ATTRS{removable}=="removable"
    ATTRS{speed}=="480"
    ATTRS{urbnum}=="1281"
    ATTRS{version}==" 2.00"


Правило должно сработать на 3-2:1.0, но не срабатывает.
------- Comment #35 From 2016-05-05 15:53:43 -------
Я сейчас руками включил 
Там новый ключ появился -J
------- Comment #36 From 2016-05-05 15:55:26 -------
usb... -J ... 155b ... 1506
------- Comment #37 From 2016-05-05 18:11:24 -------
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=2414 Вот тут
что-то пишут про устройства
------- Comment #38 From 2016-05-05 18:24:13 -------
(In reply to comment #5)
> (In reply to comment #3)
> 
> > Откатил до
> > usb-modeswitch-2.0.1-alt1
> > usb-modeswitch-data-20131113-alt1
> 
> Это что-то совсем далеко, в p7 новее сейчас:
> 
> usb-modeswitch-data-20140529-alt2
> usb-modeswitch-2.2.0-alt0.M70P.1
> 
Других под рукой не оказалось, зато заводится с полпинка.
------- Comment #39 From 2016-05-05 19:06:01 -------
В Readme у нового пакета есть описание, как использовать файл
device_reference.txt, который лежит в том-же каталоге.
------- Comment #40 From 2016-05-05 20:59:40 -------
Я не вижу, чтобы правило udev работало хоть с каким-нибудь модемом.
С любым получаю это:
[test@c164 ~]$ cat /var/log/usb_modeswitch_noname 

USB_ModeSwitch log from Thu Feb 11 19:59:00 MSK 2016

Use global config file: /etc/usb_modeswitch.conf

Started via systemd
Raw args from udev: -1-3


No data from udev. Exit
------- Comment #41 From 2016-05-05 21:26:23 -------
Я то-же не вижу вызова. Везде вместо программы положил скрипты, которые пишут о
своём вызове в файл и параметры с какими вызывались.

Так вот - пусто.
------- Comment #42 From 2016-05-05 21:32:13 -------
Вот, если переименую /lib/udev/usb_modeswitch во что-то другое, systemd-udevd
начинает ругаться на его отутствие и выдаёт команду, с какими параметрами
пытается его запустить.
------- Comment #43 From 2016-05-05 21:33:09 -------
Не переменную, а переименовать. ;-)
------- Comment #44 From 2016-05-05 21:34:13 -------
(В ответ на комментарий №40)
> 

> 
> Started via systemd
> Raw args from udev: -1-3
> 
> 
> No data from udev. Exit

Если это скормит google, то можно почитать интересное. В основном про модемы
Huaway.
------- Comment #45 From 2016-05-05 22:54:19 -------
Created an attachment (id=6709) [details]
Лог работы с G4 модемом

Вначале включил все логи, потом вставил модем. Подождал и дал команду 

usb_modeswitch -J -v 12d1 -p 155b -V 12d1 -P 1506
------- Comment #46 From 2016-05-07 09:38:11 -------
Created an attachment (id=6710) [details]
Лог udevadm test модма 4G

Я тут почитал теорию 
https://bitbucket.org/avlubimov/comp-house.repo/wiki/DebugUDEVRules
https://wiki.archlinux.org/index.php/Udev_%28Русский%29
(жаль что у нас такого нет), и протестировал модем, как там описано. 
После первого тестирования убрал лишние правила, после второго, переименовал 
40-usb_... на 39_uss....

Вот тут перескакивание идёт и правило 40-usb_modeswitch не читается:

....
IMPORT builtin 'usb_id' /lib/udev/rules.d/40-libgphoto2.rules:9
IMPORT builtin skip 'usb_id' /lib/udev/rules.d/50-udev-default.rules:13
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:13
MODE 0664 /lib/udev/rules.d/50-udev-default.rules:41
....
------- Comment #47 From 2016-05-07 13:22:39 -------
А вот такой глупый вопрос - что должно запускаться из правил udev?

Меня на https://wiki.archlinux.org/index.php/USB_3G_Modem_%28Русский%29 смутила
строка:

SUBSYSTEM=="usb", SYSFS{idProduct}=="1446", SYSFS{idVendor}=="12d1",
RUN+="/lib/udev/modem-modeswitch --vendor 0x12d1 --product 0x1446 --type
option-zerocd"
------- Comment #48 From 2016-05-07 13:24:46 -------
PS Я пока от обратного пошёл - пытаюсь конкретно под мой модем создать простое
правило, которое запускало-бы usb_modeswitch.
------- Comment #49 From 2016-05-07 15:25:34 -------
Created an attachment (id=6711) [details]
Выдача udev info по 4-м модемам наодном компьютере
------- Comment #50 From 2016-05-07 15:28:00 -------
Created an attachment (id=6712) [details]
Выдача udev info модема 4G на другом компьютере
------- Comment #51 From 2016-05-07 15:30:34 -------
Created an attachment (id=6713) [details]
Общая часть на всех HUAWEI
------- Comment #52 From 2016-05-07 15:31:58 -------
Created an attachment (id=6714) [details]
Общая часть по всем протестированным модемам
------- Comment #53 From 2016-05-08 01:12:25 -------
Created an attachment (id=6715) [details]
Маленькое исправление

В общем, приложив ещё одно маленькое исправление /usr/lib/usb_modeswitch , мне
удалось запустить из /etc/udev/modem.rules /usr/sbin/usb_modeswich, только там
меня ждала ещё одна ошибка. Формируются некорректные параметры, строка запуска
выглядит так:
usb_modeswitch -W -D -u -1 -b 1 -g 32 -v 12d1 -p 155b -f # Huawei E171
TargetVendor=0x12d1 TargetProduct=0x1506 HuaweiNewMode=1

Т.е. # закрывает весь оставшийся параметр. В man написано, что с помощью man
можно задавать многострочное описание устройства, как я понимаю, с задумкой,
что-бы система сама нашла нужные ключи для этого устройства.
------- Comment #54 From 2016-05-08 01:14:11 -------
Описка:
С помощью ключа -f. 
Только примера в мане нет :)
------- Comment #55 From 2016-05-09 14:08:40 -------
Я в начале файла поставил 

ACTION=="add", PROGRAM="/bin/echo modem ADD"
ACTION=="change", PROGRAM="/bin/echo modem CHANGE"

Так вот, "modem ADD" я в логах journald вижу, а вот "modem CHANGE" - нет.
------- Comment #56 From 2016-05-10 08:05:20 -------
Прошу не пинать меня сильно, за вопрос: 
в кубунту 16.04 с системд с ЛЮБыми юсб-свитками проблем нет, какие мне
приложить логи. чтобы можно было видеть разницу: почему там это работает, а в
альт нет?
------- Comment #57 From 2016-05-10 08:21:01 -------
Надо разрешить логи usb_modeswitch
/etc/modeswitch.conf
....
EnableLogging=1
....

И посмотреть лог /var/log/usb_modeswitch_порт

Ну и запустить перед вставкой модема
jotnalctl -af 2>&1 | tee /tmp/jurnal.log

При необходимости поавысить уровень логирования journald
------- Comment #58 From 2016-05-10 08:24:36 -------
Created an attachment (id=6716) [details]
Лучшее, что мне удалось добиться
------- Comment #59 From 2016-05-10 08:25:48 -------
Created an attachment (id=6717) [details]
Стандартный лог

Имя порта неправильно сформировалось
------- Comment #60 From 2016-05-10 08:30:55 -------
(В ответ на комментарий №57)
> Надо разрешить логи usb_modeswitch
> /etc/modeswitch.conf
> ....
> EnableLogging=1
> ....
> 
> И посмотреть лог /var/log/usb_modeswitch_порт
> 
> Ну и запустить перед вставкой модема
> jotnalctl -af 2>&1 | tee /tmp/jurnal.log
> 
> При необходимости поавысить уровень логирования journald

OK,через два дня получу доступ к машине с убунту и выложу все логи
------- Comment #61 From 2016-05-10 08:40:13 -------
Created an attachment (id=6718) [details]
Мой набор "отмычек"

На время тестирования, я подменял стандартные инструменты, на эти "отмычки",
которые уже вызывали переименованные мной стандартные утилиты.
------- Comment #62 From 2016-05-12 21:18:11 -------
(In reply to comment #40)
> Я не вижу, чтобы правило udev работало хоть с каким-нибудь модемом.

usb-modeswitch-2.3.0-alt2 будет опять работать с не-HUAWEI модемами.
С HUAWEI модемами в правилах udev'а творится что-то запредельное явно по вине
самого udev'а.
Workaround: убрать /lib/udev/rules.d/10-dm.rules
------- Comment #63 From 2016-05-12 21:29:22 -------
(В ответ на комментарий №62)
> (In reply to comment #40)
> > Я не вижу, чтобы правило udev работало хоть с каким-нибудь модемом.
> 
> usb-modeswitch-2.3.0-alt2 будет опять работать с не-HUAWEI модемами.
> С HUAWEI модемами в правилах udev'а творится что-то запредельное явно по вине
> самого udev'а.
> Workaround: убрать /lib/udev/rules.d/10-dm.rules

Спасибо! Не забудьте отправить в p8, пожалуйста.
------- Comment #64 From 2016-05-12 21:31:19 -------
(В ответ на комментарий №62)
> (In reply to comment #40)
> > Я не вижу, чтобы правило udev работало хоть с каким-нибудь модемом.
> 
> usb-modeswitch-2.3.0-alt2 будет опять работать с не-HUAWEI модемами.
> С HUAWEI модемами в правилах udev'а творится что-то запредельное явно по вине
> самого udev'а.
> Workaround: убрать /lib/udev/rules.d/10-dm.rules

Спасибо! Не забудьте отправить в p8, пожалуйста.

(В ответ на комментарий №62)
> (In reply to comment #40)
> > Я не вижу, чтобы правило udev работало хоть с каким-нибудь модемом.
> 
> usb-modeswitch-2.3.0-alt2 будет опять работать с не-HUAWEI модемами.
> С HUAWEI модемами в правилах udev'а творится что-то запредельное явно по вине
> самого udev'а.
> Workaround: убрать /lib/udev/rules.d/10-dm.rules

Спасибо! Не забудьте отправить в p8, пожалуйста.
------- Comment #65 From 2016-05-12 23:50:03 -------
Я вот заметил среди логов такую строку:

usb_modeswiswitch service: cgroup is empty.

а вот тут в логах у Ubuntu читаю:

"[ 24.531403] cgroup: libvirtd (1662) created nested cgroup for controller
"memory" which has incomplete hierarchy support. Nested cgroups may change
behavior in the future.
[ 24.531405] cgroup: "memory" requires setting use_hierarchy to 1 on the root.
[ 24.531436] cgroup: libvirtd (1662) created nested cgroup for controller
"devices" which has incomplete hierarchy support. Nested cgroups may change
behavior in the future.
[ 24.531463] cgroup: libvirtd (1662) created nested cgroup for controller
"blkio" which has incomplete hierarchy support. Nested cgroups may change
behavior in the future.
[ 64.065928] usb 3-3: new high-speed USB device number 2 using xhci_hcd
[ 64.082445] usb 3-3: New USB device found, idVendor=12d1, idProduct=14fe
[ 64.082452] usb 3-3: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 64.082455] usb 3-3: Product: HUAWEI Mobile
[ 64.082458] usb 3-3: Manufacturer: HUAWEI....
....
"


Может ему требуется настроенный cgroup?

Первый раз про cgroup слышу, но:


$ apt-cache search cgroup
cgmanager - Linux cgroup manager
pam0_cgm - Development files for libcgmanager
cgroup - Tools to control and monitor control groups
libcgroup - Libraries for allow to control and monitor control groups
libcgroup-devel - Development libraries to develop applications that utilize
control groups
pam_cgroup - A Pluggable Authentication Module for libcgroup
------- Comment #66 From 2016-05-12 23:58:11 -------
https://bbs.archlinux.org/viewtopic.php?id=175443
------- Comment #67 From 2016-05-13 00:00:55 -------
Цитата из ссылки выше:

"It's due to the virtualbox update released on Jan 04 which brought his udev
rule execution order from 10 to 60, so usb_modeswitch works well but virtualbox
overwrites his rules (they're 40).
I opened a bug that you can see here, and I'm going to

# mv /lib/udev/rules.d/40-usb_modeswitch.rules
/lib/udev/rules.d/61-usb_modeswitch.rules

and report if it works. Stay tuned.

EDIT: It works after reboot. I suggest you to use this workaround till he bug
is is fixed. Bye bye."

Пошёл пробовать :-)
------- Comment #68 From 2016-05-13 01:08:39 -------
Сейчас формируется строка (смотрю в логах):
usb_modeswitch -W -D -u -1 -b 1 -g 10 -v 12d1 -p 155b -f # Huawei E171
TargetVendor=0x12d1
TargetProduct=0x1506
HuaweiNewMode=1

А для того, что-бы она отработала, нужно заэкранировать решётку 

usb_modeswitch -W -D -u -1 -b 1 -g 10 -v 12d1 -p 155b -f #\ Huawei E171
TargetVendor=0x12d1
TargetProduct=0x1506
HuaweiNewMode=1

А вот что-бы модем заработал - не хватает "пустяка" - ключа -J

usb_modeswitch  W -J -D -u -1 -b 1 -g 10 -v 12d1 -p 155b -f #\ Huawei E171
TargetVendor=0x12d1
TargetProduct=0x1506
HuaweiNewMode=1
------- Comment #69 From 2016-05-13 01:10:16 -------
Описка, конечно : не
#\
а 
\#
------- Comment #70 From 2016-05-13 01:15:10 -------
По идее 
HuaweiMode=1 -  должен задавать ключ -H.
а
HuaweiNewMode=1 -  должен задавать ключ -J.

Но почему-то это не отрабатывается (во всяком случае с NewMode).
------- Comment #71 From 2016-05-13 05:37:05 -------
Поправлю в VirtualBox (RUN/RUN+).
------- Comment #72 From 2016-05-13 07:50:10 -------
Я вчера эти рулёзы по-разному переставлял. Если снижать  у VirtualBox, то-же
идут траблы. Методовм подбора получилось 91 у VirtualBox и 92 у usb-modeswitch.

Если просто снизить у VirtualBox, то в логах постоянно ругань на что-то
связанное с gpg.
------- Comment #73 From 2016-05-13 08:29:16 -------
Да, в последнем virtualbox (5.0.20), а также в 5.0.14 правило стоит в 90_ и
выглядит правильно. Тогда 40-usb_modeswitch.rules надо действительно в 91.
------- Comment #74 From 2016-05-13 08:38:55 -------
Там 77-м идут правила от NetworkManager , в том числе:
77-mm-huawei-net-port-types.rules

их работа не сломается?
------- Comment #75 From 2016-05-13 09:46:03 -------
>там 77-м идут правила от NetworkManager , в том числе:
>77-mm-huawei-net-port-types.rules

>их работа не сломается?
Они относятся вот к такому устройству:
https://techship.se/products/huawei-mu609-mini-pci-express/
К сожалению, у меня такого нет.
У кого-нибудь есть такое устройство для проверки?
------- Comment #76 From 2016-05-13 09:57:58 -------
This module is part of Huawei's new family of modules, including MU509 (HSDPA),
MU609 (HSPA+) and ME909 (LTE) which are all pin-to-pin compatible to enable a
clear and easy path for future integration. This makes the integration of any
one of these modules very future-proof.


Цитата из вашей ссылки.
------- Comment #77 From 2016-05-17 17:44:28 -------
Этот коммит, обнаруженный imz@, проблему с HUAWEI модемами исправляет:
https://github.com/systemd/systemd/commit/c45606eb95a7171b0dc801e91d35034957ad5e9e

2shaba: Могу подготовить NMU с этим патчем, если надо. Но может там есть еще
что заcherry-pick'ать из апстрима заодно?
------- Comment #78 From 2016-05-17 18:03:45 -------
(В ответ на комментарий №77)
> Этот коммит, обнаруженный imz@, проблему с HUAWEI модемами исправляет:
> https://github.com/systemd/systemd/commit/c45606eb95a7171b0dc801e91d35034957ad5e9e
> 
> 2shaba: Могу подготовить NMU с этим патчем, если надо. Но может там есть еще
> что заcherry-pick'ать из апстрима заодно?

Я не планировал сейчас что-либо cherry-pick'ать, т.к. жду в ближайшее время
релиза v230.
Так что лучше NMU(если надо срочно). В задании #164747 это исправление и есть,
но без cherry-pick, и мне это не нравится :)
------- Comment #79 From 2016-05-17 18:10:31 -------
(In reply to comment #78)
> Так что лучше NMU(если надо срочно).

Бага неприятная, лучше исправить. Подготовлю NMU когда сборочница заработает.
------- Comment #80 From 2016-05-17 20:09:54 -------
А, можно ссылку дать на git, для локальной сборки и проверке на "моём
зоопарке"?
------- Comment #81 From 2016-05-17 20:35:07 -------
(In reply to comment #80)
> А, можно ссылку дать на git, для локальной сборки и проверке на "моём
> зоопарке"?

Я тестировал свою сборку, но в задании #164747 действительно есть сборка с
аналогичным патчем.
------- Comment #82 From 2016-05-18 00:21:08 -------
Created an attachment (id=6726) [details]
Логи 

К сожалению с #164747 не удалось. Правда ещё один модем заработал - от
Связного, но он не Хуавей (до этого не работал). Возможно у меня какая-то
локальная мисконфигурация, но я её не нашёл. Прикладываю логи с журналд с G4
модемом и Мегафон - оба Хуавей.
------- Comment #83 From 2016-05-19 23:18:27 -------
systemd-1:229-alt6 -> sisyphus:

* Wed May 18 2016 Mikhail Efremov <sem@altlinux> 1:229-alt6
- Patch from upstream:
    + strbuf: set the proper character when creating new nodes
      (closes: #32060).
------- Comment #84 From 2016-05-20 09:03:23 -------
Created an attachment (id=6727) [details]
Неудачный лог с Хуавей

Посмотрел по-быстрому.

Пока ничего не изменилось, скорее стало хуже. После обновления отвалился eth0.
Не знаю, насколько это связано. На Сизифе такого нет, а на ноуте с p8 отвалился
(а вот WiFi - работает).
------- Comment #85 From 2016-05-20 09:04:54 -------
Created an attachment (id=6728) [details]
Удачный лог.

Для сравнения - удачный лог с другим модемом.
------- Comment #86 From 2016-05-20 10:26:15 -------
После выключения ноута и повторного включения eth0 заработал.
------- Comment #87 From 2016-05-20 10:29:32 -------
А модем ?
------- Comment #88 From 2016-05-20 10:50:49 -------
С модемом всё так-же плохо. :-(

В выходные посмотрю более подробно.
------- Comment #89 From 2016-05-20 11:06:21 -------
(В ответ на комментарий №84)
> Created an attachment (id=6727) [details] [details]
> Неудачный лог с Хуавей

Лог подтверждает, что этот баг исправлен, т.к. usb_modeswitch запустился. Если
он не переключил режим, то это, возможно, какая-то другая проблема, к которой
udev вряд ли имеет отношение.
------- Comment #90 From 2016-05-20 12:04:43 -------
Пока по-прежнему грешу на разбор длинной строки usb-modeswitch
------- Comment #91 From 2016-05-20 12:28:36 -------
(In reply to comment #83)

> * Wed May 18 2016 Mikhail Efremov <sem@altlinux> 1:229-alt6
> - Patch from upstream:
>     + strbuf: set the proper character when creating new nodes
>       (closes: #32060).

У меня всё заработало. И ttyUSB появились, и кардридер в модеме подцепился, и
внутренний псевдо-cd-rom. HUAWEI E1550.
------- Comment #92 From 2016-05-20 23:34:02 -------
Взял другой ноут, обновил его вчистую. Всё работает.
На этом, где пробовал, какие-то проблемы. Но это уже для рассылки вопрос.

Спасибо.
------- Comment #93 From 2016-06-06 11:39:58 -------
Created an attachment (id=6746) [details]
вставка модема, модем не заработал, ручной вызов usb-modeswitch, соединение

P8, по прежнему не запускаются автоматически модемы huswei.

чтобы модем заработал приходится пинать usb_modeswitch вручную.
Прикладываю лог.
Скрипт для ручного пинания такой:
#!/bin/sh
sudo usb_modeswitch -v 0x12d1 -p 0x1446 -V 0x12d1 -P 0x1436 -M
55534243123456780000000000000011062000000100000000000000000000
(вызов скрипта соответствует отметке в логе:
июн 06 11:22:15 xxx.localdomain unknown[7968]: ----before manual switch call
----
)
------- Comment #94 From 2016-06-06 11:41:58 -------
С модемами huawei проблемы остались.
см. предыдущее сообщение + лог
------- Comment #95 From 2016-06-06 11:45:18 -------
Модем вот такой:
Bus 002 Device 005: ID 12d1:1446 Huawei Technologies Co., Ltd. Broadband stick
(modem on)
------- Comment #96 From 2016-06-30 07:06:56 -------
В связи с отпуском, взял ноутбук с собой и выявил интересную особенность.
Если загрузиться в Windows, подсоединить модем, а потом перезагрузиться в Linux
он нормально работает.

После перезагрузузки 

lsusb
...
Bus 001 Device 002: ID 12d1:1506 Huawei Technologies Co., Ltd.
Modem/Networkcard
...

PS Пока более подробно разбираться некогда.
------- Comment #97 From 2016-06-30 08:47:48 -------
(In reply to comment #96)

> Если загрузиться в Windows, подсоединить модем, а потом перезагрузиться
> в Linux он нормально работает.

Это, как раз, объяснимо: Windows заменяет собой usb_modeswitch, переводя
устройство из режима эмуляции CD-ROM в режим модема. Можно это сделать и
AT-командой через minicom. Причём, можно и записать это состояние в самом
модеме, тогда всегда работать будет.
------- Comment #98 From 2017-06-14 10:07:22 -------
Пояcните пожалуйста, какие есть основания считать, что это та же проблема, что
была исправлена в https://bugzilla.altlinux.org/show_bug.cgi?id=32060#c83
------- Comment #99 From 2017-06-16 07:21:58 -------
Внешне они идентичны.
------- Comment #100 From 2017-06-16 08:44:41 -------
(In reply to comment #99)

> Внешне они идентичны.

Если речь про https://forum.altlinux.org/index.php?topic=38973.0 , то нет. Этот
баг про непоявление /dev/ttyUSB*, то есть, про то, что модем не переводится в,
собственно, режим модема. В случае же на форуме ttyUSB создаются. Там что-то
другое. Может быть, там NM появляющаяся сетевая карта с толку сбивает.
------- Comment #101 From 2017-06-16 16:35:06 -------
Т.е. предлагается прочитать почти сотню комментариев, которые скорее всего
никакого отношения к проблеме не имеют. Пожалуйста, не надо превращать багзиллу
в такую же помойку, как эти ваши форумы.
Для новой проблемы нужно открывать новый баг.
------- Comment #102 From 2017-06-16 21:33:15 -------
(В ответ на комментарий №100)

> 
> Если речь про https://forum.altlinux.org/index.php?topic=38973.0 , то нет. Этот
> баг про непоявление /dev/ttyUSB*, то есть, про то, что модем не переводится в,
> собственно, режим модема. В случае же на форуме ttyUSB создаются. Там что-то
> другое. Может быть, там NM появляющаяся сетевая карта с толку сбивает.

Нет, у меня до сих пор не один Хуавей не заводится, и на форуме часто такое об
этом "слышу"
------- Comment #103 From 2017-06-16 21:36:35 -------
(В ответ на комментарий №101)
> Т.е. предлагается прочитать почти сотню комментариев, которые скорее всего
> никакого отношения к проблеме не имеют. Пожалуйста, не надо превращать багзиллу
> в такую же помойку, как эти ваши форумы.
> Для новой проблемы нужно открывать новый баг.
Я вообще-то не думаю, что это не та-же проблема.

Багу я конечно могу новую завести, но не вижу в этом смысле. Могу проблемные
модемы к вам завести при случае ;-)
------- Comment #104 From 2017-07-31 21:13:11 -------
Вот, что обнаружил с этим пробдемным модемом:

Если дать команду:

usb_modeswitch -J -v 12d1 -p 155b
то модем сразу обнаруживается.
а вот, если дать команду
usb_modeswitch -v 12d1 -p 155b
(без ключа -J), то модем не обнаруживается.

Может он и в автомате не отрабатывает, что теряется ключ -J ?


PS продолжаю постить сюда, т.к. тут все логи по этому модему.