Блог инженера
Для резервирования интернет соединения я использую 3G модем Huawei E173, подключенный в USB порт маршрутизатора. Соединение через него всегда поднято в режиме горячего резерва (для переключения на модем достаточно сбросить default route с основного соединения). Но есть одна проблема — периодически модем «зависает» и соединение теряется.
Как правило достаточно перезапустить pppd, но вчера модем перестал реагировать совсем. В логе появились сообщения, которые относятся к проблемам скорее аппаратным.
xhci_hcd 0000:02:00.0: WARN Event TRB for slot 1 ep 4 with no TDs queued? xhci_hcd 0000:02:00.0: WARN Event TRB for slot 1 ep 4 with no TDs queued? xhci_hcd 0000:02:00.0: WARN Event TRB for slot 1 ep 4 with no TDs queued? xhci_hcd 0000:02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD xhci_hcd 0000:02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD xhci_hcd 0000:02:00.0: ERROR Transfer event TRB DMA ptr not part of current TD
Перезапуск pppd ничего не дал, похоже модем не отвечает ни на одну команду.
Apr 24 10:02:11 inet chat[6761]: abort on (\nBUSY\r) Apr 24 10:02:11 inet chat[6761]: abort on (\nERROR\r) Apr 24 10:02:11 inet chat[6761]: abort on (\nNO ANSWER\r) Apr 24 10:02:11 inet chat[6761]: abort on (\nNO CARRIER\r) Apr 24 10:02:11 inet chat[6761]: abort on (\nNO DIALTONE\r) Apr 24 10:02:11 inet chat[6761]: abort on (\nRINGING\r\n\r\nRINGING\r) Apr 24 10:02:11 inet chat[6761]: send (^MAT^M) Apr 24 10:02:11 inet chat[6761]: timeout set to 12 seconds Apr 24 10:02:11 inet chat[6761]: expect (OK) Apr 24 10:02:23 inet chat[6761]: alarm Apr 24 10:02:23 inet chat[6761]: Failed
Попытки переинициализировать модем программно не увенчались успехом, поскольку его устройство (/dev/ttyUSB0) не отвечает на AT команды. Остается только отключить и снова включить модем в порт. Но сначала решил попробовать метод, на который наткнулся недавно в интернете.
Для сброса нужной шины USB нам потребуется скомпилировать бинарник. Чтобы не компилировать его каждый раз снова и пользоваться им на практически любой машине я буду компилировать его статически.
$ wget https://gist.githubusercontent.com/x2q/5124616/raw -O usbreset.c $ gcc -Wall -static -o usbreset usbreset.c $ sudo install -o root -g root -m 0755 usbreset /usr/local/sbin $ lsusb | grep Huawei Bus 001 Device 002: ID 12d1:1001 Huawei Technologies Co., Ltd. E169/E620/E800 HSDPA Modem $ sudo usbreset /dev/bus/usb/001/002 Error in ioctl: No such device
Несмотря на ошибку в логе появились записи, свидетельствующие о «перезагрузке» модема.
$ dmesg | tail usb 1-6: New USB device strings: Mfr=3, Product=2, SerialNumber=0 usb 1-6: Product: HUAWEI Mobile usb 1-6: Manufacturer: HUAWEI Technology usb 1-6: configuration #1 chosen from 1 choice option 1-6:1.0: GSM modem (1-port) converter detected usb 1-6: GSM modem (1-port) converter now attached to ttyUSB0 option 1-6:1.1: GSM modem (1-port) converter detected usb 1-6: GSM modem (1-port) converter now attached to ttyUSB1 option 1-6:1.2: GSM modem (1-port) converter detected usb 1-6: GSM modem (1-port) converter now attached to ttyUSB2
Попробуем подключиться к нему и выполнить несколько AT команд.
$ screen /dev/ttyUSB0 115200 ATZ OK ATI Manufacturer: huawei Model: E173 Revision: 11.126.16.00.715 IMEI: 861976004215827 +GCAP: +CGSM,+DS,+ES OK
Перезагрузить USB-модем
Можно как-нибудь из под Линукса выключить и включить USB устройство?
А у тебя устройство по USB питается или от внешнего источника?
Конкретно USB-модему можно в COM-порт послать команду AT^RESET (если модель её поддерживает), после которой он сам перезагрузится.
AT^RESET ^BOOT:46585418,0,0,0,20 COMMAND NOT SUPPORTДа и вряд ли поможет. Если перезагружать компьютер, модем почему-то не сбрасывается, а вот если вытащить и обратно воткнуть, тогда нормально.
Попробуй остановить/перезапустить драйвер. Если поможет, то повезло.
Лол. Драйвер тупо общается с модемом согласно USB CDC, он не управляет им и не выолгняется на нём. На модеме свой проц. Который и нужно перезагрузить.
DUB-H7 или подобный хаб, + hubctl
Если модем потерял сеть или какой-то глюк с передачей данных, то можно перезагрузить радиомодуль. В 99% случаях мне помогает (примерно 15 модемов) AT+CFUN=4 — off AT+CFUN=6 — on Отправить их можно через cu или chat
Как еще один вариант попробуй через minicom послать команду ATZ
Перезапустить зависшее USB устройство
Есть один USB модем. Временами он уходит в себя и перестаёт реагировать на конструктивную критику, при этом продолжая моргать лампочками и вообще не проявляя каких-либо признаков беспокойства. Из этого состояния его выводит либо перетык в USB, либо перезагрузка всея компьютера, usb_reset не срабатывает.
Управления питанием у хоста (злосчастная распберри3) нема. Как бы так извернуться и дать модему пня, чтобы он перезапустился, без полной перезагрузки? Ведь как-то же он понимает, что хост ребутнулся.
Ведь как-то же он понимает, что хост ребутнулся.
Скорее всего в момент ребута хост отключает питание на USB. Ну то есть может не быть управления питанием на уровне порта, но может быть управление питанием на уровне всего контроллера USB. Но это общая информация, как именно это сделано на малине не знаю.
Самое надёжное — купить хаб с управлением питанием. Ещё можно купить релюшку в разрыв 5В линии USB провода малины и дёргать её через GPIO малины (разумеется, реле или иной ключ должен быть совместим по току и напряжению с малиной).
Хорошее описание проблемы. Если твой модем подключается как usb устройство к какому-то PC. То очевидно, что есть механизмы управления питанием usb портов из системы. А еще, есть что-то, что обнаруживает твое устройство и подключает его к PC. Никакой магии. У тебя 0 идей как эти «чудеса» происходят ?
У меня для ресета модема была такая последовательность
if ! gammu identify | grep -q E173 ; then usb_modeswitch -R -v 0x12d1 -p 0x1001 echo "12d1 1001" > /sys/bus/usb-serial/drivers/option1/new_id sleep 5 if ! gammu identify | grep -q E173 ; then logger -p daemon.err "Modem FAILED" fi fi забавно. Полагаю, в моём случае следует поработать тяпкой в /sys/bus/usb/drivers/cdc_ether.
Если твой модем подключается как usb устройство к какому-то PC. То очевидно, что есть механизмы управления питанием usb портов из системы.
Не ври. Их нет. Питание встроенных портов почти всегда тупо припаяно к системной +5V шине.
Я даже не знаю как тут комментировать. Первая ссылка в гугле «Управление питанием портов USB»
1) гугл это плохой сайт, не надо туда ходить
2) по твоей ссылке наверно тоже враньё, но в любом случае ходить я по ней не собираюсь (тем более что ты её не написал), лучше тут процитируй суть
Да не, в теории есть PPPS для этого, только на практике он есть чуть менее чем нигде.
У тебя все там в порядке ? На посмотри https://sysadminmosaic.ru/usb/power
Ты сам то пробовал это? Возьми мультиметр, подключи к usb питанию, повводи эти команды и увидишь что ничего не меняется. По крайней мере с теми портами что на материнке. Если у тебя на какой-нить флешке от этих команд гаснут индикаторы — так это не из-за питания, а из-за того что комп ей такую команду послал.
firkax ★★★★ ( 16.02.23 15:30:12 MSK )
Последнее исправление: firkax 16.02.23 15:35:03 MSK (всего исправлений: 2)
Отключить питания USB это значит обесточить usb порт и не подавать на него напряжение ? Честно, я не знаю в реальности есть ли там напряжение. Но в кейсе ТС-а это не имеет НИКАКОГО значения.
Да, «отключить питание» и «обесточить» это одно и то же. И автору нужно именно это, програмно модем завис и ни на какие сигнальные послания от компа не реагирует.
Ведь как-то же он понимает, что хост ребутнулся.
При ребуте всё с нуля инициализировается. Скорее всего и питание с портов сбрасывается в это время.
В твоем случае возможно придётся разжиться хитрым хабом или концентратором, который умеет управлять питанием портов. Ну и малине легче будет, если у него вообще своё питание будет.
И на правах бреда проверь температуру модема в момент отавала. Может тебе не питание дёргать надо, а радиатор на него повесить. Ещё можно помониторить напряжение во время работы каким-нибудь умным тестером зарядок. Есть вариант, что модем зависает из-за просадок напряжения и/или перегрузок по току.
Radjah ★★★★★ ( 16.02.23 15:53:33 MSK )
Последнее исправление: Radjah 16.02.23 15:55:18 MSK (всего исправлений: 1)
У модема совершенно рандомно мозги текут. Иногда перестаёт ловить сеть, и можно ребутнуть через панель управления, иногда забывает, как работать с DHCP, и после истечекия аренды всё ещё можно установить старый IP вручную и открыть панель, иногда просто перестаёт откликаться, и только лампочками моргает. Какой-то прикладной способ вряд ли годится, потому что функционал деградирует рандомно.
Что характерно, DHCP лечится через usb_reset, а потеря сети и полное зависание — нет.
bo4ok ★ ( 16.02.23 16:05:53 MSK )
Последнее исправление: bo4ok 16.02.23 16:07:15 MSK (всего исправлений: 1)
В порядке вангования: а фирмварь модема обновлять пробовал? Что вообще за модем?
Простой рецепт устойчивой работы 3G под Linux
С настройками wvdial по умолчанию — сообщения шли бесконечно. По всем симптомам — модем «зависал». Проблема решалась просто — ручным кратковременным вытаскиванием модема из USB разъема.
Но мне требовалось более надежное решение, независящее от моего присутствия. Сам рецепт подсказывал мне — надо научиться программно перезапускать модем.
Самый надежный и универсальный способ — управление питанием по шине USB. Выключить и включить питание модема и все — проблема будет решена.
К сожалению, USB-хабы, поддерживающие управление питанием весьма редки. А исследование устройства с точки зрения Linux указывало на отсутствие такой функции на шине USB модема. Поэтому, такой вариант пришлось исключить.
Второй вариант — попробовать AT командой поуправлять модемом. Хотя бы заставить переподключить к GSM/3G сети.
Пришлось заняться поиском документации по AT коммандам.
И они нашлись от первоисточника:
http://www.3gpp.org/ftp/Specs/html-info/27007.htm
Команда, решающая мою проблему выглядит так:
Команда заставляет модем перегрузиться и снова перейти в рабочий режим.
Модем действительно перегрузился, даже находясь в режиме передачи данных — команда была послана через ttyUSB2.
В консоли команда отправляется так:
echo -e "AT+CFUN=1,1\r\n" >/dev/ttyUSB0
Проблема теоретически решена. Осталось автоматизировать процесс.
В /etc/wvdial.conf добавил ограничение на количество попыток соединения:
После пяти не успешных попыток дозвониться, wvdial завершит работу.
Теперь обертываю вызов wvdial в скрипт:
rm -f /var/log/3g.log while true; do echo "wvdial" >>/var/log/3g.log wvdial >&/var/log/wvdial.log echo "sleep 10" >>/var/log/3g.log sleep 10 echo "reboot modem" >>/var/log/3g.log echo -e "AT+CFUN=1,1\r\n" >/dev/ttyUSB0 echo "sleep 30" >>/var/log/3g.log sleep 30 done
Вызов скрипта добавляю в скрипт загрузки системы.
/var/log/wvdial.log — будут писаться события wvdial
/var/log/3g.log — события скрипта
30 секунд оказалось вполне достаточно для перезагрузки модема.
Желаю устойчивого connect’a!