Периодически отваливается USB модем

[unoc_u34]

Приветствую всех форумчан! Имеется ОС CentOS установлен ЮСБ-модем HIAWEI E173. В системе поднята система виртуализации KVM\QEMU
и модем проброшен на виртуальку. Время от времени модем отваливается с ошибкой (ошибка из вируталки):
rtt min/avg/max/mdev = 78.120/78.491/78.863/0.465 ms
[root@sj45s outbox]# service gammu-sm[78454.532755] usb 1-1: USB disconnect, device number 2
[78454.540785] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
[78454.543444] option 1-1:1.0: device disconnected
[78454.544256] cdc_ether 1-1:1.1 wws4f7u1i1: unregister 'cdc_ether' usb-0000:00:04.7-1, Mobile Broadband Network Device
[78454.550519] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
[78454.551748] option 1-1:1.3: device disconnected
[78454.553755] option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2
[78454.555158] option 1-1:1.4: device disconnected


Подскажите, пожалуйста, как решить. Спасибо огромное за ранее!

[Hephaestus]

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

Поэтому, прежде всего, надо проверить физику.
Обеспечить модему нормальное питание.
Модем, вероятно, висит на окне, воткнут в usb-кабель?
Вот этот самый кабель должен быть качественным, экранированным, и не слишком длинным.
Также, обратите внимание, в какой usb-разъем втыкается модем.
Разъемы на передней панели могут быть слабоваты для модема.

Это всё безотносительно виртуалки/не виртуалки. Общие рекомендации.
Я бы начал именно с этого.

[unoc_u34]

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

Поэтому, прежде всего, надо проверить физику.
Обеспечить модему нормальное питание.
Модем, вероятно, висит на окне, воткнут в usb-кабель?
Вот этот самый кабель должен быть качественным, экранированным, и не слишком длинным.
Также, обратите внимание, в какой usb-разъем втыкается модем.
Разъемы на передней панели могут быть слабоваты для модема.

Это всё безотносительно виртуалки/не виртуалки. Общие рекомендации.
Я бы начал именно с этого.

Спасибо, что ответили. Модем воткнуть прямиком в мазеборд и с питанием проблем нет.

[devilr]

Чтобы отсечь проблемы с питанием, нужно, прежде всего оценить само питание модема. Мультиметром. Обычным.
Опять же, кабель может быть красивым, толстым, экранированным, но, внутри, может быть обычный секретный китайский сплав фольги и картона. И земля подключена неправильно. Или, вовсе не подключена.
Ну и, основную причину чудес в электротехнике - контакты - никто не отменял.
Имхо.

[Hephaestus]

unoc_u34
Если питание в норме, в таком случае сообщите, как модем ведет себя на хостовой системе (без виртуалки).

[unoc_u34]

Чтобы отсечь проблемы с питанием, нужно, прежде всего оценить само питание модема. Мультиметром. Обычным.
Опять же, кабель может быть красивым, толстым, экранированным, но, внутри, может быть обычный секретный китайский сплав фольги и картона. И земля подключена неправильно. Или, вовсе не подключена.
Ну и, основную причину чудес в электротехнике - контакты - никто не отменял.
Имхо.

Спасибо, за развернутый ответ. Модем подключен прямиком к матьке без проводом.
Честно скажу, питание не проверял. Но мне кажеться, что проблеме с питанием.

[unoc_u34]

unoc_u34
Если питание в норме, в таком случае сообщите, как модем ведет себя на хостовой системе (без виртуалки).

Когда модем пробрасывается в виртуалку, устройства ttyUSB* перебрасываются гипервизиром (КЕМУ) в витуалку. Когда вышеупомянутая ошибка возникает, КЕМУ освобождает девайсы.

[devilr]

Спасибо, за развернутый ответ. Модем подключен прямиком к матьке без проводом.
Честно скажу, питание не проверял. Но мне кажеться, что проблеме с питанием.

Ну, сам разъем тоже бывает либо корявым от изготовителя, либо окисленным. Либо, в случае, если модем какое-то время таскался в кармане - банально "засранным". Тут два варианта решения - спичка-ватка-спирт, либо замена самого разъёма.
Бывает ещё такая штука - сам разъем на модеме припаян неправильно на заводе и, от длительной эксплуатации, появились микротрещины на спае разъёма с основной платой модема. Тогда, можно просто разобрать модем и прогреть паяльником дефектный спай.

[unoc_u34]

Спасибо, за развернутый ответ. Модем подключен прямиком к матьке без проводом.
Честно скажу, питание не проверял. Но мне кажеться, что проблеме с питанием.

Ну, сам разъем тоже бывает либо корявым от изготовителя, либо окисленным. Либо, в случае, если модем какое-то время таскался в кармане - банально "засранным". Тут два варианта решения - спичка-ватка-спирт, либо замена самого разъёма.
Бывает ещё такая штука - сам разъем на модеме припаян неправильно на заводе и, от длительной эксплуатации, появились микротрещины на спае разъёма с основной платой модема. Тогда, можно просто разобрать модем и прогреть паяльником дефектный спай.

Спасибо Вам за ваши ценные советы. Чтобы исключить физику, попробуй заменить модем на новый. Кстати, ваши предположения, тоже могуть быть верными, так как, модем он затасканный

[Bizdelnick]

А что говорит dmesg на хост-системе на момент отключения?

[Hephaestus]

Когда модем пробрасывается в виртуалку, устройства ttyUSB* перебрасываются гипервизиром (КЕМУ) в витуалку. Когда вышеупомянутая ошибка возникает, КЕМУ освобождает девайсы.

Я не об этом спрашивал. Я спрашивал, как ведет себя модем без виртуалки. Стабильно работает или тоже отваливается?

[unoc_u34]

Когда модем пробрасывается в виртуалку, устройства ttyUSB* перебрасываются гипервизиром (КЕМУ) в витуалку. Когда вышеупомянутая ошибка возникает, КЕМУ освобождает девайсы.

Я не об этом спрашивал. Я спрашивал, как ведет себя модем без виртуалки. Стабильно работает или тоже отваливается?

Честно скажу. на хосте я не проверял работает ли нет. Но одно ясно, когда отваливается модем из виртуалки, гипервизор освобождает все девайся ttyUSB* и на хосте они станут доступны и udevadm info --name=/dev/ttyUSB0 --attribute-walk определяет устройство со всеми характиристиками.

[unoc_u34]

А что говорит dmesg на хост-системе на момент отключения?

Спасибо, что ответили. Случиться такой прецедент, проверю и выхлоп напишу.

[unoc_u34]

Когда модем пробрасывается в виртуалку, устройства ttyUSB* перебрасываются гипервизиром (КЕМУ) в витуалку. Когда вышеупомянутая ошибка возникает, КЕМУ освобождает девайсы.

Я не об этом спрашивал. Я спрашивал, как ведет себя модем без виртуалки. Стабильно работает или тоже отваливается?

Еще раз здравствуйтте! Сегондя случилось опять та же ситуация, т.е. ЮСБ девайся пропали из виртуалки. Наблюдалось следующее:
В то време как в виртуалке не определялись ЮСБ девайсы т.е.как ttyUSB*, в этот момент их и хост оказывается не видил, т.е. они и из хоста пропали. Было определен, что VID и PID ы модема были изменены т.е. когда все работало было 12d1:1436, а когда перестало работать стало 12d1:1446. Господа форумчане, следовательно вознимакет вопрос: Как прокинуть ЮСБ девайс в не зависимости от ВИД и ПИДа, либо сделать так, чтобы ВИД и ПИД никогда не менялся. За ранее огромное спасибо за наводки.

[Bizdelnick]

Похоже на то, что модем самопроизвольно перезагрузился. Может из-за питания, а может из-за глюка прошивки.
PID меняется при переключении модема в другой режим (это usb_modeswitch обычно делает), без этого он просто не будет работать.

[unoc_u34]

Похоже на то, что модем самопроизвольно перезагрузился. Может из-за питания, а может из-за глюка прошивки.
PID меняется при переключении модема в другой режим (это usb_modeswitch обычно делает), без этого он просто не будет работать.

Спасибо, что ответили Bizdelnick. Имеется-ли какой нибудь вариант перманентно сказать ему, чтобы тот не менял режим? Например сформировать файлик в /etc/udev/rules.d/ с названием хх-usb_modeswitch.rules и прописать там, не вариант? За ранее спасибо за ответ.

[Hephaestus]

Было определен, что VID и PID ы модема были изменены т.е. когда все работало было 12d1:1436, а когда перестало работать стало 12d1:1446. Господа форумчане, следовательно вознимакет вопрос: Как прокинуть ЮСБ девайс в не зависимости от ВИД и ПИДа, либо сделать так, чтобы ВИД и ПИД никогда не менялся.

Как уже сказал Bizdelnick, VID:PID меняется при переключении модема в другой режим.
Обычно изначально модем находится в режиме носителя cdrom (там драйвера под win, фирменный софт и т.п.), под Windows после установки драйверов, устройство переключается в режим модема и дальше уже работает.
Под Linux переключение режима происходит с помощью usb_modeswitch и делается это при каждом втыкании модема в разъем.
В Вашем случае хост переключил режим модема, далее виртуалка перехватила это usb-устройство и дальше, если что-то случилось с модемом, хост уже его не переключает, в частности потому, что устройство занято виртуалкой.
То есть его нужно освободить, переключить, и снова занять.

Вариантов вижу только два:
1. Скормить виртуалке оба usb-устройства (12d1:1436 и 12d1:1446) и пусть режим переключается внутри виртуалки. Тогда хост этим заниматься не должен.

2. Установить на модем какую-нибудь hilink-прошивку. Точно я не помню, но в этих прошивках вроде бы есть возможность зафиксировать режим устройства, то есть отключить cdrom модема и сохранить это состояние.

Минусы этого варианта:
Этот вариант сложнее, прошивки эти пилятся энтузиастами, обитают где-нибудь на 4pda.ru, там нужно найти тему про свое устройство и смотреть, что к чему.
Заливается неофициальная прошивка на устройство (потеря гарантии и пр.)

Плюсы:
Соединение с сетью происходит внутри модема, в компьютере он выглядит как сетевая карта.
Веб-интерфейс управления модемом, с кучей настроек, нет необходимости возиться с драйверами, фирменными софтинами и т.д.
Можно переключаться между 3G/4G, в том числе в автоматическом режиме. То есть модем не теряет соединение.
В зависимости от версии hilink-прошивки дополнительно может быть возможность отправлять sms и ussd запросы.
Если модем ещё и разлочен, интерфейс поддерживает любые симки.

[unoc_u34]

Спасибо Вам за ваш развернутый ответ.

В Вашем случае хост переключил режим модема, далее виртуалка перехватила это usb-устройство и дальше, если что-то случилось с модемом, хост уже его не переключает, в частности потому, что устройство занято виртуалкой.
То есть его нужно освободить, переключить, и снова занять.

Да, так и есть, что получается такая нелепая ситуация, режим поменялся, но при всем этом, процесс гипервизора на хосте занимает устройство и не освобождать, пока не переключить.
Вариантов вижу только два:

1. Скормить виртуалке оба usb-устройства (12d1:1436 и 12d1:1446) и пусть режим переключается внутри виртуалки. Тогда хост этим заниматься не должен.

Беда в том, что пока явно не перезапустишь: usb_modeswitch -v 0x12d1 -p 0x1446 -R, устройства ttyUSB* не появиться в системе(( После того, как устройстро перезапущено ПИД обрантно возвращает значение 1436
И да насчет прошивки обязатлеьно прочитаю. Но завтра хочу поставить новый модем, дабы икслючить вариант с плохой пайкой и плохими контактами, как советовали ранее.

[unoc_u34]

Из minicom явно отключил все режимы кроме модема. Посмотрим как себя поведет! Но положение отчаенное друзья

[Hephaestus]

Беда в том, что пока явно не перезапустишь: usb_modeswitch -v 0x12d1 -p 0x1446 -R, устройства ttyUSB* не появиться в системе

Я не знаю, как на QEMU - не пробовал. А на Virtualbox для проброса usb достаточно указать VID:PID, причем можно несколько разных для разных вариантов. Таким образом, виртуалка перехватывает usb-устройство в его исходном состоянии и переключение режима происходит уже в виртуальной системе, а не в хостовой.
Утверждать не могу, но предполагаю, что на QEMU тоже можно так сделать.

Из minicom явно отключил все режимы кроме модема. Посмотрим как себя поведет! Но положение отчаенное друзья

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

[unoc_u34]

Беда в том, что пока явно не перезапустишь: usb_modeswitch -v 0x12d1 -p 0x1446 -R, устройства ttyUSB* не появиться в системе

Я не знаю, как на QEMU - не пробовал. А на Virtualbox для проброса usb достаточно указать VID:PID, причем можно несколько разных для разных вариантов. Таким образом, виртуалка перехватывает usb-устройство в его исходном состоянии и переключение режима происходит уже в виртуальной системе, а не в хостовой.
Утверждать не могу, но предполагаю, что на QEMU тоже можно так сделать.

Из minicom явно отключил все режимы кроме модема. Посмотрим как себя поведет! Но положение отчаенное друзья

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

Однако, вариант! Обоих устройств перебросить в виртуалку надо попробовать. Но думаю, что при старте ОС виртуалки ругнется на несуществующий виртуальный девайс (тот который, не переключенный). И наверняка выхлоп dmesg это зафиксирует. Но как бы там не было, Если ошибка возникнет вновь, попробую ваш вариант и отпишусь о результатах. Кстати, спасибо за ваши ответы.

[unoc_u34]

После того, как в миником явно задал мод модем, ПИД не меняется. Но процесс работа шлюза отснавливается. Вот, что в логах господа:
[ 9225.224287] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-2)
[ 9225.225436] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-2)
[ 9225.226615] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-2)
[ 9225.230010] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
[ 9225.231737] option 1-1:1.0: device disconnected
[ 9225.232742] cdc_ether 1-1:1.1 wws4f7u1i1: unregister 'cdc_ether' usb-0000:00:04.7-1, Mobile Broadband Network Device
[ 9225.240958] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
[ 9225.242268] option 1-1:1.3: device disconnected
[ 9225.243218] option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2
[ 9225.244284] option 1-1:1.4: device disconnected
[ 9225.509655] usb 1-1: reset high-speed USB device number 2 using ehci-pci
[ 9225.791966] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 9225.794515] option 1-1:1.0: GSM modem (1-port) converter detected
[ 9225.797183] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
[ 9225.799189] usb-storage 1-1:1.1: USB Mass Storage device detected
[ 9225.812885] cdc_ether 1-1:1.1 wwan0: register 'cdc_ether' at usb-0000:00:04.7-1, Mobile Broadband Network Device, 02:50:f3:00:00:00
[ 9225.815874] usb-storage 1-1:1.3: USB Mass Storage device detected
[ 9225.823713] option 1-1:1.3: GSM modem (1-port) converter detected
[ 9225.824710] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2
[ 9225.825782] usb-storage 1-1:1.4: USB Mass Storage device detected
[ 9225.829636] option 1-1:1.4: GSM modem (1-port) converter detected
[ 9225.830767] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB3
[ 9225.832605] cdc_ether 1-1:1.1 wws4f7u1i1: renamed from wwan0
Sun 2018/07/15 15:15:40 gammu-smsd[799]: Error getting SMS status: Error writing to the device. (DEVICEWRITEERROR[11])
Sun 2018/07/15 15:15:50 gammu-smsd[799]: Error getting SMS status: Error writing to the device. (DEVICEWRITEERROR[11])
Sun 2018/07/15 15:16:00 gammu-smsd[799]: Error getting SMS status: Error writing to the device. (DEVICEWRITEERROR[11])
Sun 2018/07/15 15:16:00 gammu-smsd[799]: Already hit 3 errors
Sun 2018/07/15 15:16:00 gammu-smsd[799]: Terminating communication: Entry is empty. (EMPTY[22])
Sun 2018/07/15 15:16:00 gammu-smsd[799]: Starting phone communication...
Sun 2018/07/15 15:16:00 gammu-smsd[799]: Error at init connection: Error opening device, it doesn't exist. (DEVICENOTEXIST[4])

Очень нужна идея, незнаю уже в какую сторону копать!(( Заранее блаодарю

[devilr]

Как говорил один врач: "если в заднице торчит иголка, то не надо обкалывать её новокаином. Достаточно вытащить её и боль пройдёт сама собой"
Я к тому, что вы пытаетесь решить аппаратную проблему программными затычками. Имхо.

[unoc_u34]

Как говорил один врач: "если в заднице торчит иголка, то не надо обкалывать её новокаином. Достаточно вытащить её и боль пройдёт сама собой"
Я к тому, что вы пытаетесь решить аппаратную проблему программными затычками. Имхо.

Спасибо, завтра попробую заменить модем в первую очередь на новую.