обсуждение: 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 проблему не решает.
Created attachment 6705 [details] Пример подключения в p7 Пример подключения этого же модема в p7.
Вот ещё по теме: https://forum.altlinux.org/index.php?topic=36758.msg285754#msg285754
возможно как-то поможет в диагностике.. модем huawei e392 - при подключении определяется как как cdrom после вызова в консоли вручную команды: usb_modeswitch -v 12d1 -p 1505 -V 12d1 -P 151b -W -M 55534243123456780000000000000011062000000100000000000000000000 распознается системой и устанавливает соединение (через NetworkManager).
(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
(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, а хотелось бы и без, как раньше.
Посмотрите вот эти таски: 164301 - без systemd, последняя версия 164315 - полностью интегррированный с systemd 164319- новый usb-modeswitch-data 164317 - пересобранный 2.1.1
У меня лучше всех показал 164301 , но всё равно соединение не создалось.
https://lists.altlinux.org/pipermail/devel/2016-May/201392.html
2shaba@ , boyarsh@ : чья эта бага? :)
Всё, я сообразил. Я yota тестировал, а она на 4G только включается. Модем с 4G не работает из-за CD, а на остальных, надо смотреть, но это уже не сейчас - на работу пора. Но на одном сразу завёлся с Мегафоном на 164301
(В ответ на комментарий №10) > Всё, я сообразил. Я yota тестировал, а она на 4G только включается. Модем с 4G > не работает из-за CD, а на остальных, надо смотреть, но это уже не сейчас - на > работу пора. Но на одном сразу завёлся с Мегафоном на 164301 Руслан, Вы объясните _тут_, что попало сейчас в Сизиф и где у Вас что завелось без отсылки к номерам заданий.
Извиняюсь перед мантейнером пакета, но в сизиф уехала база usb-modeswitch-data от 2016012, переименованная в версию 2.3.0 (по примеру OpenSuse). Задание http://git.altlinux.org/tasks/archive/done/_160/164316
Завелась 2.3.0 с патчем, убирающим systemd. http://git.altlinux.org/tasks/164301/ Базу везде использовал одну и ту-же, 2.3.0 (20160112). версия 164315 то-же работспособна, но ничем не лучше 164301, только имеет лишнию зависимость на systemd.
PS у меня ещё и симка от Мегафона развалилась, теперь в другой модем не переставишь, так-что на других модемах пока проверить не могу ;-(
(In reply to comment #12) > переименованная в версию 2.3.0 (по примеру OpenSuse). Вот это, кажется, зря: usb-modeswitch-data может обновляться независимо от usb-modeswitch. Но, может быть, и хорошо видеть в названии пакета минимальную версию. А вот отправлять в Сизиф пакет data до обновления самого usb-modeswitch не стоило, если в readme у data есть предупреждение о минимальной версии. Лучше было их в одном задании держать.
(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.
(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.
У меня сейчас нет под рукой подходящего устройства. Приложите, пожалуйста, логи неудачного подключения в Сизифе, не ограничиваясь dmesg Если у вас systemd, укажите это и приложить вывод journalctl с момента подключения модема. Если у вас sysvinit укажите это. Чем больше логов вы приложите, тем больше вероятность быстрого исправления.
(In reply to comment #18) > Приложите, пожалуйста, логи неудачного подключения в Сизифе, не ограничиваясь > dmesg В первом сообщении, вообще-то, syslog/messages. udev_log="debug" количество информации там не увеличивает. Хотя, смотрю, что-то пошло в daemons/info. Но всё про cdrom. Сейчас приложу. > Если у вас sysvinit укажите это. Это вот я не указал. Речь про sysvinit. > У меня сейчас нет под рукой подходящего устройства. Вообще, наверное, я могу придумать вариант с доступом к стенду с модемом.
Created attachment 6706 [details] Пример подключения модема в p8, udev_log="debug"
Кто-нибудь может подтвердить или опровергнуть работоспособность usb-modeswitch под управлением systemd?
(В ответ на комментарий №21) > Кто-нибудь может подтвердить или опровергнуть работоспособность usb-modeswitch > под управлением systemd?
> > Кто-нибудь может подтвердить или опровергнуть работоспособность usb-modeswitch > > под управлением systemd? Я могу. Не работает. Буду копать.
У меня работает только при "ручном" вызове. На втыкание модема не реагирует. У меня p8 systemd.
Сейчас в обед по-быстрому накатил пакеты 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)
Сейчас проверил - все 4 модема в рабочем состоянии и в p7 все вышли в интернет.
(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.
(В ответ на комментарий №18) > У меня сейчас нет под рукой подходящего устройства. Если что, есть билайновый и мегафоновый USB 3G-модемы (без симок). И йота, но она другая...
> > - Один не создал 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 должен запуститься, но я не уверен, что это единственная проблема.
(In reply to comment #29) > ATTR{idVendor}=="12d1", ATTR{idProduct}=="1506", RUN+="usb_modeswitch '%b/%k'" > > После этого usb_modeswitch должен запуститься, но я не уверен, что это > единственная проблема. У меня отработало правильно теперь (с поправкой на ATTR{idProduct}=="1446").
> У меня отработало правильно теперь (с поправкой на ATTR{idProduct}=="1446"). То есть связь установилась или просто usb_modswitch запустился, но ничего полезного не сделал?
Похоже отработала, тк. id поменялся на 12d1:155b, но устройство /dev/ttyUSB не появилось. Там в логах журнала идёт какая-то mpt-probe Может туда уходит не возвращается? Я с телефона. Если нужны логи, то только вечером. Ну или через фото.
(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 пробую обновить, если всё пройдёт быстро и успешно, можно попробовать связь проверить.
В общем, я вижу проблему раз: в правилах написано: 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, но не срабатывает.
Я сейчас руками включил Там новый ключ появился -J
usb... -J ... 155b ... 1506
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=2414 Вот тут что-то пишут про устройства
(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 > Других под рукой не оказалось, зато заводится с полпинка.
В Readme у нового пакета есть описание, как использовать файл device_reference.txt, который лежит в том-же каталоге.
Я не вижу, чтобы правило 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
Я то-же не вижу вызова. Везде вместо программы положил скрипты, которые пишут о своём вызове в файл и параметры с какими вызывались. Так вот - пусто.
Вот, если переименую /lib/udev/usb_modeswitch во что-то другое, systemd-udevd начинает ругаться на его отутствие и выдаёт команду, с какими параметрами пытается его запустить.
Не переменную, а переименовать. ;-)
(В ответ на комментарий №40) > > > Started via systemd > Raw args from udev: -1-3 > > > No data from udev. Exit Если это скормит google, то можно почитать интересное. В основном про модемы Huaway.
Created attachment 6709 [details] Лог работы с G4 модемом Вначале включил все логи, потом вставил модем. Подождал и дал команду usb_modeswitch -J -v 12d1 -p 155b -V 12d1 -P 1506
Created attachment 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 ....
А вот такой глупый вопрос - что должно запускаться из правил 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"
PS Я пока от обратного пошёл - пытаюсь конкретно под мой модем создать простое правило, которое запускало-бы usb_modeswitch.
Created attachment 6711 [details] Выдача udev info по 4-м модемам на одном компьютере
Created attachment 6712 [details] Выдача udev info модема 4G на другом компьютере
Created attachment 6713 [details] Общая часть на всех HUAWEI
Created attachment 6714 [details] Общая часть по всем протестированным модемам
Created attachment 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 можно задавать многострочное описание устройства, как я понимаю, с задумкой, что-бы система сама нашла нужные ключи для этого устройства.
Описка: С помощью ключа -f. Только примера в мане нет :)
Я в начале файла поставил ACTION=="add", PROGRAM="/bin/echo modem ADD" ACTION=="change", PROGRAM="/bin/echo modem CHANGE" Так вот, "modem ADD" я в логах journald вижу, а вот "modem CHANGE" - нет.
Прошу не пинать меня сильно, за вопрос: в кубунту 16.04 с системд с ЛЮБыми юсб-свитками проблем нет, какие мне приложить логи. чтобы можно было видеть разницу: почему там это работает, а в альт нет?
Надо разрешить логи usb_modeswitch /etc/modeswitch.conf .... EnableLogging=1 .... И посмотреть лог /var/log/usb_modeswitch_порт Ну и запустить перед вставкой модема jotnalctl -af 2>&1 | tee /tmp/jurnal.log При необходимости поавысить уровень логирования journald
Created attachment 6716 [details] Лучшее, что мне удалось добиться
Created attachment 6717 [details] Стандартный лог Имя порта неправильно сформировалось
(В ответ на комментарий №57) > Надо разрешить логи usb_modeswitch > /etc/modeswitch.conf > .... > EnableLogging=1 > .... > > И посмотреть лог /var/log/usb_modeswitch_порт > > Ну и запустить перед вставкой модема > jotnalctl -af 2>&1 | tee /tmp/jurnal.log > > При необходимости поавысить уровень логирования journald OK,через два дня получу доступ к машине с убунту и выложу все логи
Created attachment 6718 [details] Мой набор "отмычек" На время тестирования, я подменял стандартные инструменты, на эти "отмычки", которые уже вызывали переименованные мной стандартные утилиты.
(In reply to comment #40) > Я не вижу, чтобы правило udev работало хоть с каким-нибудь модемом. usb-modeswitch-2.3.0-alt2 будет опять работать с не-HUAWEI модемами. С HUAWEI модемами в правилах udev'а творится что-то запредельное явно по вине самого udev'а. Workaround: убрать /lib/udev/rules.d/10-dm.rules
(В ответ на комментарий №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, пожалуйста. (В ответ на комментарий №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, пожалуйста.
Я вот заметил среди логов такую строку: 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
https://bbs.archlinux.org/viewtopic.php?id=175443
Цитата из ссылки выше: "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." Пошёл пробовать :-)
Сейчас формируется строка (смотрю в логах): 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
Описка, конечно : не #\ а \#
По идее HuaweiMode=1 - должен задавать ключ -H. а HuaweiNewMode=1 - должен задавать ключ -J. Но почему-то это не отрабатывается (во всяком случае с NewMode).
Поправлю в VirtualBox (RUN/RUN+).
Я вчера эти рулёзы по-разному переставлял. Если снижать у VirtualBox, то-же идут траблы. Методовм подбора получилось 91 у VirtualBox и 92 у usb-modeswitch. Если просто снизить у VirtualBox, то в логах постоянно ругань на что-то связанное с gpg.
Да, в последнем virtualbox (5.0.20), а также в 5.0.14 правило стоит в 90_ и выглядит правильно. Тогда 40-usb_modeswitch.rules надо действительно в 91.
Там 77-м идут правила от NetworkManager , в том числе: 77-mm-huawei-net-port-types.rules их работа не сломается?
>там 77-м идут правила от NetworkManager , в том числе: >77-mm-huawei-net-port-types.rules >их работа не сломается? Они относятся вот к такому устройству: https://techship.se/products/huawei-mu609-mini-pci-express/ К сожалению, у меня такого нет. У кого-нибудь есть такое устройство для проверки?
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. Цитата из вашей ссылки.
Этот коммит, обнаруженный imz@, проблему с HUAWEI модемами исправляет: https://github.com/systemd/systemd/commit/c45606eb95a7171b0dc801e91d35034957ad5e9e 2shaba: Могу подготовить NMU с этим патчем, если надо. Но может там есть еще что заcherry-pick'ать из апстрима заодно?
(В ответ на комментарий №77) > Этот коммит, обнаруженный imz@, проблему с HUAWEI модемами исправляет: > https://github.com/systemd/systemd/commit/c45606eb95a7171b0dc801e91d35034957ad5e9e > > 2shaba: Могу подготовить NMU с этим патчем, если надо. Но может там есть еще > что заcherry-pick'ать из апстрима заодно? Я не планировал сейчас что-либо cherry-pick'ать, т.к. жду в ближайшее время релиза v230. Так что лучше NMU(если надо срочно). В задании #164747 это исправление и есть, но без cherry-pick, и мне это не нравится :)
(In reply to comment #78) > Так что лучше NMU(если надо срочно). Бага неприятная, лучше исправить. Подготовлю NMU когда сборочница заработает.
А, можно ссылку дать на git, для локальной сборки и проверке на "моём зоопарке"?
(In reply to comment #80) > А, можно ссылку дать на git, для локальной сборки и проверке на "моём > зоопарке"? Я тестировал свою сборку, но в задании #164747 действительно есть сборка с аналогичным патчем.
Created attachment 6726 [details] Логи К сожалению с #164747 не удалось. Правда ещё один модем заработал - от Связного, но он не Хуавей (до этого не работал). Возможно у меня какая-то локальная мисконфигурация, но я её не нашёл. Прикладываю логи с журналд с G4 модемом и Мегафон - оба Хуавей.
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).
Created attachment 6727 [details] Неудачный лог с Хуавей Посмотрел по-быстрому. Пока ничего не изменилось, скорее стало хуже. После обновления отвалился eth0. Не знаю, насколько это связано. На Сизифе такого нет, а на ноуте с p8 отвалился (а вот WiFi - работает).
Created attachment 6728 [details] Удачный лог. Для сравнения - удачный лог с другим модемом.
После выключения ноута и повторного включения eth0 заработал.
А модем ?
С модемом всё так-же плохо. :-( В выходные посмотрю более подробно.
(В ответ на комментарий №84) > Created an attachment (id=6727) [details] > Неудачный лог с Хуавей Лог подтверждает, что этот баг исправлен, т.к. usb_modeswitch запустился. Если он не переключил режим, то это, возможно, какая-то другая проблема, к которой udev вряд ли имеет отношение.
Пока по-прежнему грешу на разбор длинной строки usb-modeswitch
(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.
Взял другой ноут, обновил его вчистую. Всё работает. На этом, где пробовал, какие-то проблемы. Но это уже для рассылки вопрос. Спасибо.
Created attachment 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 ---- )
С модемами huawei проблемы остались. см. предыдущее сообщение + лог
Модем вот такой: Bus 002 Device 005: ID 12d1:1446 Huawei Technologies Co., Ltd. Broadband stick (modem on)
В связи с отпуском, взял ноутбук с собой и выявил интересную особенность. Если загрузиться в Windows, подсоединить модем, а потом перезагрузиться в Linux он нормально работает. После перезагрузузки lsusb ... Bus 001 Device 002: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard ... PS Пока более подробно разбираться некогда.
(In reply to comment #96) > Если загрузиться в Windows, подсоединить модем, а потом перезагрузиться > в Linux он нормально работает. Это, как раз, объяснимо: Windows заменяет собой usb_modeswitch, переводя устройство из режима эмуляции CD-ROM в режим модема. Можно это сделать и AT-командой через minicom. Причём, можно и записать это состояние в самом модеме, тогда всегда работать будет.
Пояcните пожалуйста, какие есть основания считать, что это та же проблема, что была исправлена в https://bugzilla.altlinux.org/show_bug.cgi?id=32060#c83
Внешне они идентичны.
(In reply to comment #99) > Внешне они идентичны. Если речь про https://forum.altlinux.org/index.php?topic=38973.0 , то нет. Этот баг про непоявление /dev/ttyUSB*, то есть, про то, что модем не переводится в, собственно, режим модема. В случае же на форуме ttyUSB создаются. Там что-то другое. Может быть, там NM появляющаяся сетевая карта с толку сбивает.
Т.е. предлагается прочитать почти сотню комментариев, которые скорее всего никакого отношения к проблеме не имеют. Пожалуйста, не надо превращать багзиллу в такую же помойку, как эти ваши форумы. Для новой проблемы нужно открывать новый баг.
(В ответ на комментарий №100) > > Если речь про https://forum.altlinux.org/index.php?topic=38973.0 , то нет. Этот > баг про непоявление /dev/ttyUSB*, то есть, про то, что модем не переводится в, > собственно, режим модема. В случае же на форуме ttyUSB создаются. Там что-то > другое. Может быть, там NM появляющаяся сетевая карта с толку сбивает. Нет, у меня до сих пор не один Хуавей не заводится, и на форуме часто такое об этом "слышу"
(В ответ на комментарий №101) > Т.е. предлагается прочитать почти сотню комментариев, которые скорее всего > никакого отношения к проблеме не имеют. Пожалуйста, не надо превращать багзиллу > в такую же помойку, как эти ваши форумы. > Для новой проблемы нужно открывать новый баг. Я вообще-то не думаю, что это не та-же проблема. Багу я конечно могу новую завести, но не вижу в этом смысле. Могу проблемные модемы к вам завести при случае ;-)
Вот, что обнаружил с этим пробдемным модемом: Если дать команду: usb_modeswitch -J -v 12d1 -p 155b то модем сразу обнаруживается. а вот, если дать команду usb_modeswitch -v 12d1 -p 155b (без ключа -J), то модем не обнаруживается. Может он и в автомате не отрабатывает, что теряется ключ -J ? PS продолжаю постить сюда, т.к. тут все логи по этому модему.
