Bug 32060
| Summary: | Перестали работать USB-модемы | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Sergey Y. Afonin <asy> |
| Component: | usb-modeswitch-data | Assignee: | Mikhail Efremov <sem> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | critical | ||
| Priority: | P3 | CC: | aen, alxste, asy, boyarsh, lakostis, mike, mister.eric, nbr, rider, ruslandh, sem, shaba |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
| Attachments: | |||
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 , но всё равно соединение не создалось. 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 Цитата из ссылки выше: "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 продолжаю постить сюда, т.к. тут все логи по этому модему. |
Description
Sergey Y. Afonin 2016-05-04 15:47:53 MSK